Clés d'administration et multisig

La surface d’autorité des programmes Raydium — ce que chaque administrateur peut faire, la structure du multisig, et comment vérifier on-chain qui détient actuellement chaque rôle.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.

Voir la version anglaise →

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.

Le 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

Les farms individuelles n’ont pas d’administrateur de protocole — le créateur de chaque farm contrôle uniquement sa propre farm, et ses pouvoirs sont délimités (il ne peut pas saisir les mises des utilisateurs ni changer le mint de staking).

​

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

Les launches ne disposent d’aucun administrateur de protocole capable de modifier les courbes ou de saisir les fonds levés.

​

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.

Propriétés opérationnelles du multisig de mise à jour :

• 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>

La sortie inclut :

Program Id:          CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner:               BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority:           <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes

Si 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 ?

1. Vérifiez l’autorité de mise à jour avant toute allocation importante. Confirmez qu’elle correspond au multisig documenté.
2. 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.
3. 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.
4. 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

• reference/program-addresses — adresses d’autorité canoniques.
• security/attack-vectors — comment se manifestent les compromissions d’administrateur.
• ray/treasury — adresses de trésorerie et de collecte des frais.
• security/disclosure — signalement de problèmes d’administration suspectés.

Sources :

• Squads Protocol — interface multisig.
• Solana BPF Loader docs — mécanisme de mise à jour.