Clés d'administration et multisig

La surface d’autorité dans les programmes Raydium — ce que chaque administrateur peut faire, comment le multisig est structuré, 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 dispose d’au moins un rôle privilégié — une clé qui peut mettre à niveau le programme, créer de nouvelles configurations, ou 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

Rôle	Adresse d’autorité	Ce qu’il peut faire
Mise à niveau du programme	Multisig Squads (3/4)	Déployer le nouveau bytecode du programme
Administrateur du pool	Multisig Trésor (3/5)	Basculer l’état du pool, mettre à jour les frais sur les pools existants

​

CPMM

Rôle	Adresse d’autorité	Ce qu’il peut faire
Mise à niveau du programme	Multisig Squads (3/4)	Déployer le nouveau bytecode du programme
Administrateur AmmConfig	Multisig Trésor (3/5)	Créer de nouvelles AmmConfigs (niveaux de frais) ; basculer les existantes
Destinataire des frais de création de pool	Multisig Trésor (3/5)	Recevoir les frais uniques de création de pool
Créateur de Permission-PDA	admin du programme ou un propriétaire dédié de création de permission-PDA (valeur différente sur mainnet vs devnet)	Appeler CreatePermissionPda pour accorder à une autorité l’accès à InitializeWithPermission. Depuis la mise à niveau 2026-09, le propriétaire dédié peut également appeler ClosePermissionPda, il accorde et révoque donc ; avant cette mise à niveau, la révocation était réservée à l’administrateur.

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

Rôle	Adresse d’autorité	Ce qu’il peut faire
Mise à niveau du programme	Multisig Squads (3/4)	Déployer le nouveau bytecode du programme
Administrateur AmmConfig	Multisig Trésor (3/5)	Créer/modifier les AmmConfigs
Administrateur DynamicFeeConfig	Multisig Trésor (3/5)	CreateDynamicFeeConfig / UpdateDynamicFeeConfig — calibrer les niveaux de frais dynamiques qu’un appel CreateCustomizablePool peut choisir
Collecteur de lamports excédentaires	admin du programme ou un portefeuille dédié de collecte de lamports (valeur différente sur mainnet vs devnet)	CollectExcessLamports : balayer les lamports au-dessus du minimum exempt de loyer depuis le PoolState d’un pool et ses coffres, plus tous les PDA appartenant à CLMM transmis. Déplace uniquement les lamports, jamais les soldes de jetons, et ne peut pas fermer les comptes. Ajouté 2026-09-30.
limit_order_admin (au niveau du programme)	Portefeuille opérationnel chaud hors-chaîne, pas un multisig	Régler et fermer les ordres limites au nom de leurs propriétaires. La clé du gardien est une constante unique au niveau du programme (valeur différente sur mainnet vs devnet), vérifiée via signer == limit_order.owner || signer == limit_order_admin::ID sur SettleLimitOrder / CloseLimitOrder. La sortie atterrit toujours dans l’ATA du propriétaire original ; le gardien ne peut pas rediriger les fonds, modifier les ordres, ou en ouvrir de nouveaux.

Créer des pools supplémentaires pour une paire à une adresse dérivée de seed_index (CreateCustomizablePoolV2) ne nécessite aucun rôle. Avant la mise à niveau 2026-10-22, cela nécessitait un PDA Permission émis par une clé permission_pda_admin dédiée ; ce rôle, le compte Permission et ses deux instructions d’administration ont été supprimés.

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).

Il ne peut pas appeler OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, muter aucun champ de pool, ou signer pour aucune 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 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

Rôle	Adresse d’autorité	Ce qu’il peut faire
Mise à niveau du programme	Multisig Squads (3/4)	Déployer le nouveau bytecode du programme
Créateur de farm (par farm)	Le portefeuille du créateur de la farm	Financer 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 — 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

Rôle	Adresse d’autorité	Ce qu’il peut faire
Mise à niveau du programme	Multisig Squads (3/4)	Déployer le nouveau bytecode du programme
Administrateur du programme	Administrateur Raydium partagé	Créer et mettre à jour les comptes GlobalConfig ; opérer d’autres chemins réservés à l’administrateur
Créateur de config délégué	Autorité spécifique au cluster dédiée	Créer une nouvelle GlobalConfig ; ne peut pas mettre à jour une config existante
Administrateur de plateforme	Autorité de seed PDA pour une PlatformConfig	Mettre à jour les paramètres de la plateforme et créer ou fermer les comptes PlatformAllowConfig de cette plateforme
Créateur de lancement (par lancement)	Le portefeuille du créateur du lancement	Réclamer les frais du créateur de courbe de liaison ; reçoit les droits de frais du créateur CPMM uniquement lorsque la plateforme ne remplace pas platform_cp_creator

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 n’accorde 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 des 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 Programme STRIDE 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 bogues, 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.

Aucun programme Raydium n’est actuellement gelé ou suffisamment statique pour être traité comme une alternative immuable — AMM v4, historiquement le plus statique d’entre eux, a lui-même été redéployé le 2026-07-22. Le slot du dernier déploiement pour chaque programme est public ; consultez-le avant de supposer que l’un d’eux est dormant :

