Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Le modèle de compte de Solana est la chose la plus importante à comprendre avant de lire le code de Raydium. Contrairement à Ethereum où l’état vit aux côtés du code du contrat, les programmes Solana sont complètement sans état : tout l’état vit dans des « comptes » séparés sur lesquels les programmes opèrent. Chaque pool, position et coffre Raydium est un compte — comprendre comment ces comptes fonctionnent rend le reste de la documentation compréhensible.

​
La séparation fondamentale : programmes vs comptes

​
Programmes

Un programme sur Solana est du code exécutable — un binaire compilé chargé à partir d’un fichier, déployé sur une Pubkey, et invocable via des transactions. Les programmes n’ont pas d’état associé ; ils ne contiennent que de la logique. Les programmes de Raydium :
  • CPMM : CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
  • CLMM : CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK
  • AMM v4 : 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
Chacun est un binaire fixe. Le programme ne « se souvient » de rien entre les invocations.

​
Comptes

Un compte est une ligne de données sur la chaîne. Chaque compte a :
  • pubkey — son adresse.
  • owner — le programme qui le possède (contrôle les écritures).
  • data — les octets bruts.
  • lamports — le solde SOL (1 SOL = 1 000 000 000 lamports).
  • rent_epoch — champ hérité de la collecte de rent (ignoré depuis que l’exemption de rent est devenue obligatoire).
Quand vous interrogez un pool Raydium, vous lisez un ou plusieurs comptes. Quand un swap s’exécute, le programme CPMM lit/écrit plusieurs comptes — l’état du pool, les coffres, l’état des observations, et les comptes de jetons de l’utilisateur.

​
Propriété

Chaque compte est possédé par exactement un programme. Seul le code de ce programme peut modifier le champ data du compte. Un utilisateur peut modifier lamports (envoyer/recevoir SOL) sur un compte pour lequel il peut signer, mais modifier data nécessite que le programme propriétaire le fasse en son nom. Exemples :
  • Votre portefeuille utilisateur : possédé par le System Program. Les lamports vivent ici ; vous signez pour transférer.
  • Votre compte de jetons USDC : possédé par le SPL Token Program. L’instruction transfer du programme de jetons met à jour le solde.
  • Un compte d’état de pool Raydium : possédé par le programme CPMM. Seules les instructions CPMM peuvent modifier les réserves, les frais, etc.
  • Le PersonalPositionState d’un NFT de position Raydium : possédé par le programme CLMM.
« Possédé par » est strict : si le programme A écrit sur un compte possédé par le programme B, le runtime Solana rejette la transaction.

​
Rent et exemption de rent

Créer un compte consomme de l’espace de stockage. Solana facture le rent pour cet espace, mais depuis 2020 tous les nouveaux comptes doivent être exempts de rent — ce qui signifie qu’ils détiennent suffisamment de lamports pour que le rent qu’ils devraient sur 2 ans soit préfinancé. En pratique :
  • Un compte exempté de rent vit pour toujours.
  • Fermer le compte retourne les lamports au signataire qui ferme.
Pour un compte de 165 octets (par ex., compte de jetons SPL), l’exemption de rent est ~0,00204 SOL. Pour un état de pool CPMM Raydium de 1 440 octets, c’est ~0,011 SOL.

​
Coûts de rent Raydium

CompteTailleRent
CPMM PoolState~1 440 B~0,011 SOL
CLMM PoolState~1 500 B~0,012 SOL
CLMM TickArray~9 000 B~0,063 SOL
CLMM PersonalPositionState~280 B~0,003 SOL
ATA165 B~0,002 SOL
Vault (Compte de jetons)165 B~0,002 SOL
La création d’un pool nécessite le rent pour plusieurs comptes à la fois — c’est pourquoi la création d’un pool CPMM coûte ~0,15 SOL au total.

​
Comptes de données vs comptes exécutables

Les comptes se présentent sous deux saveurs :

​
Comptes de données

Conservent l’état (réserves du pool, soldes de jetons, positions des utilisateurs). executable = false. C’est la grande majorité.

​
Comptes exécutables

Conservent le bytecode du programme. executable = true. Ce sont les programmes (CPMM, CLMM, etc.). Les programmes n’ont pas de données au-delà de leur bytecode.

​
Comptes dérivés du programme (PDA)

Un PDA est un compte de données dont l’adresse est dérivée de manière déterministe à partir d’un programme et de certaines graines — aucune clé privée n’existe pour cette adresse. Seul le programme de dérivation peut signer au nom d’un PDA via invoke_signed. Raydium utilise extensivement les PDA :
  • Les PDA d’état du pool : dérivés de [poolTypeDiscriminator, mintA, mintB, ammConfig].
  • Les PDA de coffre : dérivés de [pool, mint].
  • Le PDA d’état des observations : dérivé de [observationSeed, pool].
