La documentation officielle décrit Raydium comme un ensemble de programmes Solana pour la tenue de marché automatisée et une infrastructure de liquidité, et présente RAY comme le jeton SPL natif de Raydium.
Les recherches anglaises raydium ecosystem and use cases, raydium solana et how does raydium work renvoient respectivement à l'écosystème, au contexte réseau et au mécanisme. Ce profil y répond au niveau de l'architecture et ne transforme pas un design documenté en affirmation de valeur, de sécurité, de disponibilité, de légalité ou de résultat pour quiconque.
Qu'est-ce que Raydium sur Solana
Les sources officielles décrivent Raydium comme une collection de programmes de contrats intelligents permissionless et non custodial sur Solana. La documentation le présente comme une pile de tenue de marché automatisée et de liquidité, non comme une application unique et indivisible. Chaque programme possède ses propres états, sa logique de courbe, son historique de versions et ses limites de risque.
Un teneur de marché automatisé, ou AMM, exprime une relation entre des actifs grâce à des règles de programme et à des réserves contrôlées par le programme. Il applique la courbe documentée aux réserves concernées au lieu de laisser une personne fixer chaque relation. Cela explique l'organisation de la liquidité onchain, mais ne prouve ni la fiabilité, ni l'adéquation, ni l'émission légitime, ni la conservation de valeur d'un actif.
La liquidité désigne ici une organisation structurée de réserves à partir de laquelle le programme peut calculer sa courbe. Elle ne promet pas qu'un actif pourra toujours être converti selon une relation attendue, que la composition des réserves restera stable ou qu'un chemin donné restera disponible. Une description de la liquidité est donc un point de départ architectural, pas une garantie d'exécution, de sécurité ou de profondeur.
Quel problème un AMM cherche-t-il à traiter
À haut niveau, un AMM traite la question de savoir comment un programme peut dériver une relation changeante entre deux réserves sans carnet d'ordres externe. Un design à produit constant exprime couramment sa relation centrale comme x · y = k. Si une réserve change par rapport à l'autre, la courbe implique une relation différente entre les deux côtés. C'est un modèle mathématique, non une prévision ou une recommandation.
La documentation Raydium distingue plusieurs designs AMM. CPMM est la forme standard à produit constant, CLMM concentre la liquidité dans des plages choisies et Stable AMM utilise une courbe de table interpolée pour des actifs corrélés. La présence de plusieurs designs reflète des structures de programmes et des contraintes différentes, mais ne signifie pas que l'un est toujours plus sûr, plus approprié ou plus avantageux qu'un autre.
La liquidité est aussi un concept d'état, non un label de qualité. Les réserves, les paramètres de courbe, le comportement des jetons, les mises à jour des programmes et les conditions autour de Solana peuvent modifier ce que le mécanisme représente à un moment donné. Il faut distinguer l'idée durable d'un programme fondé sur une courbe des observations variables sur un pool ou une interface précis.
Comment les programmes AMM de Raydium s'articulent-ils
La documentation d'architecture actuelle de Raydium décrit des programmes AMM indépendants, notamment AMM v4, CPMM, CLMM et Stable AMM, ainsi qu'une infrastructure de soutien telle que le routing et des conventions de configuration. Les programmes partagent l'environnement Solana, mais ne se réduisent pas à un moteur universel de relation de prix. Le nom Raydium ne prouve donc pas que chaque composant a le même comportement ou le même statut.
CPMM est documenté comme un AMM à produit constant natif de Solana. CLMM est documenté comme un design par plages, ticks et comptabilité au niveau de la position. Stable AMM est documenté comme un programme séparé avec une courbe de table. Ces descriptions expliquent plusieurs formes de liquidité dans l'architecture, mais ne prescrivent aucune action et ne promettent aucun résultat.
La documentation officielle actuelle fixe aussi une importante limite historique. AMM v4 a autrefois eu une intégration avec le carnet d'ordres OpenBook, mais la documentation indique que cette intégration est désactivée et que les comptes associés sont inertes. Elle ne doit pas être présentée comme une source actuelle de liquidité partagée. Ainsi, how does raydium work doit être expliqué par les programmes et courbes actuels, non par un récit d'intégration obsolète.
Que représente RAY dans le système Raydium
La page officielle RAY de Raydium identifie RAY comme le jeton SPL natif du projet sur Solana. Le ticker exact est RAY. Cela identifie le libellé de jeton utilisé par la documentation, sans établir un intérêt de propriété, un droit à un rendement, une valorisation ou une raison de l'acquérir.
Un ticker est un identifiant, non une preuve d'authenticité. Des noms, symboles, images et descriptions semblables peuvent être copiés. À des fins éditoriales, l'identité officielle du jeton doit être séparée des sources non liées qui réemploient seulement le mot RAY ou Raydium.
Les données d'offre, les informations de mint, le langage d'allocation, les émissions, les descriptions liées à la gouvernance et toute formulation d'utilité sont des faits du jour de publication. Ils ne sont utiles que s'ils sont recoupés avec le document officiel actuel et si leur portée est précisée. Ce profil évite volontairement les quantités variables et ne présente aucun mécanisme de jeton comme une promesse.
Un point structurel relève de RAY et non de l'architecture. La fiche méthodologique de DefiLlama pour ce protocole indique que 12 % des frais de transaction, tous types de pools confondus, financent des rachats de RAY et que 4 % des frais des pools à liquidité concentrée et à produit constant vont à la trésorerie, le reste revenant aux fournisseurs de liquidité. L'accumulation de frais suit donc le volume qui transite réellement par les pools, et une large part de ce flux, ces dernières années, provenait des lancements de jetons sur Solana. En 2025, ce lien est devenu explicite : en mars, une plateforme de lancement a sorti un teneur de marché automatisé concurrent et a capté une partie de ce flux, et Raydium a répondu en avril par son propre produit de lancement. Lire RAY sans lire le volume de lancements, c'est manquer l'origine des frais.
Écosystème Raydium et état actuel de la documentation
L'écosystème Raydium dans la documentation actuelle inclut des documents sur AMM v4, CPMM, CLMM, Stable AMM, Farm, LaunchLab et l'infrastructure de liquidité partagée. La documentation sépare aussi les programmes onchain natifs des surfaces offchain de soutien. Il s'agit d'une carte de composants documentés, non d'une confirmation que chaque composant a le même statut actif, la même portée géographique, la même disponibilité d'interface ou la même maturité.
Le langage relatif au statut actuel doit être revu le jour de publication. Les documents officiels peuvent modifier leurs descriptions des versions de programmes, désactivations, mises à jour, surfaces destinées aux utilisateurs ou choix de configuration. Le statut de AMM v4, CPMM, CLMM, Stable AMM, Farm et LaunchLab doit donc être lu sur les pages officielles le jour de publication, non déduit d'un ancien article, d'un résultat en cache ou d'un visuel copié.
La liste de l'écosystème ne démontre pas non plus à elle seule un cas d'usage d'actifs du monde réel. Elle ne valide ni actif sous-jacent, ni émetteur, ni droit juridique, ni réserve, ni traitement réglementaire. Toute affirmation sur une structure RWA précise exige sa propre preuve primaire et ne doit pas être inférée de l'existence d'une infrastructure générale de liquidité Solana.
Comment lire les affirmations sur l'architecture de Raydium
Un schéma d'architecture peut clarifier quelle catégorie de programme est responsable d'un état ou d'une courbe. Il ne peut pas établir qu'une instance déployée est exempte de défaut, que sa configuration convient ou qu'une interface externe affiche une information complète. La portée d'un mécanisme documenté est plus étroite qu'une garantie sur des conséquences réelles.
Non custodial et permissionless décrivent un modèle de système. Ils ne résolvent pas à eux seuls les questions de risque de code, d'autorité administrative, de contrôle des mises à jour, de comportement des jetons, d'erreur utilisateur, de traitement réglementaire ou de continuité de service. Chaque question exige une source de preuve différente et peut évoluer.
La documentation distingue aussi les programmes onchain des surfaces offchain associées. Cette distinction évite qu'un nom de produit large soit pris pour une assurance unique, mais elle ne signifie pas que l'infrastructure de soutien, la documentation, l'indexation ou une interface seront toujours disponibles, complètes ou sans erreur.
Risques, confusion d'identité et limites de la documentation
Les systèmes AMM et de liquidité comportent des risques de code, de configuration, de composition et propres aux actifs. La logique de courbe peut différer de l'intuition du lecteur, les caractéristiques de jeton peuvent introduire un comportement particulier et des changements dans les systèmes environnants peuvent modifier les conditions d'interprétation d'un programme. Un profil court ne supprime pas ces risques.
Il existe aussi un risque d'identité. Un nom connu, un ticker, un logo, une capture d'écran, un compte social ou un résultat de recherche ne suffit pas à prouver qu'une source ou un actif est officiel. Les documents officiels de sécurité Raydium insistent sur les vérifications de domaine et d'identité, car des imitateurs et des libellés trompeurs peuvent imiter un projet légitime.
Une référence d'audit, un dépôt de code public ou une déclaration de sécurité doivent être lus selon leur portée exacte et leur date. Aucun ne garantit à lui seul sécurité, conformité, liquidité, disponibilité ou absence de changements futurs. La bonne limite éditoriale consiste à décrire la source primaire et à laisser hors de l'article les affirmations non vérifiées.
Deux incidents distincts figurent au dossier public de ce projet, et ils ont échoué de manières différentes. Le 16 décembre 2022, une clé administrative de pool a été compromise ; le post-mortem de l'équipe attribue la compromission à un cheval de Troie présent sur la machine qui détenait la clé, l'attaquant ayant ensuite appelé une fonction retirant les frais de transaction normalement destinés à la trésorerie du DAO, vidant plusieurs pools. Les montants de perte rapportés diffèrent selon les récits. Ce qui compte pour le lecteur, c'est la classe de défaillance : il s'agissait de sécurité opérationnelle des clés et non d'un défaut dans les mathématiques des pools. L'indemnisation a consisté à couvrir la part en RAY avec des jetons d'équipe déjà débloqués et à soumettre aux détenteurs une proposition de trésorerie pour les actifs que l'équipe ne détenait pas.
Le second incident, le 10 juin 2026, provenait de code retiré et non de l'exploitation. Un programme de teneur de marché automatisé obsolète, hérité d'une époque antérieure, ne vérifiait pas les adresses d'émission des jetons LP sur son chemin de retrait ; un attaquant a donc créé une émission LP contrefaite sans lien avec un pool réel, en a frappé une seule unité et a appelé l'ancienne fonction de retrait ; l'ancien programme a traité cela comme une part de 100 % et a libéré les réserves. Cinq pools inactifs de longue date, remontant à 2021, ont été vidés d'environ 1,34 million de dollars au total. Raydium a décrit le défaut comme une erreur de logique circonscrite au programme hérité, a indiqué que les pools et programmes actuels n'étaient pas exposés et a annoncé que sa trésorerie couvrirait les pertes. Ensemble, ces deux événements illustrent une règle générale : du code retiré, devenu inaccessible depuis une interface, peut rester accessible en chaîne.
Comment vérifier Raydium et RAY
La vérification commence par la comparaison du nom du projet, du contexte de la documentation officielle et du composant précisément décrit dans les sources de première partie Raydium. Un article copié, un annuaire non lié ou une publication sociale ne peut servir que d'indice, non de source faisant autorité pour une affirmation factuelle.
Pour RAY, la révision avant publication doit rapprocher le ticker, le contexte Solana et le document officiel actuel du jeton. Une adresse du contrat ou un explorateur de blocs peut soutenir la vérification de l'identité seulement s'il correspond à un identifiant publié dans le matériel officiel du projet. Cela ne remplace pas la vérification de la source, de la date et de la portée de ce matériel.
Enfin, il faut séparer les affirmations stables sur le mécanisme des faits du jour de publication. Les versions de programme, avis de désactivation, données de mint, statut d'interface, informations de sécurité, domaines officiels et toute affirmation liée à RWA exigent une vérification primaire actuelle. Ce sont des principes d'évaluation de l'information publique, non des indications pour utiliser un produit ou autoriser une action.
Conclusion
Selon les sources de première partie actuelles, Raydium se comprend le mieux comme une architecture AMM et de liquidité à plusieurs programmes sur Solana. CPMM, CLMM, Stable AMM et le design AMM v4 plus ancien décrivent différentes façons d'organiser l'état des réserves et la logique de courbe. RAY est le ticker officiel du jeton SPL natif de Raydium.
La limite éditoriale centrale est celle qui sépare un mécanisme documenté d'un résultat garanti. La documentation actuelle doit être lue selon sa portée et sa date, surtout lorsqu'une ancienne description de carnet d'ordres, une affirmation sur un jeton, un statut de programme ou une affirmation RWA pourrait être prise à tort pour un fait actuel ou une promesse.
Pages de marché associées
Pages Bitbase pour les jetons cités dans cet article :
- RAY : Voir le prix · Marché spot
Articles associés
Autres articles Bitbase sur ce sujet :
- Staking sur Solana et économie des validateurs
- Erreurs de transaction Solana : blockhash expiré et transactions non incluses
- Frais et performance de Solana
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il explique ce que fait un projet et quel rôle son jeton joue dans ce système ; il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance, et il ne vaut ni recommandation ni approbation d'un projet ou d'un jeton. Bitbase n'a pas effectué de diligence raisonnable sur le projet décrit ici, et le mentionner ne signifie pas que Bitbase référence ou prend en charge cet actif. Les cryptoactifs comportent un risque important, notamment la volatilité des prix, une liquidité faible, la défaillance des contrats intelligents, l'incertitude réglementaire et la perte possible de toute leur valeur. Rédigé en août 2026 ; le statut d'un projet, sa tokenomics, son équipe et ses contrats peuvent changer à tout moment. Vérifiez tout par vous-même via les canaux officiels, l'adresse du contrat et un explorateur de blocs, et méfiez-vous des sites imitant le projet et des liens d'hameçonnage.
Sources
[1] What is Raydium, Raydium Docs docs.raydium.io
[2] Raydium Architecture, Raydium Docs docs.raydium.io
[3] Versions and migration, Raydium Docs docs.raydium.io
[4] CPMM overview, Raydium Docs docs.raydium.io
[5] CLMM overview, Raydium Docs docs.raydium.io
[6] RAY, Raydium Docs docs.raydium.io
[7] Security and Risk, Raydium Docs docs.raydium.io
[8] Trust and safety, Raydium Docs docs.raydium.io
[9] Cointelegraph, Raydium announces details of the 2022 hack and compensation cointelegraph.com
[10] CertiK, Raydium protocol exploit incident analysis www.certik.com
