Vecteurs d'attaque

Un AMM est une cible alléchante pour du code malveillant : les fonds des LP sont dans des pools entièrement visibles ; chaque swap change le prix de manière déterministe. Cette page catalogue les classes d’attaques qui ont été démontrées contre les AMM, comment elles s’appliquent à Raydium spécifiquement, et ce que Raydium (et les intégrateurs) font pour se défendre.

​

1. Attaques sandwich / MEV

​

Attaque

Un bot surveille le mempool / flux de gossip, voit un swap d’un utilisateur, le devance avec un achat dans la même direction (poussant le prix), laisse la transaction de l’utilisateur s’exécuter à un prix pire, puis la suit avec une vente opposée. Le bot profite du spread.

​

Exposition

• Plus exposé : pools CPMM à faible TVL et pools AMM v4 — même les petits trades bougent le prix de manière significative.
• Moins exposé : pools CLMM profondes — les trades intra-tick ne bougent pas le prix.
• Non exposé : récoltes de fermes, dépôts LP (ratio appliqué, non sensible au prix de la même manière).

​

Défenses

• Bundles Jito (integration-guides/routing-and-mev) cachent la transaction du mempool public.
• Slippage serré — minimum-out plus proche de l’attendu rend les sandwiches non rentables. En dessous d’environ 0,3 %, la plupart des sandwiches perdent de l’argent.
• Tailles de trade plus petites — divisez un swap de $100k en 10× $10k ; chacun bouge le prix moins.

​

Position de Raydium

Les programmes principaux de Raydium n’appliquent pas de protections anti-MEV — ils sont neutres au niveau du programme. La protection se fait au niveau de la soumission (Jito, protection intégrée des portefeuilles). L’interface par défaut fixe le slippage à 0,5 % ce qui est raisonnable pour la plupart des pools.

​

2. Manipulation de prix

​

Attaque

Un grand trader bouge temporairement le prix d’un pool (par un flash loan ou auto-financé), déclenche une action en aval qui dépend du prix (une liquidation, un emprunt dérivé du prix, un paiement de dérivé), puis ramène le prix à la normale.

​

Exposition

• Opérations Raydium natives : non exposé. Un swap spot aller-retour n’encourt que des frais aller-retour ; le trader perd de l’argent.
• Programmes intégrés : exposé s’ils lisent naïvement le prix du pool Raydium.

​

Défenses

• Utilisez les TWAP, pas les prix spot, pour la composabilité (voir security/oracle-and-token-risks).
• CLMM ObservationState donne un TWAP à court terme qui n’est pas manipulable sans engagement de capital soutenu.
• Consensus multi-oracle : si votre programme lit Raydium et Pyth et Jupiter et n’agit que quand ils s’accordent à 1 %, la manipulation par flash-loan d’une seule source ne suffit pas.

​

Position de Raydium

CLMM expédie le support TWAP ObservationState ; les intégrateurs qui l’ignorent et utilisent les prix spot sont livrés à eux-mêmes. L’interface de Raydium utilise plusieurs sources de prix pour l’affichage en USD.

​

3. Attaques par donation / inflation

​

Attaque

Le premier LP dans un nouveau pool dépose une petite quantité (par exemple, 1 token chacun de 6 mints décimaux → 1 unité de LP émise). Ensuite, l’attaquant « donne » 1 000 000 tokens directement au vault du pool via un transfert SPL Token. Maintenant 1 unité LP représente 500 000 de chaque mint. Tout LP ultérieur déposant moins que cela est arrondi à 0 unité LP et perd son dépôt.

​

Exposition

• CPMM / AMM v4 : potentiellement exposé sur les pools nouvellement créés à faible liquidité.
• CLMM : non exposé (pas de mint LP partagé ; chaque position est son propre NFT avec valeur de liquidité explicite).

​

Défenses

L’instruction initialize de CPMM verrouille un montant LP minimum au pool (inspiré par le modèle MINIMUM_LIQUIDITY d’Uniswap V2). Cela signifie que le premier LP reçoit sqrt(x × y) - MINIMUM_LIQUIDITY, avec le MINIMUM_LIQUIDITY (1000 unités) brûlé à null. Une attaque par donation nécessite que l’attaquant donne >> le dépôt initial, ce qui devient non économique. De plus, le SDK de Raydium avertit fortement quand le dépôt initial est minuscule et guide les utilisateurs vers des montants sensés.

​

Position de Raydium

