Angriffsvektoren

Ein AMM ist ein attraktives Ziel für böswilligen Code: Die Mittel der LP sind in vollständig sichtbaren Pools; jeder Swap ändert den Preis deterministisch. Diese Seite katalogisiert die Angriffskategorien, die gegen AMMs überall demonstriert wurden, wie sie auf Raydium zutreffen, und was Raydium (und Integratoren) zur Verteidigung tun.

​

1. Sandwich- / MEV-Angriffe

​

Angriff

Ein Bot beobachtet den Mempool / Gossip-Stream, sieht einen Swap eines Benutzers, führt einen Front-Run mit einem Kauf in die gleiche Richtung durch (drückt den Preis), lässt die Transaktion des Benutzers zu einem schlechteren Preis ausführen und führt dann einen Back-Run mit einem entgegengesetzten Verkauf durch. Der Bot profitiert von der Spanne.

​

Anfälligkeit

• Am stärksten exponiert: CPMM-Pools mit niedriger TVL und AMM-v4-Pools — selbst kleine Trades bewegen den Preis erheblich.
• Weniger exponiert: tiefe CLMM-Pools — Trades innerhalb eines Ticks bewegen den Preis nicht.
• Nicht exponiert: Farm-Harvests, LP-Einzahlungen (Verhältnis erzwungen, nicht auf die gleiche Weise preisabhängig).

​

Abwehrmaßnahmen

• Jito-Bundles (integration-guides/routing-and-mev) verstecken die Transaktion vor dem öffentlichen Mempool.
• Enge Slippage — Minimum-Out näher am Erwartungswert macht Sandwiches unrentabel. Unter ~0,3% verlieren die meisten Sandwiches Geld.
• Kleinere Handelsgrößen — teilen Sie einen $100k-Swap in 10× $10k auf; jeder bewegt den Preis weniger.

​

Raydiums Haltung

Raydiums Kernprogramme erzwingen keine Anti-MEV-Schutzmaßnahmen — sie sind auf Programmebene neutral. Der Schutz erfolgt auf der Einreichungsebene (Jito, integrierter Schutz von Wallets). Die UI setzt Slippage standardmäßig auf 0,5%, was für die meisten Pools angemessen ist.

​

2. Preismanipulation

​

Angriff

Ein großer Trader bewegt den Preis eines Pools vorübergehend (durch einen Flash Loan oder selbstfinanziert), löst eine nachgelagerte Aktion aus, die vom Preis abhängt (eine Liquidation, eine orakelgestützte Kreditaufnahme, eine Derivatauszahlung), und stellt dann den Preis wieder her.

​

Anfälligkeit

• Native Raydium-Operationen: nicht exponiert. Ein Spot-Swap rein und raus verursacht nur Gebühren hin und zurück; der Trader verliert Geld.
• Integrierte Programme: exponiert, wenn sie den Raydium-Pool-Preis naiv lesen.

​

Abwehrmaßnahmen

• Verwenden Sie TWAPs, nicht Spot-Preise, für Komposabilität (siehe security/oracle-and-token-risks).
• CLMM ObservationState bietet einen kurzfristigen TWAP, der ohne anhaltende Kapitalverpflichtung nicht manipulierbar ist.
• Multi-Oracle-Konsens: Wenn Ihr Programm Raydium, Pyth und Jupiter liest und nur handelt, wenn sie sich auf 1% einigen, reicht die Flash-Loan-Manipulation einer einzelnen Quelle nicht aus.

​

Raydiums Haltung

CLMM wird mit ObservationState-TWAP-Unterstützung ausgeliefert; Integratoren, die dies ignorieren und Spot-Preise verwenden, sind auf sich allein gestellt. Raydiums Frontend verwendet mehrere Preisquellen für die USD-Anzeige.

​

3. Spende- / Inflationsanschläge

​

Angriff

