Angriffsvektoren

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.

​

1. Sandwich- / MEV-Angriffe

​

Angriff

Ein Bot beobachtet den Mempool / Gossip-Stream, sieht einen Swap eines Benutzers, front-lädt mit einem Same-Direction-Kauf (drückt den Preis), lässt die Transaktionen des Benutzers mit schlechterem Preis ausführen, dann back-lädt mit einem Gegenkauf-Verkauf. Der Bot profitiert vom Spread.

​

Anfälligkeit

• Am meisten gefährdet: niedrig-TVL-CPMM-Pools und AMM-v4-Pools — selbst kleine Trades bewegen den Preis deutlich.
• Weniger gefährdet: tiefe CLMM-Pools — Within-Tick-Trades bewegen den Preis nicht.
• Nicht gefährdet: Farm-Harvests, LP-Einzahlungen (Verhältnis erzwungen, nicht preiselastisch auf die gleiche Weise).

​

Abwehrmaßnahmen

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

​

Raydiums Position

Raydiums Core-Programme erzwingen keine Anti-MEV-Schutzmaßnahmen — sie sind auf Programm-Ebene neutral. Der Schutz findet auf der Submission-Ebene statt (Jito, integrierte Wallet-Schutzmaßnahmen). 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 Pool-Preis vorübergehend (durch einen Flash-Loan oder selbst finanziert), löst eine nachgelagerte Aktion aus, die vom Preis abhängt (eine Liquidation, ein Oracle-basiertes Darlehen, eine Derivat-Auszahlung), dann gibt der Trader den Preis auf Normal zurück.

​

Anfälligkeit

• Native Raydium-Operationen: nicht gefährdet. Ein Spot-Swap rein und raus lädt einfach Round-Trip-Gebühren auf; der Trader verliert Geld.
• Integrierte Programme: gefährdet, wenn sie den Raydium-Pool-Preis naiv auslesen.

​

Abwehrmaßnahmen

• Verwenden Sie TWAPs, nicht Spot-Preise, für Composability (siehe security/oracle-and-token-risks).
• CLMM ObservationState gibt einen kurzfristigen TWAP, der nicht ohne nachhaltiges Kapitalengagement manipulierbar ist.
• Multi-Oracle-Konsens: Wenn Ihr Programm Raydium und Pyth und Jupiter ausliest und nur handelt, wenn sie sich auf 1% einigen, reicht eine Flash-Loan-Manipulation einer einzelnen Quelle nicht.

​

Raydiums Position

CLMM liefert ObservationState-TWAP-Support; Integrator, die es ignorieren und Spot-Preise verwenden, sind auf sich allein gestellt. Raydiums Frontend verwendet mehrere Preisquellen für USD-Anzeige.

​

3. Donation- / Inflationsangriffe

​

Angriff

Der erste LP in einem neuen Pool zahlt einen winzigen Betrag ein (z.B. 1 Token von jeweils 6-Dezimal-Mints → 1 LP-Einheit ausgestellt). Dann „spendet” der Angreifer 1.000.000 Token direkt an den Pool-Vault über SPL-Token-Transfer. Nun 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: potenziell gefährdet bei neu erstellten, niedrig-Likuiditäts-Pools.
• CLMM: nicht gefährdet (kein gemeinsamer LP-Mint; jede Position ist ihre eigene NFT mit explizitem Liquiditätswert).

​

Abwehrmaßnahmen

CPMMs initialize-Anweisung sperrt einen Mindest-LP-Betrag in den Pool (inspiriert von Uniswap V2s MINIMUM_LIQUIDITY-Muster). Das bedeutet, die erste LP erhält sqrt(x × y) - MINIMUM_LIQUIDITY, wobei MINIMUM_LIQUIDITY (1000 Einheiten) auf null verbrannt wird. Ein Donation-Angriff erfordert, dass der Angreifer >> die erste Einzahlung spendet, was unwirtschaftlich wird. Darüber hinaus warnt Raydiums SDK laut, wenn die erste Einzahlung winzig ist, und leitet Benutzer zu sinnvollen Beträgen.

​

Raydiums Position

Der MINIMUM_LIQUIDITY-Lockup wird in CPMM versendet; AMM v4 hat einen ähnlichen Mechanismus. Benutzer, die Pools erstellen, sollten mindestens 10.000+ Einheiten von jedem Mint einzahlen, um Donation-Angriffe in jedem Fall unwirtschaftlich zu machen.

​

4. Token-2022-Transfer-Hook-Missbrauch

​

Angriff

Ein Mints Transfer-Hook ist aktualisierbar. Der Angreifer stellt beim Launch einen unschuldigen Hook bereit, wird auf Raydium aufgelistet, sammelt LP von Benutzern. Später aktualisiert der Angreifer den Hook, um alle Transfers zu blockieren (effektiv soft-rugging — Benutzer können nicht abheben). Der Angreifer macht den Pool nur in eine Richtung handelbar, kauft LP günstig auf, entsperrt Hooks, gewinnt.

​

Anfälligkeit

Pools, die einen Transfer-Hook-Mint enthalten.

​

Abwehrmaßnahmen

• Programm-Ebene: Raydium-Programme rufen den Hook während Swaps auf; wenn der Hook blockiert, wird der Swap zurückgewiesen. Das verhindert den Angriff mechanisch nicht.
• UI-Ebene: Raydium kennzeichnet Pools mit Transfer-Hook-Mints.
• Integrator-Ebene: Aggregator sollten Transfer-Hook-Mints standardmäßig überspringen und nur verifizierte Hooks zulassen.

​

Raydiums Position

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

​

5. Composability- / CPI-Exploits

​

Angriff

