Passer au contenu principal

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.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Les audits détectent certaines classes de bugs (motifs d’attaque connus, erreurs de contrôle d’accès, débordements d’entiers) et en manquent d’autres (défauts de conception économique, manipulation théorique des jeux, bugs d’intégration avec d’autres programmes). Les programmes de Raydium subissent plusieurs rounds d’audits chacun ; cette page les énumère et discute de ce que chaque audit a réellement vérifié.

​
Tableau d’audit par programme

ProgrammeAuditeurDateRapport
Order-book AMMKudelski SecurityQ2 2021Voir
Concentrated liquidity (CLMM)OtterSecQ3 2022Voir
Updated order-book AMMOtterSecQ3 2022Voir
StakingOtterSecQ3 2022Voir
Order-book AMM & OpenBook migrationMadShieldQ2 2023Voir
Constant-product AMM (CPMM)MadShieldQ1 2024Voir
Burn & Earn (liquidity locker)HalbornQ4 2024Voir
LaunchLabHalbornQ2 2025Voir
CPMM (update)Sec3Q3 2025Voir
CLMM update — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Voir
Des membres de l’équipe de Neodyme ont également effectué des revues étendues via des accords de bug-bounty. Tous les rapports d’audit pour les programmes Raydium sont disponibles en miroir sous github.com/raydium-io/raydium-docs/audit/. Chaque auditeur publie également sur son propre site.

​
Ce que les audits couvrent

Un audit Raydium typique (~3–6 semaines, 2 auditeurs) couvre :
  • Contrôle d’accès — chaque opération privilégiée est-elle correctement protégée ?
  • Arithmétique — débordements, soustractions négatives, direction d’arrondi, précision du point fixe.
  • Validation des comptes — chaque compte a-t-il le bon propriétaire, la bonne mint, la bonne autorité ?
  • Motifs de type réentrance — l’état est-il mis à jour avant ou après un CPI ?
  • Dérivation des PDA — les seeds sont-elles cohérentes partout ?
  • Codes et messages d’erreur — les conditions d’erreur reviennent-elles proprement ?
  • Qualité du code — Rust idiomatique, code mort, branches inaccessibles.

​
Ce que les audits ne couvrent pas

  • Théorie économique des jeux — par exemple « si je peux créer 1000 pools gratuitement, puis-je harceler le routeur ? »
  • MEV / ordonnancement — attaques sandwich, front-running via collusion de validateurs.
  • Infrastructure hors chaîne — fiabilité du RPC, exactitude de l’indexeur, interface Web.
  • Intégrations avec d’autres programmes — bugs qui ne se manifestent que lors de composition avec des contrats de prêt, d’options ou d’agrégateur spécifiques.
  • Comportements émergents au fil du temps — que se passe-t-il après 10 millions de positions ? Les audits examinent des cas de test à petite échelle.
C’est pourquoi audit ≠ garantie de sécurité. Raydium complète les audits par des bug-bounties, une surveillance et une ingénierie défensive.

​
Statut de résolution des findings

Chaque audit produit une liste de findings (critique / élevée / moyenne / basse / informationnelle), avec des comptes de sévérité et un statut par finding (Fixé / Reconnu / Ne sera pas corrigé). Les ventilations par finding ne sont pas dupliquées ici — lisez chaque rapport directement via le tableau ci-dessus.

​
Ré-audit après changements significatifs

Lorsqu’un programme déploie une mise à jour significative (nouvelle instruction, nouveau champ de compte, nouveau support d’extension), Raydium commande une ré-audit. L’examen Sec3 Q3 2025 du CPMM et l’examen Sec3 Q2 2026 du CLMM (Limit Order, Dynamic Fee, Single Asset Fee) listés dans le tableau ci-dessus sont tous deux des ré-audits de ce type. Le périmètre du ré-audit est plus restreint (juste la différence), mais c’est véritablement un ré-audit — pas simplement une revue de code. Les rapports des ré-audits sont ajoutés au rapport d’audit principal.

​
Vérification on-chain

Le hash du programme déployé doit correspondre au hash du code audité. N’importe qui peut vérifier : 
# Récupère le bytecode du programme déployé.
solana program dump <PROGRAM_ID> program.so

# Construit le repo au commit audité.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# Compare.
sha256sum program.so target/deploy/raydium_cp_swap.so
Les builds Anchor vérifiables produisent du bytecode déterministe ; les hashes doivent correspondre exactement. S’ils ne correspondent pas, le programme déployé n’est pas celui audité — escaladez. Raydium publie les hashes attendus par déploiement dans la section releases du repo.

​
Comment lire un rapport d’audit

Un court guide pour les non-auditeurs :
  1. Allez directement au résumé des findings — un tableau des comptes de sévérité. Si le compte « Critique » est > 0 et vous voyez un statut « Ouvert », creusez.
  2. Lisez la description et le statut de chaque finding. « Fixé dans le commit XYZ » signifie résolu ; « Reconnu » signifie que l’équipe a accepté le risque ; « Partiellement fixé » mérite un examen plus attentif.
  3. Scannez la section périmètre. Si l’audit n’a pas couvert l’instruction ou le compte qui vous intéresse, l’absence de findings là-bas n’est pas une preuve de sécurité.
  4. Parcourez la section recommandations de l’auditeur. Souvent plus utile que les findings — met en surface les notes « nous ne pouvons pas le prouver formellement mais nous sommes mal à l’aise ».

​
Intégration des bug-bounties

Les audits s’exécutent avant le déploiement ; les bug-bounties s’exécutent continuellement après le déploiement. Le programme de bounty de Raydium (security/disclosure) couvre tout ce que les audits couvrent plus :
  • Les attaques économiques que les audits ne couvrent pas.
  • Les bugs trouvés dans les nouvelles intégrations.
  • Les bugs d’implémentation dans les SDK et les composants hors-chaîne.
Une découverte whitehat dans le programme de bounty est généralement payée plus rapidement que d’attendre le prochain cycle d’audit ; les incitations sont alignées pour une divulgation rapide. Le programme actif est hébergé sur Immunefi : immunefi.com/bug-bounty/raydium/information.

​
Incidents historiques

Les programmes de Raydium ont eu deux incidents remarquables dans le monde réel :

​
Exploit de l’autorité du pool (décembre 2022)

Quoi : La clé privée de l’autorité du pool AMM v4 a été compromise, permettant à un attaquant de drainer plusieurs pools. Périmètre : Gestion opérationnelle des clés, pas un bug du programme. L’audit n’avait pas signalé le code puisque le code était correct ; le processus de gestion des clés était l’échec. Correction : Migration multisig (tous les rôles d’autorité ont été déplacés vers le multisig Squads) ; contrôles opérationnels supplémentaires. Leçon : Les audits ne couvrent pas la gestion des clés. Voir security/admin-and-multisig.

​
Gel de l’intégration OpenBook (janvier 2023)

Quoi : Une mise à jour du programme OpenBook a changé la sémantique des comptes ; le crank MonitorStep d’AMM v4 ne pouvait pas régler le PnL jusqu’à ce qu’un patch AMM v4 soit déployé. Périmètre : Bug d’intégration — aucun programme n’était incorrect isolément. Correction : Patch AMM v4 et déploiement coordonné. Leçon : Les audits du programme A ne détectent pas les bugs dans l’intégration du programme A avec le programme B. L’outil approprié est le test d’intégration + les déploiements par étapes.

​
Références

Sources :