Infrastructure partagée

​

Ce que « partagé » signifie ici

• Partage de convention. Chaque programme utilise le même motif de dérivation PDA, la même forme de répartition des frais et la même idée de compte d’observation — mais chacun les implémente dans son propre programme avec ses propres seeds.
• Partage de compte. Une poignée de comptes sont littéralement le même enregistrement sur plusieurs pools (le PDA d’autorité global en CPMM, les comptes AmmConfig).
• Partage hors chaîne. Une API REST et un SDK TypeScript font face à tous les quatre programmes. Les intégrateurs interagissent avec un seul hôte HTTP et un seul paquet NPM, quel que soit le programme qu’ils finissent par appeler.

​

1. PDAs d’autorité

• Pour CPMM et CLMM, le PDA d’autorité est un compte global — chaque pool de ce type l’utilise. Si vous faites un CPI dans CPMM, vous en avez besoin une fois, pas par pool.
• Pour les autorités par pool / par ferme, vous dérivez le PDA à partir de l’ID du pool/ferme. Le SDK le fait dans getPoolKeys / getFarmKeys ; si vous intégrez directement, vous dérivez avec findProgramAddressSync.
• La propriété du coffre ne peut pas être modifiée. Une fois qu’un compte de jeton est créé avec le PDA d’autorité comme propriétaire, seul ce PDA — invoqué par le programme — peut transférer. Il n’y a pas de remplacement administrateur.

​

2. Comptes d’administration et de configuration

// CPMM AmmConfig (abrégé — la version CLMM est structurellement similaire)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // gate new pool creation in this tier
    pub index: u16,                       // tier index
    pub trade_fee_rate: u64,              // fraction of trade going to fees
    pub protocol_fee_rate: u64,           // fraction of trade fee to protocol
    pub fund_fee_rate: u64,               // fraction of trade fee to fund
    pub create_pool_fee: u64,             // one-time per-pool creation fee
    pub protocol_owner: Pubkey,           // signer for CollectProtocolFee
    pub fund_owner: Pubkey,               // signer for CollectFundFee
    pub padding: [u64; 16],
}

• Les paliers de frais sont globaux. Quand un pool dit « c’est un pool à 0,25% », cela signifie qu’il se lie au AmmConfig dont le trade_fee_rate était 0,25% au moment de la création. Il n’y a pas de remplacement de taux par pool.
• Une configuration peut être modifiée mais les pools ne la suivent pas. Si l’autorité de configuration modifie un AmmConfig, chaque pool existant lié à cette configuration récupère immédiatement le nouveau taux. C’est une fonctionnalité, pas un bug ; c’est ainsi que les changements économiques au niveau du protocole se propagent sans migrations par pool.
• disable_create_pool est le levier de dépréciation. Quand un palier de frais est supprimé, le multisig du protocole définit cet indicateur — les pools existants continuent de fonctionner mais aucun nouveau pool ne peut choisir le palier.
• protocol_owner / fund_owner sont les signataires pour les appels de collecte de frais. Les définir sur un multisig est ce qui contrôle le retrait des frais. Ce ne sont PAS les adresses de destination des frais eux-mêmes ; c’est protocol_fee_destination / fund_fee_destination sur le même compte.

​

3. La répartition des frais protocole / fonds / créateur

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. Les frais de transaction s’accumulent dans le pool. Les frais sont prélevés du côté d’entrée du swap et le montant après frais est ce que les mathématiques du produit constant voient. C’est ce que « le LP gagne les frais » signifie — k augmente et la valeur implicite par jeton LP aussi.
2. Les portions protocole/fonds/créateur sont déduites de cette accumulation du côté LP dans des comptes de compteur par pool. Elles se trouvent sur l’état du pool (protocol_fees_token{0,1}, fund_fees_token{0,1}, etc.) jusqu’à ce que quelqu’un appelle l’instruction de collecte correspondante. Elles ne quittent pas les coffres du pool jusqu’à ce moment ; du point de vue d’un swap, elles sont toujours « dans le pool ».
3. La collecte les déplace. Les chemins protocole et fonds nécessitent le signataire respectif protocol_owner / fund_owner de AmmConfig. Les frais de créateur CPMM utilisent soit le chemin CollectCreatorFee signé par le créateur, soit CollectCreatorFeePermissionless, que n’importe quel payeur peut déclencher mais qui fixe les destinations aux ATAs canoniques du créateur.