Le verrouillage MINIMUM_LIQUIDITY est expédié dans CPMM ; AMM v4 a un mécanisme similaire. Les utilisateurs créant des pools devraient ensemencer avec au moins 10 000+ unités de chaque mint pour rendre les attaques par donation non économiques de toute façon.

​

4. Abus de transfer-hook Token-2022

​

Attaque

Le hook de transfert d’un mint est modifiable. L’attaquant déploie un hook innocent au lancement du mint, se fait lister sur Raydium, accumule des LP des utilisateurs. Plus tard, met à niveau le hook pour bloquer tous les transferts (effectivement un soft-rug — les utilisateurs ne peuvent pas se retirer). L’attaquant rend le pool tradeable dans une seule direction, achète des LP bon marché, déverrouille les hooks, gagne.

​

Exposition

Pools qui incluent un mint avec transfer-hook.

​

Défenses

• Niveau programme : les programmes Raydium invoquent le hook pendant les swaps ; si le hook bloque, le swap revient. Cela n’empêche pas l’attaque mécaniquement.
• Niveau UI : Raydium signale les pools avec des mints transfer-hook.
• Niveau intégrateur : les agrégateurs devraient ignorer les mints transfer-hook par défaut et ne lister que les hooks vérifiés.

​

Position de Raydium

Raydium ne bannit pas les pools transfer-hook (les hooks légitimes existent), mais les étiquette clairement. Les agrégateurs filtrant sur tags.includes("TRANSFER_HOOK") peuvent exclure si désiré.

​

5. Exploits de composabilité / CPI

​

Attaque

Un programme compose Raydium via CPI et introduit un bug : par exemple, il passe le mauvais observation_state, les mauvais tick arrays pour un swap CLMM, ou double-dépense un compte. L’attaquant identifie la composition bugguée et l’exploite.

​

Exposition

• L’intégrateur bugué — généralement la source du bug.
• Raydium — seulement si le bug déclenche un comportement involontaire dans les programmes Raydium eux-mêmes.

​

Exemples historiques

Aucun des programmes de Raydium n’a été exploité via CPI — les validateurs de compte de Raydium attrapent les comptes mal formés et reviennent. Les exploits dans l’écosystème plus large se sont produits via des bugs de programme personnalisé qui composaient avec un AMM mais ne provenaient pas de l’AMM.

​

Défenses

• Les programmes appelants devraient utiliser les helpers CPI Anchor (pas les instructions construites à la main) quand possible — la sécurité des types attrape la plupart des abus.
• Les tests d’intégration contre l’état forké du mainnet couvrent les cas de composition.

​

6. Compromission d’admin / clé

​

Attaque

Une clé d’admin (autorité de mise à niveau, admin AmmConfig, réclamation de frais de protocole) est compromise. L’attaquant déploie une mise à niveau malveillante qui draine les pools, ou modifie les AmmConfigs pour router les frais vers un portefeuille d’attaquant, ou draine les frais de protocole.

​

Exposition

Tous les rôles documentés dans security/admin-and-multisig.

​

Défenses

• Multisig 3/4 sur l’autorité de mise à niveau nécessite de compromettre 4 signataires indépendants.
• Timelock de 24 heures sur les mises à niveau donne aux utilisateurs le temps de se retirer avant qu’une mise à niveau malveillante s’active.
• Surveillance opérationnelle — alertes sur toute activité multisig via la file d’attente publique de Squads.

​

Incident historique

La clé d’autorité du pool AMM v4 a été compromise en décembre 2022 (pré-multisig). Correction : déplacement de toute l’autorité vers le multisig Squads. Post-correction, aucun incident.

​

7. Attaques économiques sur les mathématiques de tick CLMM

​

Attaque

Un attaquant sophistiqué exploite l’arrondi ou les cas limites de comptabilité des frais dans les mathématiques de tick CLMM. Des exemples qui ont été trouvés dans d’autres implémentations CLMM (pas Raydium) :

• Comptabilité de croissance des frais qui arrondit contre l’utilisateur, accumulant de la poussière.
• Croisement de tick qui crédite/débite le mauvais delta fee_growth.
• Débordement d’entier dans les produits sqrtPrice * liquidity.

​

Exposition

Mathématiques complexes et sur mesure. Les audits et le fuzzing sont la défense principale.

​

Position de Raydium