Der erste LP in einem neuen Pool zahlt einen winzigen Betrag ein (z. B. 1 Token von jedem 6-Dezimal-Mint → 1 Einheit LP ausgegeben). Dann „spendet” der Angreifer 1.000.000 Token direkt an den Pool-Tresor über SPL-Token-Transfer. Jetzt repräsentiert 1 LP-Einheit 500.000 von jedem Mint. Jeder nachfolgende LP, der weniger einzahlt, wird auf 0 LP-Einheiten gerundet und verliert seine Einzahlung.

​

Anfälligkeit

• CPMM / AMM v4: möglicherweise exponiert bei neu erstellten Pools mit niedriger Liquidität.
• CLMM: nicht exponiert (kein gemeinsamer LP-Mint; jede Position ist ihre eigene NFT mit explizitem Liquiditätswert).

​

Abwehrmaßnahmen

Die initialize-Anweisung von CPMM sperrt einen Mindest-LP-Betrag im Pool (inspiriert von Uniswap V2s MINIMUM_LIQUIDITY-Muster). Dies bedeutet, dass der erste LP sqrt(x × y) - MINIMUM_LIQUIDITY erhält, wobei MINIMUM_LIQUIDITY (1000 Einheiten) auf Null verbrannt wird. Ein Spendeanschlag erfordert, dass der Angreifer >> die anfängliche Einzahlung spendet, was unwirtschaftlich wird. Zusätzlich warnt Raydiums SDK laut, wenn die anfängliche Einzahlung winzig ist, und leitet Benutzer zu sinnvollen Beträgen.

​

Raydiums Haltung

Die MINIMUM_LIQUIDITY-Sperrung wird in CPMM ausgeliefert; AMM v4 hat einen ähnlichen Mechanismus. Benutzer, die Pools erstellen, sollten mit mindestens 10.000+ Einheiten von jedem Mint seeden, um Spendeanschläge in jedem Fall unwirtschaftlich zu machen.

​

4. Token-2022-Transfer-Hook-Missbrauch

​

Angriff

Der Transfer-Hook eines Mints ist aktualisierbar. Der Angreifer stellt einen unschuldigen Hook bei Mint-Start bereit, wird auf Raydium gelistet, sammelt LP von Benutzern. Später aktualisiert der Angreifer den Hook, um alle Transfers zu blockieren (effektiv Soft-Rug — Benutzer können nicht abheben). Der Angreifer macht den Pool nur in eine Richtung handelbar, kauft LP billig auf, entsperrt Hooks und gewinnt.

​

Anfälligkeit

Pools, die einen Transfer-Hook-Mint enthalten.

​

Abwehrmaßnahmen

• Programmebene: Raydium-Programme rufen den Hook während Swaps auf; wenn der Hook blockiert, wird der Swap rückgängig gemacht. Dies verhindert den Angriff mechanisch nicht.
• UI-Ebene: Raydium kennzeichnet Pools mit Transfer-Hook-Mints.
• Integrator-Ebene: Aggregatoren sollten Transfer-Hook-Mints standardmäßig überspringen und nur verifizierte Hooks auf die Whitelist setzen.

​

Raydiums Haltung

Raydium verbietet Transfer-Hook-Pools nicht (legitime Hooks existieren), kennzeichnet sie aber deutlich. Aggregatoren, die nach tags.includes("TRANSFER_HOOK") filtern, können ausschließen, wenn gewünscht.

​

5. Komposabilitäts- / CPI-Exploits

​

Angriff

Ein Programm setzt Raydium über CPI zusammen und führt einen Fehler ein: z. B. übergibt es den falschen observation_state, die falschen Tick-Arrays für einen CLMM-Swap oder gibt ein Konto doppelt aus. Der Angreifer identifiziert die fehlerhafte Komposition und nutzt sie aus.

​

Anfälligkeit

• Der fehlerhafte Integrator — normalerweise die Quelle des Fehlers.
• Raydium — nur wenn der Fehler unbeabsichtigtes Verhalten in Raydium-Programmen selbst auslöst.

​

Historische Beispiele