Les PDA permettent à Raydium de créer des comptes à des adresses prévisibles sans gérer les clés. N’importe qui peut calculer l’adresse PDA pour un pool connu étant donné les graines. Voir solana-fundamentals/pdas-and-cpis.

​
Transactions et références de comptes

Chaque transaction Solana porte une liste explicite des comptes qu’elle va lire/écrire. Le runtime applique :
  • Les comptes listés peuvent être lus ou écrits (selon leur drapeau is_writable).
  • Les comptes non listés ne peuvent pas être touchés.
Pour un swap Raydium, la liste des comptes de la transaction inclut : 
[readonly] CPMM program
[writable] pool state
[readonly] amm config
[readonly] pool authority (PDA)
[writable] input vault
[writable] output vault
[writable] user input ATA
[writable] user output ATA
[readonly] input mint
[readonly] output mint
[readonly] input token program
[readonly] output token program
[writable] observation state
[signer,writable] user
Cette énumération explicite est la raison pour laquelle les transactions Solana sont rapides et parallélisables — le runtime peut déterminer les tx non conflictuelles à l’avance.

​
Taille du compte et disposition des données

Chaque compte Raydium a une taille fixe ou limitée. La disposition est définie dans le code (structs Rust avec #[repr(C)]) et documentée dans sdk-api/anchor-idl. Les programmes Anchor ajoutent en préfixe un discriminateur de 8 octets à chaque compte qu’ils créent, dérivé de hash("account:<StructName>")[0..8]. Cela permet aux clients d’identifier le type d’un compte en lisant simplement les 8 premiers octets — crucial pour les scans getProgramAccounts qui énumèrent tous les comptes d’un type.

​
Lire un état de pool Raydium

Via le SDK : 
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
Via RPC brute + disposition : 
const accountInfo = await connection.getAccountInfo(poolId);
const data = accountInfo.data;
// Ignorer les 8 premiers octets (discriminateur), puis analyser selon la disposition de struct.
const poolState = CpmmPoolStateLayout.decode(data.slice(8));
La disposition se trouve dans src/raydium/cpmm/layout.ts dans la source du SDK.

​
Exemple travaillé : lire un compte de jetons

Lisons le solde USDC d’un utilisateur. 
import { Connection, PublicKey } from "@solana/web3.js";
import { getAssociatedTokenAddressSync, AccountLayout } from "@solana/spl-token";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const user       = new PublicKey("YourUserWallet...");
const usdcMint   = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");

// 1. Calculer l'adresse ATA (dérivation de style PDA).
const ata = getAssociatedTokenAddressSync(usdcMint, user);

// 2. Lire le compte.
const accountInfo = await connection.getAccountInfo(ata);
if (!accountInfo) {
  console.log("ATA n'existe pas encore (l'utilisateur n'a jamais détenu USDC).");
  return;
}

// 3. Vérifier que le propriétaire est le SPL Token Program.
console.assert(accountInfo.owner.toBase58() === "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA");

// 4. Décoder les données.
const parsed = AccountLayout.decode(accountInfo.data);
console.log("Solde (plus petites unités):", parsed.amount.toString());
console.log("Mint:",                        new PublicKey(parsed.mint).toBase58());
console.log("Propriétaire:",                new PublicKey(parsed.owner).toBase58());
Ce motif — dériver l’adresse, récupérer le compte, vérifier le propriétaire, décoder — s’applique à chaque lecture sur la chaîne, y compris les pools Raydium.

​
Pourquoi cela importe pour Raydium

Le modèle de compte façonne la conception de Raydium :
  • L’état du pool est un seul compte — tout ce qui concerne un pool (mints, réserves, frais, admin) vit dans un seul compte possédé par le programme du pool.
  • Les jetons LP sont des comptes de jetons SPL standard — Raydium délègue la tokenization au SPL Token Program.
  • Les tableaux de ticks sont fragmentés — CLMM ne peut pas avoir un seul tableau de ticks croissant car les comptes ont une taille allouée fixe ; à la place, il utilise des PDA TickArray fragmentés.
  • Les NFT de position sont des NFT Metaplex — les positions CLMM sont des NFT standard selon Metaplex ; l’état de position est un PDA séparé.
Comprendre cela vous permet de répondre correctement aux questions « où vit X ? » :
  • « Où sont les réserves du pool ? » → deux comptes de coffre (comptes de jetons) possédés par le SPL Token Program, avec autorité déléguée à un PDA du programme du pool.
  • « Où sont les données de tick pour CLMM ? » → une série de PDA TickArray, chacun couvrant 60 ticks consécutifs.
  • « Où est mon stake de farm ? » → un PDA UserLedger dérivé de [user, farmId], possédé par le programme de farm.

​
Pointeurs

Sources :