• Les pourcentages de répartition sont sur les frais de transaction, pas sur la transaction. Un frais de transaction de 0,25% avec une part de protocole de 12% signifie que le protocole obtient 0,25% × 12% = 0,03% de la transaction — pas 12% de la transaction.
• Les frais de créateur n’existent que sur les pools diplômés de LaunchLab. Les pools CPMM/CLMM standard ont une répartition à 3 voies (LP / protocole / fonds). LaunchLab ajoute un quatrième slot acheminé vers celui qui a lancé le jeton, configuré à Initialize et immuable.
• AMM v4 se divise en deux voies seulement, codées en dur par pool : LP et protocole. Pas de slot fonds, pas de slot créateur.
• Fonds vs protocole — les deux sont des destinations de trésorerie du protocole, mais ils ont des signataires différents et des utilisations prévues différentes. protocol finance historiquement les opérations ; fund est la trésorerie à plus long terme. La répartition entre les deux est elle-même réglable.

​

4. Comptes d’observation (tampon annulaire TWAP)

// CPMM ObservationState (abrégé)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // next slot to overwrite
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // sum of (price × dt) since init
    pub cumulative_token_1_price_x32: u128,
}

• Chaque swap appelle update_observation. Le programme lit le prix actuel, le multiplie par les secondes écoulées depuis l’observation précédente, et l’ajoute au compteur cumulatif. La nouvelle entrée écrase le slot le plus ancien (style tampon annulaire).
• TWAP sur une fenêtre = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Les consommateurs choisissent deux observations encadrant la fenêtre souhaitée et divisent.
• Raydium lui-même n’utilise pas le TWAP pour la tarification. Les mathématiques AMM lisent directement les réserves au comptant. Les observations sont une externalité — Raydium paie le coût de les écrire pour que d’autres contrats puissent les lire.
• AMM v4 n’a pas de compte d’observation. Il est plus ancien que la conception ObservationState ; les intégrateurs voulant un TWAP v4 doivent en calculer un hors chaîne à partir de l’historique des journaux.

​

5. API REST + SDK + IDL

• API REST — https://api-v3.raydium.io. Une vue indexée en lecture seule de tout l’état on-chaîne plus un moteur de devis. Un hôte, un schéma.
• SDK TypeScript — @raydium-io/raydium-sdk-v2 sur NPM. Construit et signe les transactions pour chaque programme. Parle à l’API pour les devis/métadonnées, parle à un RPC Solana pour les actualisations d’état avant signature.
• Registre IDL — Les IDLs Anchor pour chaque programme publié vivent dans le dépôt raydium-idl (un JSON par programme : CPMM, CLMM, LaunchLab). Le SDK TypeScript consomme ces IDLs en interne ; les clients Rust / Python en aval régénèrent à partir des mêmes fichiers.

​

6. Indexeurs et flux de prix

• L’indexeur est la seule chose qui « connaît » l’état inter-programmes. Mapper un pool CPMM à son homologue CLMM, calculer un nombre de volume sur 24h sur les versions de programme, récupérer une ferme associée à un mint LP — tout cela est du travail d’indexeur. Les programmes eux-mêmes ne le font pas.
• Le temps d’arrêt de l’indexeur est le temps d’arrêt de l’API. Si l’API retourne des données obsolètes ou vides, l’indexeur est le suspect. L’état on-chaîne n’est pas affecté ; les intégrateurs avec leur propre RPC et SDK peuvent continuer à effectuer des transactions.

​

Ce qui n’est pas partagé

• Les programmes ne s’appellent pas les uns les autres. Un swap CPMM ne fait jamais de CPI dans CLMM ou AMM v4. Le seul programme qui compose plusieurs AMMs est le programme AMM Routing — et celui-ci est lui-même mince, émettant simplement des CPIs dans chaque AMM en séquence.
• Pas d’autorité de mise à niveau partagée sur les programmes. Chaque programme on-chaîne a sa propre clé de mise à niveau de programme (un multisig 3/4 plus un verrouillage temporel de 24h). Elles ne sont pas liées.
• Pas d’état partagé entre les fermes et les AMMs. Une ferme ne sait pas si le LP qu’elle met en jeu provient d’un pool CPMM, d’un mint NFT de position CLMM ou d’un jeton SPL non lié. Le programme de ferme traite le mint de mise en jeu comme opaque.
• Pas de dépendance d’oracle. La tarification est sur les réserves on-chaîne. Il n’y a pas de secours Pyth/Switchboard ; l’AMM ne vérifie pas un oracle avant de compenser.

​

Pointeurs

• protocol-overview/architecture — le diagramme canonique montrant comment ces pièces se composent.
• protocol-overview/versions-and-migration — comment les conventions ont évolué sur les versions de programme.
• security/admin-and-multisig — qui contrôle les clés derrière les AmmConfigs.
• reference/fee-comparison — matrice des taux de frais par produit.
• reference/program-addresses — IDs de programme canoniques.

• Raydium SDK v2 — la source de vérité pour les seeds PDA, les dispositions de compte et les définitions IDL.
• Registre IDL Raydium — IDLs Anchor.
• Pages de comptes par produit citées en ligne ci-dessus.