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.
Chaque programme Raydium comporte au moins un rôle privilégié — une clé capable de mettre à jour le programme, de créer de nouvelles configurations ou de retirer des frais de protocole. Limiter les prérogatives de ces rôles (et les conditionner à des multisigs avec délai) constitue la principale défense contre un administrateur compromis. Cette page recense les rôles et les mécanismes qui les sécurisent en pratique.
Rôles par programme
AMM v4
| Rôle | Adresse d’autorité | Ce qu’il peut faire |
|---|
| Mise à jour du programme | Multisig Squads (3/4) | Déployer un nouveau bytecode de programme |
| Admin de pool | Multisig trésorerie (3/5) | Basculer le statut d’un pool, mettre à jour les frais des pools existants |
CPMM
| Rôle | Adresse d’autorité | Ce qu’il peut faire |
|---|
| Mise à jour du programme | Multisig Squads (3/4) | Déployer un nouveau bytecode de programme |
| Admin AmmConfig | Multisig trésorerie (3/5) | Créer de nouveaux AmmConfigs (niveaux de frais) ; basculer les configurations existantes |
| Destinataire des frais de création de pool | Multisig trésorerie (3/5) | Recevoir les frais uniques de création de pool |
CLMM
| Rôle | Adresse d’autorité | Ce qu’il peut faire |
|---|
| Mise à jour du programme | Multisig Squads (3/4) | Déployer un nouveau bytecode de programme |
| Admin AmmConfig | Multisig trésorerie (3/5) | Créer/modifier les AmmConfigs |
| Admin DynamicFeeConfig | Multisig trésorerie (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — calibrer les niveaux de frais dynamiques qu’un appel CreateCustomizablePool peut utiliser |
limit_order_admin (à l’échelle du programme) | Portefeuille chaud opérationnel hors chaîne, pas un multisig | Régler et clore des ordres limites au nom de leurs propriétaires. La clé keeper est une constante unique à l’échelle du programme (valeur différente sur mainnet et devnet), vérifiée via signer == limit_order.owner || signer == limit_order_admin::ID sur SettleLimitOrder / CloseLimitOrder. La sortie est toujours déposée dans l’ATA du propriétaire d’origine ; le keeper ne peut pas rediriger les fonds, modifier les ordres ni en ouvrir de nouveaux. |
limit_order_admin est un rôle opérationnel délibérément limité. Il permet à un keeper hors chaîne d’exécuter des ordres remplis sans que le propriétaire de l’ordre soit en ligne. La clé keeper est chaude (elle réside sur la VM du keeper) et fait l’objet d’une rotation indépendante des multisigs ci-dessus. Concrètement, l’autorité du keeper est restreinte à :
SettleLimitOrder — transmettre la sortie remplie d’un ordre vers l’ATA du propriétaire au prix limite de l’ordre.CloseLimitOrder — clore le compte d’un ordre entièrement réglé pour récupérer le loyer (le loyer revient au propriétaire de l’ordre).
Il ne peut pas appeler OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, modifier un champ de pool, ni signer pour toute autre instruction — ces contrôles sont appliqués on-chain par les contraintes de seed et has_one dans la struct Accounts de l’instruction. Dans le pire cas, un keeper compromis peut être indisponible (les ordres restent en attente jusqu’à ce que le propriétaire les règle lui-même) ou régler/clore des ordres légitimement exécutables dans un ordre non optimal ; il ne peut en aucun cas déplacer les fonds des utilisateurs ailleurs que là où le propriétaire les a déjà autorisés.
Farm v6
| Rôle | Adresse d’autorité | Ce qu’il peut faire |
|---|
| Mise à jour du programme | Multisig Squads (3/4) | Déployer un nouveau bytecode de programme |
| Créateur de farm (par farm) | Le portefeuille créateur de la farm | Alimenter les coffres de récompenses, prolonger les calendriers, récupérer les récompenses inutilisées |
LaunchLab
| Rôle | Adresse d’autorité | Ce qu’il peut faire |
|---|
| Mise à jour du programme | Multisig Squads (3/4) | Déployer un nouveau bytecode de programme |
| Créateur de launch (par launch) | Le portefeuille créateur du launch | Collecter les frais créateur après graduation ; retirer le reliquat de courbe non graduée |
Autorité de mise à jour des programmes
Les programmes Raydium utilisent le mécanisme de mise à jour standard BPF Loader v3 de Solana. L’autorité de mise à jour de tous les programmes est le multisig Squads 3/4.
Pourquoi 3/4 : suffisamment de signataires pour qu’une seule compromission soit insuffisante, mais assez peu pour que la coordination d’une mise à jour légitime reste praticable. Les quatre autorités sont des signataires indépendants sur appareils froids à isolation réseau, détenus par des membres de l’équipe principale. La signature séquentielle empêche les approbations parallèles sur la même transaction ; les transactions comportent une fenêtre d’expiration fixe. Les opérations du multisig sont examinées périodiquement en partenariat avec le programme STRIDE de Solana (Asymmetric Research).
Suppression de l’autorité de mise à jour
Raydium n’a défini l’autorité de mise à jour d’aucun programme à null. Le protocole part du principe que les programmes doivent être évolutifs (pour corriger des bugs, ajouter des extensions comme Token-2022, résoudre des dérives d’intégration). Contrepartie : les utilisateurs font confiance au multisig 3/4 pour ne déployer que des mises à jour soigneusement vérifiées.
Pour les utilisateurs souhaitant une alternative immuable, le programme AMM v4 historique est stable depuis son dernier audit ; aucune mise à jour en 18 mois. Ce chemin de code est de fait gelé, même si l’autorité existe encore.
Autorité AmmConfig
La création de chaque nouvel AmmConfig est soumise à permission — le multisig trésorerie 3/5 autorise les nouveaux niveaux de frais et espacements de ticks. Les pools existants référencent leur AmmConfig par PDA ; le niveau de frais du pool est celui défini par l’AmmConfig.
Les administrateurs peuvent-ils modifier un AmmConfig existant ? Oui, techniquement. updateAmmConfig est appelable par l’administrateur. En pratique, les modifications apportées aux AmmConfigs déployés sont évitées, car elles changent silencieusement l’économie de tous les pools utilisant cette configuration. La politique du protocole est de créer un nouvel AmmConfig pour toute modification, puis de migrer.
Les administrateurs peuvent-ils détourner des frais de protocole via la configuration ? Non — l’AmmConfig contient des paramètres de frais mais pas le destinataire des frais de protocole ; c’est une adresse immuable distincte par pool.
Collecte des frais de protocole
Une partie des frais de swap (typiquement 3–12 bps sur 25 bps de frais de swap, selon la configuration) s’accumule dans un coffre de frais de protocole. Le multisig peut retirer ces frais accumulés. Les utilisateurs ne voient jamais leur solde LP varier de ce fait — c’est la part pré-allouée au protocole, et non l’argent des LP.
Autorité du créateur de farm
Les farms v6 donnent au créateur le pouvoir de :
- Alimenter le coffre de récompenses (ajouter des tokens).
- Prolonger le calendrier (repousser la date de fin).
- Appeler
withdrawReward après la date de fin pour récupérer le solde inutilisé du coffre.
Les créateurs de farm ne peuvent pas :
- Retirer les LP mis en staking par les utilisateurs.
- Modifier le mint de staking.
- Modifier les taux d’émission rétroactivement (uniquement de façon prospective via
setRewards).
- Bloquer les harvests des utilisateurs.
Dans le pire cas, un créateur de farm malveillant peut sous-alimenter le coffre afin que la farm s’épuise ; la mise principale des utilisateurs est toujours protégée.
Configuration du multisig Squads
Raydium opère deux multisigs Squads distincts correspondant à des surfaces de risque différentes. Les deux peuvent être inspectés on-chain via l’interface Squads Protocol.
| Multisig | Seuil | Délai | Périmètre |
|---|
| Mise à jour des programmes | 3/4 | 24 heures | Seule autorité pour déployer un nouveau bytecode pour AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap et les programmes Farm/Staking historiques. Consultable sur app.squads.so/.../FytDr…ceZQK. |
| Trésorerie | 3/5 | aucun | Actifs de trésorerie, revenus du protocole, dépenses opérationnelles. Détient également l’autorité d’administration limitée des programmes Raydium (création d’AmmConfigs, collecte des frais de protocole, configuration des paramètres de pool) pour l’instant. Consultable sur v3.squads.so/dashboard/RVha…dHdtYz09. |
- Délai de 24 heures sur toute transaction. Une mise à jour approuvée aujourd’hui n’est exécutée qu’au plus tôt 24 heures plus tard, laissant le temps aux utilisateurs de réagir.
- Signature sur appareil froid à isolation réseau. Les appareils froids ont leurs cartes réseau physiquement retirées ; ils ne se connectent qu’à un portefeuille matériel et lisent les données de transaction via QR code depuis un appareil chaud séparé.
- Signature séquentielle. Ce n’est qu’après qu’un appareil froid a généré et signé une transaction que l’appareil froid suivant peut commencer son processus de signature — ce qui empêche les signatures conflictuelles ou parallèles sur la même transaction.
- Expiration des transactions. Chaque transaction comporte une fenêtre d’expiration fixe, de sorte que les transactions obsolètes sont automatiquement invalidées.
- Application de TOTP + clé physique sur les appareils chauds utilisés pour l’initiation des transactions et la diffusion on-chain.
- File de transactions publique. Tout le monde peut surveiller les mises à jour en attente via l’interface Squads.
Le multisig de trésorerie ne comporte pas de délai — son périmètre est plus restreint et les opérations courantes (création d’AmmConfigs, collecte des frais) doivent être traitées le jour même. Le multisig de trésorerie détient également l’autorité d’administration limitée des programmes listée dans les tableaux par programme ci-dessus ; il s’agit d’une disposition provisoire, réexaminée périodiquement avec les partenaires de sécurité du projet.
Vérification de l’autorité on-chain
La façon la plus simple de vérifier l’autorité de mise à jour actuelle d’un programme :
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority ne correspond pas à l’adresse du multisig Squads attendue, quelque chose ne va pas. Raydium publie les adresses d’autorité attendues sur reference/program-addresses.
Pour les rôles AmmConfig / admin de pool, récupérez le compte on-chain et décodez :
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Expected: 3/5 treasury multisig.
Historique des changements d’autorité
| Date | Programme | Modification |
|---|
| 2022-12 | AMM v4 | Autorité de mise à jour migrée d’une signature unique vers un multisig 3/4 après incident |
| 2023-02 | Tous les programmes | Tous les rôles opérationnels regroupés sous le multisig trésorerie 3/5 |
| 2023-11 | CLMM | Ajout d’un second multisig dédié aux opérations de récompense uniquement, pour réduire l’exposition |
| 2024-05 | CPMM | Déploiement initial avec autorité multisig dès le premier jour |
Considérations côté utilisateur
Que faire en tant qu’utilisateur, LP ou intégrateur ?
- Vérifiez l’autorité de mise à jour avant toute allocation importante. Confirmez qu’elle correspond au multisig documenté.
- Surveillez l’activité du multisig. L’interface Squads affiche les transactions en attente ; une mise à jour programmée vous donne 24 heures pour déboucler votre position si vous n’approuvez pas le changement.
- Stratégies de sortie tenant compte du délai. Si vous gérez un auto-compounder, assurez-vous que votre chemin de sortie ne nécessite pas une instruction en cours de modification.
- Ne supposez pas l’immuabilité des programmes. Tous les programmes Raydium peuvent être mis à jour ; anticipez-le.
Pièges pour les intégrateurs
1. Mise en cache des adresses d’autorité
Si vous codez en dur l’autorité de mise à jour ou l’adresse du multisig administrateur dans votre code et qu’elle est ensuite modifiée, votre vérification échouera. Récupérez-la depuis reference/program-addresses au moment de l’exécution ou actualisez-la périodiquement.
2. Supposer que les AmmConfigs sont stables
Un nouvel AmmConfig peut être créé à tout moment. Votre agrégateur/routeur devrait récupérer la liste complète des configurations périodiquement (toutes les heures convient).
3. Vecteurs de nuisance du créateur de farm
Si vous déposez dans une farm à faible réputation, le créateur pourrait mettre fin à la farm prématurément et récupérer le coffre de récompenses (à condition qu’aucun utilisateur n’ait encore mis en staking). Une fois que des utilisateurs ont mis en staking, les droits au prorata sont appliqués par le programme ; la récupération ne porte que sur le reliquat après une fin normale.
Références
Sources :