Programme	Dernier déploiement (mainnet)
LaunchLab	2026-09-02
CPMM / CLMM / AMM Routing	2026-08-17
AMM v4	2026-07-22
Stable AMM	2026-06-22
Lock (Burn & Earn)	2025-08-23
Farm v6	2024-05-13

(À partir du compte ProgramData de chaque programme ; solana program show <PROGRAM_ID> rapporte le même slot.)

​

Autorité AmmConfig

Chaque création de nouvelle AmmConfig est permissionnée — le multisig 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 config. 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 config ? 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 config) 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 withdrawReward après l’heure de fin pour récupérer le solde inutilisé du coffre.

Les créateurs de farm ne peuvent pas :

• Retirer les LP mis en jeu par l’utilisateur.
• Changer le mint de mise en jeu.
• Changer les taux d’émission rétroactivement (uniquement prospectif via setRewards).
• Geler les récoltes des utilisateurs.

Un créateur de farm malveillant peut au pire sous-financer le coffre pour que la farm s’épuise ; la mise en jeu principale de l’utilisateur est toujours sûre.

​

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 Protocole Squads.

Multisig	Seuil	Timelock	Portée
Mise à niveau du programme	3/4	24 heures	Seule autorité pour déployer le nouveau bytecode du programme pour AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap, et les programmes Farm/Staking hérités. Voir à app.squads.so/.../FytDr…ceZQK.
Trésor	3/5	aucun	Actifs du trésor, revenus du protocole, dépenses opérationnelles. Détient également l’autorité limitée d’administrateur de programme de Raydium (créer des AmmConfigs, balayer les frais de protocole, configurer les paramètres du pool) pour le moment. Voir à v3.squads.so/dashboard/RVha…dHdtYz09.

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’invalident automatiquement.
• Application TOTP + clé physique sur les appareils chauds utilisés pour l’initiation de la 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.

Le multisig trésor n’a pas de timelock — sa portée est plus étroite et les opérations de routine (créer des AmmConfigs, balayer les frais) doivent atterrir le même jour. Le multisig trésor détient également l’autorité limitée d’administrateur de programme énumérée dans les tableaux par programme ci-dessus ; c’est un arrangement intérimaire et est examiné périodiquement avec les partenaires de sécurité du projet.

​

Vérifier l’autorité on-chain

Le moyen le plus simple de vérifier l’autorité de mise à jour actuelle d’un programme :

solana program show <PROGRAM_ID>

La sortie inclut :

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

Si Authority n’est pas l’adresse 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-le :

import { CpmmConfigInfoLayout } from "@raydium-io/raydium-sdk-v2";

const info = await connection.getAccountInfo(configPda);
const config = CpmmConfigInfoLayout.decode(info!.data);
console.log("protocol owner:", config.protocolOwner.toBase58());
console.log("fund owner:",     config.fundOwner.toBase58());

AmmConfig n’a pas de champ admin — l’administrateur du programme est une clé publique compilée dans le programme (crate::admin::ID), et les autorités opérationnelles par configuration sont protocolOwner / fundOwner. L’autorité de mise à jour BPF est une préoccupation distincte au niveau du chargeur ; lisez-la avec solana program show.

​

Historique des changements d’autorité

Date	Programme	Changement
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 unifiés sous un multisig trésorier 3/5
2023-11	CLMM	Ajout d’un second multisig pour les opérations de récompense uniquement afin de réduire l’exposition
2024-05	CPMM	Déploiement initial avec autorité multisig dès le premier jour

​

Considérations côté utilisateur

Que devez-vous faire en tant qu’utilisateur/LP/intégrateur ?

1. Vérifiez l’autorité de mise à jour avant les allocations importantes. 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 vous retirer si vous n’êtes pas d’accord avec le changement.
3. Stratégies de rachat conscientes du time-lock. Si vous exécutez un auto-compounder, assurez-vous que votre chemin de retrait ne nécessite pas une instruction en cours de modification.
4. Ne supposez pas l’immuabilité du programme. Chaque programme Raydium peut être mis à jour ; planifiez en conséquence.

​

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 change ultérieurement, votre vérification échoue. Récupérez depuis reference/program-addresses à l’exécution ou actualisez périodiquement.

​

2. Supposer que les AmmConfigs sont stables

Un nouvel AmmConfig peut être créé à tout moment. Votre agrégateur/routeur doit récupérer la liste complète des configurations périodiquement (toutes les heures, c’est acceptable).

​

3. Vecteurs de grief du créateur de farm

Si vous déposez dans une farm de faible réputation, le créateur pourrait terminer la farm plus tôt et récupérer le coffre de récompense (en supposant qu’aucun utilisateur n’ait encore misé). Une fois que les utilisateurs ont misé, les droits au prorata sont appliqués par le programme ; la récupération n’obtient que le reste après la fin rationnelle.

​

Références

• reference/program-addresses — adresses d’autorité canoniques.
• security/attack-vectors — comment les compromis administrateur se manifestent.
• ray/treasury — adresses du trésor et de collecte des frais.
• security/disclosure — signalement des problèmes administrateur suspects.

Sources :

• Squads Protocol — interface multisig.
• Documentation Solana program & loader — le mécanisme de mise à jour et comment révoquer l’autorité de mise à jour rend un programme immuable.