Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Chaque programme Raydium dispose d’au moins un rôle privilégié — une clé capable de mettre à niveau le programme, de créer de nouvelles configurations, ou de retirer les frais de protocole. Minimiser ce que ces rôles peuvent faire (et les placer derrière des multisigs avec délais) est la défense principale contre un administrateur compromis. Cette page énumère les rôles et comment ils sont sécurisés en pratique.
Rôles par programme
AMM v4
CPMM
La collecte des frais du créateur n’introduit pas de rôle privilégié.
CollectCreatorFeePermissionless accepte n’importe quel payeur, contraint le propriétaire du destinataire à PoolState.pool_creator, et contraint les deux destinations aux ATA canoniques de ce créateur. Un appelant peut financer les ATA manquantes et déclencher le balayage mais ne peut pas rediriger les frais.
CLMM
Détenir une PDA
Permission permet à son autorité d’appeler CreatePermissionedPool — créer des pools supplémentaires pour une paire qui en a déjà un canonique, chacun à une adresse dérivée d’un seed_index distinct. La permission est limitée à la création de pool uniquement : elle ne peut pas déplacer les fonds, modifier les frais, ou toucher à un pool existant. La révoquer (ClosePermissionPda) empêche l’autorité de créer d’autres pools mais laisse les pools déjà créés intacts.
Le limit_order_admin est un rôle opérationnel délibérément étroit. Il existe pour qu’un gardien hors-chaîne puisse balayer les ordres remplis sans que le propriétaire de l’ordre doive être en ligne. La clé du gardien est chaude (réside sur la VM du gardien) et est tournée indépendamment des multisigs ci-dessus. Concrètement, l’autorité du gardien est limitée à :
SettleLimitOrder— pousser la sortie remplie d’un ordre vers l’ATA du propriétaire au prix limite de l’ordre.CloseLimitOrder— fermer le compte d’un ordre entièrement réglé pour récupérer le loyer (le loyer va au propriétaire de l’ordre).
OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, muter aucun champ de pool, ou signer pour toute autre instruction — ces vérifications sont appliquées on-chain par les contraintes de seed et has_one dans la struct Accounts de l’instruction. Un gardien compromis peut au pire être indisponible (les ordres restent garés jusqu’à ce que le propriétaire les règle lui-même) ou régler/fermer les ordres légitimement remplissables hors d’ordre ; il ne peut pas déplacer les fonds des utilisateurs ailleurs que là où le propriétaire les a déjà autorisés.
Farm v6
Les farms individuelles n’ont pas d’administrateur de protocole — chaque créateur de farm contrôle uniquement sa farm, et les pouvoirs du créateur sont limités (ne peut pas saisir les mises en jeu des utilisateurs, ne peut pas changer le mint de mise en jeu).
LaunchLab
La liste d’autorisation de l’administrateur de plateforme s’auto-restreint : elle limite les comptes
GlobalConfig que les lancements sous cette plateforme peuvent utiliser. Elle ne confère pas d’autorité sur d’autres plateformes ou les fonds de lancement existants. Les adresses d’autorité déléguées canoniques se trouvent dans reference/program-addresses.
Autorité de mise à niveau du programme
Les programmes Raydium utilisent le mécanisme de mise à niveau standard de Solana BPF Loader v3. L’autorité de mise à niveau pour tous les programmes est le multisig Squads 3/4. Pourquoi 3/4 : assez de signataires pour qu’un seul compromis soit insuffisant ; assez peu pour que la coordination d’une mise à niveau légitime soit traitable. Les quatre autorités sont indépendantes, des signataires sur appareils froids isolés du réseau détenus par les membres de l’équipe principale. La signature séquentielle empêche les approbations parallèles sur la même transaction ; les transactions ont une fenêtre d’expiration fixe. Les opérations multisig sont examinées périodiquement en partenariat avec le STRIDE Program de Solana (Asymmetric Research).Suppression de l’autorité de mise à niveau
Raydium n’a défini l’autorité de mise à niveau d’aucun programme à null. Le protocole fonctionne selon le principe que les programmes doivent être mises à niveau (pour corriger les bugs, ajouter des extensions comme Token-2022, corriger la dérive d’intégration). Compromis : les utilisateurs font confiance au fait que le multisig 3/4 ne déploiera que des mises à niveau bien examinées. Pour les utilisateurs qui veulent une alternative immuable, le programme AMM v4 plus ancien est stable depuis son dernier audit ; zéro mise à niveau en 18 mois. Ce chemin de code est effectivement gelé même si l’autorité existe toujours.Autorité AmmConfig
Chaque création de nouvelle AmmConfig est autorisée — le multisig du trésor 3/5 autorise les nouveaux niveaux de frais et espacements de tick. Les pools existants référencent leur AmmConfig par PDA ; le niveau de frais du pool est ce que dit l’AmmConfig. Les administrateurs peuvent-ils modifier une AmmConfig existante ? Oui, techniquement.updateAmmConfig est appelable par l’administrateur. En pratique, les modifications des AmmConfigs déployées sont évitées car cela change silencieusement l’économie de tous les pools utilisant cette configuration. La politique du protocole est de créer une nouvelle AmmConfig pour tout changement et de migrer.
Les administrateurs peuvent-ils voler les frais de protocole via la configuration ? Non — l’AmmConfig contient les paramètres de frais mais pas le destinataire des frais de protocole ; c’est une adresse immuable séparée par pool.
Réclamation des frais de protocole
Une portion des frais de swap (généralement 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 changer à cause de cela — c’est la part pré-allouée du protocole, pas l’argent des LP.Autorité du créateur de farm
Les Farms v6 donnent au créateur le pouvoir de :- Financer le coffre de récompenses (ajouter plus de jetons).
- Prolonger le calendrier (repousser l’heure de fin plus tard).
- Appeler
withdrawRewardaprès l’heure de fin pour récupérer le solde inutilisé du coffre.
- Retirer les LP mis en jeu par les utilisateurs.
- Changer le mint de mise en jeu.
- Changer les taux d’émission rétroactivement (uniquement prospectif via
setRewards). - Geler les récoltes des utilisateurs.
Configuration du multisig Squads
Raydium opère deux multisigs Squads séparés pour des surfaces de risque distinctes. Les deux peuvent être inspectés on-chain via l’interface utilisateur du Squads Protocol.
Propriétés opérationnelles du multisig de mise à niveau :
- Timelock de 24 heures sur toute transaction. Une mise à niveau approuvée aujourd’hui s’exécute au plus tôt 24 heures plus tard, donnant aux utilisateurs le temps de réagir.
- Signature sur appareils froids isolés du réseau. Les appareils froids ont les cartes réseau physiquement retirées ; ils se connectent uniquement à un portefeuille matériel et lisent les données de transaction via code QR à partir d’un appareil chaud séparé.
- Signature séquentielle. Ce n’est qu’après qu’un appareil froid génère et signe une transaction que l’appareil froid suivant peut commencer son processus de signature — empêchant les signatures conflictuelles ou parallèles sur la même transaction.
- Expiration de la transaction. Chaque transaction porte une fenêtre d’expiration fixe, donc les transactions obsolètes s’auto-invalident.
- Application TOTP + clé physique sur les appareils chauds utilisés pour l’initiation de transaction et la diffusion on-chain.
- File d’attente de transaction publique. N’importe qui peut surveiller les mises à niveau en attente sur l’interface utilisateur de Squads.
Vérification de l’autorité on-chain
Le moyen le plus simple de vérifier l’autorité de mise à niveau actuelle d’un programme :Authority n’est 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 d’administrateur AmmConfig / pool, récupérez le compte on-chain et décodez :
Changements d’autorité historiques
Considérations côté utilisateur
Que devriez-vous faire en tant qu’utilisateur/LP/intégrateur ?- Vérifiez l’autorité de mise à niveau avant les allocations importantes. Confirmez qu’elle correspond au multisig documenté.
- Surveillez l’activité du multisig. L’interface utilisateur de Squads affiche les transactions en attente ; une mise à niveau programmée vous donne 24 heures pour vous retirer si vous n’êtes pas d’accord avec le changement.
- Stratégies de rachat conscientes du timelock. Si vous exécutez un auto-compounder, assurez-vous que votre chemin de retrait ne nécessite pas une instruction qui est en cours de modification.
- Ne supposez pas l’immuabilité du programme. Chaque programme Raydium peut être mis à niveau ; planifiez-le.
Pièges pour les intégrateurs
1. Mise en cache des adresses d’autorité
Si vous codez en dur l’autorité de mise à niveau ou l’adresse du multisig administrateur dans votre code et qu’elle tourne plus tard, votre vérification échoue. Récupérez à partir dereference/program-addresses à l’exécution ou actualisez périodiquement.
2. Supposer que les AmmConfigs sont stables
Une nouvelle AmmConfig peut être créée à tout moment. Votre agrégateur/routeur devrait re-récupérer la liste complète de la configuration périodiquement (toutes les heures c’est bien).3. Vecteurs de chagrin du créateur de farm
Si vous déposez dans une farm de faible réputation, le créateur pourrait terminer la farm tôt et récupérer le coffre de récompenses (en supposant qu’aucun utilisateur n’ait misé). Une fois que les utilisateurs ont misé, les droits pro-rata sont appliqués par le programme ; la récupération n’obtient que le reste après la fin rationnelle.Pointeurs
reference/program-addresses— adresses d’autorité canoniques.security/attack-vectors— comment les compromis d’administrateur se manifestent.ray/treasury— adresses du trésor et de collecte des frais.security/disclosure— signaler les problèmes d’administrateur suspectés.
- Squads Protocol — interface utilisateur multisig.
- Solana BPF Loader docs — mécanisme de mise à niveau.