Ein Programm setzt Raydium über CPI zusammen und führt einen Bug ein: z.B. übergibt es den falschen observation_state, die falschen Tick-Arrays für einen CLMM-Swap oder gibt ein Konto doppelt aus. Angreifer erkennen die buggy-Zusammensetzung und exploitieren.

​

Anfälligkeit

• Der buggy-Integrator — üblicherweise die Fehlerquelle.
• Raydium — nur wenn der Bug unbeabsichtigtes Verhalten in Raydium-Programmen selbst auslöst.

​

Historische Beispiele

Keines von Raydiums Programmen wurde über CPI exploitet — Raydiums Account-Validatoren erfassen falsch geformte Accounts und stoppen. Exploits im breiteren Ökosystem sind über Custom-Programm-Bugs passiert, die mit einem AMM zusammengesetzt wurden, aber nicht von dem AMM stammten.

​

Abwehrmaßnahmen

• Aufgerufene Programme sollten die Anchor-CPI-Helfer verwenden (nicht handgebaute Anweisungen), wenn möglich — Typ-Sicherheit erfasst die meisten Missbräuche.
• Integrationstests gegen Mainnet-geforkten State decken die Composition-Fälle ab.

​

6. Admin- / Schlüsselkompromittierung

​

Angriff

Ein Admin-Schlüssel (Upgrade-Autorität, AmmConfig-Admin, Protokoll-Fee-Claim) ist kompromittiert. Angreifer stellen ein böswilliges Upgrade bereit, das Pools leert, oder ändern AmmConfigs, um Gebühren an ein Angreifer-Wallet zu leiten, oder leeren Protokoll-Gebühren.

​

Anfälligkeit

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

​

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 Abbau vor einem böswilligen Upgrade aktiviert wird.
• Operatives Monitoring — Benachrichtigungen bei jeder Multisig-Aktivität über öffentliche Squads-Warteschlange.

​

Historischer Vorfall

AMM v4s Pool-Autorität-Schlüssel wurde im Dezember 2022 kompromittiert (vor Multisig). Fix: Alle Autoritäten zu Squads-Multisig verschoben. Nach dem Fix, keine Vorfälle.

​

7. Wirtschaftliche Angriffe auf CLMM-Tick-Mathematik

​

Angriff

Ein sophistizierter Angreifer exploitiert Rundungs- oder Gebühren-Buchhaltungskantenfälle in der CLMM-Tick-Mathematik. Beispiele, die in anderen CLMM-Implementierungen gefunden wurden (nicht Raydium):

• Gebühren-Wachstums-Buchhaltung, die gegen den Benutzer rundet, Staub ansammelt.
• Tick-Crossing, das die falsche fee_growth-Delta krediert/debiliert.
• Integer-Overflow in sqrtPrice * liquidity-Produkten.

​

Anfälligkeit

Komplexe bespoke Mathematik. Audits und Fuzzing sind die primäre Abwehr.

​

Raydiums Position

CLMM hat zwei unabhängige Audits (OtterSec + MadShield) plus fortlaufendes Property-Based-Fuzzing. Kein produktionsrelevanter Bug bis heute. Die sqrt_price_x64 Q64.64-Arithmetik verwendet saturating 128-Bit-Mathematik mit Unit-Tests, die Grenz-Ticks abdecken.

​

8. Position-NFT-Verwechslung

​

Angriff

Ein Benutzer wird getäuscht, eine Transaktion zu signieren, 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 signieren, die NFTs übertragen.

​

Raydiums Position

Position-NFTs implementieren Metaplexs Metadaten-Standard; Wallet-Apps, die CLMM-Positionen verstehen, zeigen sie als Liquiditätspositionen statt als handelbare NFTs an. Die meisten großen Solana-Wallets zeigen sie seit 2026 speziell.

​

9. Farm-Reward-Stream-Manipulation

​

Angriff

Ein Farm-Ersteller finanziert den Reward-Vault, lockt Staker, ruft dann restartRewards mit Parametern auf, die die Pending-Reward-Berechnung verwirrend machen, stiehlt Harvest-Wert.

​

Anfälligkeit

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

​

Abwehrmaßnahmen

Farm v6s Admin-Anweisungen (setRewards, restartRewards, addReward) bewahren Pro-Rata-Ansprüche — die reward_per_share wird im Moment der Änderung angepasst, daher wird keine Pre-Change-Accrual rückwirkend beschädigt.

​

Raydiums Position

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

​

10. Simulation-vs-Execution-Divergenz

​

Angriff

Ein Angreifer konstruiert eine Transaktion, die erfolgreich simuliert, aber bei der Ausführung zurückgewiesen wird (oder umgekehrt). Verwendet, um Wallets zu quälen, die sich auf Simulation für die Anzeige verlassen.

​

Anfälligkeit

Wallets zeigen „Sie werden X erhalten” basierend auf der Simulation.

​

Abwehrmaßnahmen

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

​

Raydiums Position

CLMM-Simulation ist deterministisch bei aktuellem Pool-State; Divergenz findet nur statt, wenn sich der State zwischen Simulation und Ausführung ändert (normaler Fall, wird mit Slippage-Bounds behandelt).

​

Zusammenfassungstabelle

​

Was Benutzer tun können

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

​

Was Integrator tun können

• Verwenden Sie ObservationState-TWAPs für Derivat-Preisgestaltung.
• Validieren Sie Account-Einschränkungen beim Composing über CPI.
• Filtern Sie Pools nach tags-Feld (überspringen Sie scam, honeypot, unverifizierten Transfer-Hook).
• Setzen Sie angemessene Slippage-Grenzen; akzeptieren Sie nicht 0 Slippage von Benutzereingaben.
• Verwenden Sie simulateTransaction mit Vorsicht — 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-Post-Mortems, die diese Liste informieren.
• Audit-Berichte verlinkt in security/audits.