CLMM a eu deux audits indépendants (OtterSec + MadShield) plus du fuzzing basé sur les propriétés en cours. Aucun bug impactant la production trouvé à ce jour. L’arithmétique sqrt_price_x64 Q64.64 utilise des mathématiques saturantes 128-bit avec des tests unitaires couvrant les ticks limites.

​

8. Confusion de position-NFT

​

Attaque

Un utilisateur est trompé pour signer une transaction qui transfère son NFT de position CLMM à un attaquant. L’attaquant possède maintenant la liquidité de la position.

​

Exposition

Tout détenteur de NFT de position.

​

Défenses

• Les UIs de portefeuille devraient reconnaître les NFT de position Raydium et les afficher distinctement (pas comme des NFT génériques à « envoyer »).
• Les utilisateurs devraient être prudents en signant des transactions qui transfèrent des NFT.
• Une nouvelle position est gelée seulement quand elle utilise un chemin ouvert V2 et que l’autorité de gel du mint du vault sous-jacent correspond à la liste des émetteurs restreints de CLMM. Cette position correspondante ne peut pas être transférée ou avoir son propriétaire de compte de token changé ; toutes les autres nouvelles positions restent transférables.

​

Position de Raydium

Les NFT de position implémentent la norme de métadonnées de Metaplex ; les applications de portefeuille qui comprennent les positions CLMM les affichent comme des positions de liquidité plutôt que des NFT tradables. La plupart des principaux portefeuilles Solana les affichent spécialement à partir de 2026. La congélation des émetteurs restreints est ciblée et ne protège pas les positions transférables ordinaires.

​

9. Manipulation du flux de récompenses de ferme

​

Attaque

Un créateur de ferme finance le vault de récompense, attire des stakers, puis appelle restartRewards avec des paramètres qui rendent le calcul de récompense en attente bizarre, volant la valeur de récolte.

​

Exposition

Fermes avec des créateurs malveillants. Farm v6 limite étroitement les pouvoirs du créateur ; cette attaque ne fonctionne pas.

​

Défenses

Les instructions d’admin de Farm v6 (setRewards, restartRewards, addReward) préservent les droits pro-rata — le reward_per_share est ajusté au moment du changement, donc aucune accumulation pré-changement n’est rétroactivement corrompue.

​

Position de Raydium

L’audit de ferme d’OtterSec a spécifiquement testé les scénarios de redémarrage de récompenses ; aucun exploit trouvé.

​

10. Divergence simulation-vs-exécution

​

Attaque

Un attaquant construit une transaction qui simule avec succès mais revient à l’exécution (ou vice versa). Utilisé pour harceler les portefeuilles qui s’appuient sur la simulation pour l’affichage.

​

Exposition

Portefeuilles affichant « vous recevrez X » basé sur la simulation.

​

Défenses

• Utilisez simulateTransaction avec le même blockhash que la soumission réelle.
• Affichez la sortie attendue comme « ≈ » (approximativement) pas exacte.
• Re-simulez immédiatement avant la soumission.

​

Position de Raydium

La simulation CLMM est déterministe étant donné l’état actuel du pool ; la divergence ne se produit que si l’état change entre la simulation et l’exécution (cas normal, géré via les limites de slippage).

​

Tableau récapitulatif

​

Ce que les utilisateurs peuvent faire

• Défaut au slippage serré ; augmentez seulement si nécessaire.
• Utilisez les flux de portefeuille / swap activés par Jito.
• Vérifiez les extensions de mint avant LP.
• Surveillez le multisig Squads pour les mises à niveau en attente.
• Diversifiez entre les pools ; ne concentrez pas tout votre LP dans un seul pool de lancement.

​

Ce que les intégrateurs peuvent faire

• Utilisez les TWAP ObservationState pour la tarification des dérivés.
• Validez les contraintes de compte lors de la composition via CPI.
• Filtrez les pools par champ tags (ignorez scam, honeypot, transfer-hook non vérifiés).
• Définissez des limites de slippage raisonnables ; n’acceptez pas 0 slippage de l’entrée utilisateur.
• Utilisez simulateTransaction avec prudence — documentez que c’est une estimation.

​

Pointeurs

• security/oracle-and-token-risks — Risques Token-2022 en profondeur.
• security/admin-and-multisig — Structure d’autorité.
• security/disclosure — Programme de bug-bounty.
• integration-guides/routing-and-mev — Atténuations MEV.

Sources :

• Rekt News — Post-mortems DeFi informant cette liste.
• Rapports d’audit liés dans security/audits.