Keines von Raydiums Programmen wurde über CPI ausgenutzt — Raydiums Account-Validatoren fangen falsch geformte Accounts ab und machen rückgängig. Exploits im breiteren Ökosystem sind über benutzerdefinierte Programmfehler aufgetreten, die mit einem AMM zusammengesetzt wurden, aber nicht vom AMM stammten.

​

Abwehrmaßnahmen

• Aufrufende Programme sollten die Anchor-CPI-Helfer verwenden (nicht handgebaute Anweisungen), wenn möglich — Typsicherheit fängt die meisten Missbräuche ab.
• Integrationstests gegen Mainnet-geforkten State decken die Kompositionsfälle ab.

​

6. Admin- / Schlüsselkompromiss

​

Angriff

Ein Admin-Schlüssel (Upgrade-Autorität, AmmConfig-Admin, Protokoll-Gebühren-Anspruch) wird kompromittiert. Der Angreifer stellt ein böswilliges Upgrade bereit, das Pools ablässt, oder ändert AmmConfigs, um Gebühren an eine Angreifer-Wallet zu leiten, oder lässt Protokoll-Gebühren ab.

​

Anfälligkeit

Alle Rollen dokumentiert in security/admin-and-multisig.

​

Abwehrmaßnahmen

• 3/4-Multisig auf Upgrade-Autorität erfordert die Kompromittierung von 4 unabhängigen Unterzeichnern.
• 24-Stunden-Timelock auf Upgrades gibt Benutzern Zeit zum Abwickeln, bevor ein böswilliges Upgrade aktiviert wird.
• Operatives Monitoring — Warnungen bei jeder Multisig-Aktivität über Squads’ öffentliche Warteschlange.

​

Historischer Vorfall

Der Pool-Autoritätsschlüssel von AMM v4 wurde im Dezember 2022 kompromittiert (vor Multisig). Behebung: Alle Autoritäten zu Squads-Multisig verschoben. Nach der Behebung keine Vorfälle.

​

7. Wirtschaftliche Angriffe auf CLMM-Tick-Mathematik

​

Angriff

Ein ausgefeilter Angreifer nutzt Rundungs- oder Gebührenabrechnung-Grenzfälle in CLMM-Tick-Mathematik. Beispiele, die in anderen CLMM-Implementierungen gefunden wurden (nicht Raydium):

• Gebührenwachstums-Abrechnung, die gegen den Benutzer rundet und Staub ansammelt.
• Tick-Übergang, der die falsche fee_growth-Delta gutschreibt/belastet.
• Ganzzahlüberlauf in sqrtPrice * liquidity-Produkten.

​

Anfälligkeit

Komplexe benutzerdefinierte Mathematik. Audits und Fuzzing sind die primäre Verteidigung.

​

Raydiums Haltung

CLMM hat zwei unabhängige Audits (OtterSec + MadShield) plus laufendes eigenschaftsbasiertes Fuzzing. Kein produktionsbeeinflussender Fehler bis heute. Die sqrt_price_x64-Q64.64-Arithmetik verwendet saturierende 128-Bit-Mathematik mit Unit-Tests, die Grenz-Ticks abdecken.

​

8. Position-NFT-Verwechslung

​

Angriff

Ein Benutzer wird getäuscht, eine Transaktion zu unterzeichnen, die seine CLMM-Position-NFT an einen Angreifer überträgt. Der Angreifer besitzt nun die Liquidität der Position.

​

Anfälligkeit

Jeder Position-NFT-Inhaber.

​

Abwehrmaßnahmen

• Wallet-UIs sollten Raydium-Position-NFTs erkennen und sie deutlich anzeigen (nicht als generische NFTs zum „Senden”).
• Benutzer sollten vorsichtig sein, wenn sie Transaktionen unterzeichnen, die NFTs übertragen.
• Eine neue Position wird nur eingefroren, wenn sie einen V2-Open-Pfad verwendet und die Freeze-Autorität eines zugrunde liegenden Vault-Mints mit CLMMs Restricted-Issuer-Liste übereinstimmt. Diese übereinstimmende Position kann nicht übertragen werden oder ihre Token-Account-Eigentümer geändert werden; alle anderen neuen Positionen bleiben übertragbar.

​

Raydiums Haltung

Position-NFTs implementieren Metaplex’ Metadaten-Standard; Wallet-Apps, die CLMM-Positionen verstehen, zeigen sie als Liquiditätspositionen statt handelbarer NFTs an. Die meisten großen Solana-Wallets zeigen sie ab 2026 speziell an. Restricted-Issuer-Einfrieren ist gezielt und schützt nicht gewöhnliche übertragbare Positionen.

​

9. Farm-Reward-Stream-Manipulation

​

Angriff

Ein Farm-Ersteller finanziert den Reward-Tresor, zieht Staker an, ruft dann restartRewards mit Parametern auf, die die Pending-Reward-Berechnung verwirrend machen und Harvest-Wert stehlen.

​

Anfälligkeit

Farms mit böswilligen Erstellern. Farm v6 begrenzt Creator-Befugnisse eng; dieser Angriff funktioniert nicht.

​

Abwehrmaßnahmen

Die Admin-Anweisungen von Farm v6 (setRewards, restartRewards, addReward) bewahren Pro-Rata-Ansprüche — die reward_per_share wird zum Zeitpunkt der Änderung angepasst, sodass keine Vor-Änderungs-Abgrenzung rückwirkend beschädigt wird.

​

Raydiums Haltung

OtterSecs Farm-Audit testete speziell Restart-Rewards-Szenarien; kein Exploit gefunden.

​

10. Simulations- vs. Ausführungs-Divergenz

​

Angriff

Ein Angreifer konstruiert eine Transaktion, die erfolgreich simuliert, aber bei der Ausführung rückgängig gemacht wird (oder umgekehrt). Wird verwendet, um Wallets zu ärgern, die sich auf Simulation für die Anzeige verlassen.

​

Anfälligkeit

Wallets, die „Sie erhalten X” basierend auf Simulation anzeigen.

​

Abwehrmaßnahmen

• Verwenden Sie simulateTransaction mit dem gleichen Blockhash wie die echte Einreichung.
• Zeigen Sie erwartete Ausgabe als „≈” (ungefähr) nicht exakt an.
• Simulieren Sie unmittelbar vor der Einreichung erneut.

​

Raydiums Haltung

CLMM-Simulation ist deterministisch bei aktuellem Pool-State; Divergenz tritt nur auf, wenn sich der State zwischen Simulation und Ausführung ändert (normaler Fall, über Slippage-Grenzen behandelt).

​

Zusammenfassungstabelle

​

Was Benutzer tun können

• Standardmäßig enge Slippage; nur bei Bedarf erhöhen.
• Jito-aktivierte Wallets / Swap-Flows verwenden.
• Mint-Erweiterungen vor LP überprüfen.
• Squads-Multisig auf ausstehende Upgrades überwachen.
• Über Pools diversifizieren; konzentrieren Sie nicht alle Ihre LP in einem New-Launch-Pool.

​

Was Integratoren tun können

• ObservationState-TWAPs für Derivat-Preisgestaltung verwenden.
• Account-Constraints bei CPI-Komposition validieren.
• Pools nach tags-Feld filtern (überspringen Sie scam, honeypot, unverifizierten Transfer-Hook).
• Angemessene Slippage-Grenzen setzen; akzeptieren Sie nicht 0 Slippage von Benutzereingaben.
• simulateTransaction mit Vorsicht verwenden — dokumentieren Sie, dass es eine Schätzung ist.

​

Verweise

• security/oracle-and-token-risks — Token-2022-Risiken im Detail.
• security/admin-and-multisig — Autoritätsstruktur.
• security/disclosure — Bug-Bounty-Programm.
• integration-guides/routing-and-mev — MEV-Mitigationen.

Quellen:

• Rekt News — DeFi-Nachanalysen, die diese Liste informieren.
• Audit-Berichte verlinkt in security/audits.