Skip to main content
Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Seit dem Upgrade 2026-07 wurde die OpenBook / Serum Abhängigkeit von AMM v4 entfernt — keine Instruktion liest oder schreibt mehr OpenBook State. Die Marktkonten unten werden nur noch als Positionsplatzhalter in den Legacy v1 Instruktionslayouts (akzeptiert aber ignoriert) und als Referenzfelder auf AmmInfo beibehalten. Verwenden Sie die V2 Swap Entrypoints, die diese komplett weglassen. Diese Seite gruppiert die Konten weiterhin in „Pool-eigene” und „OpenBook (Legacy)” Abschnitte zum Lesen älterer Transaktionen.

Verzeichnis

Ein AMM v4 Pool registriert einen gebundenen Markt auf AmmInfo bei der Erstellung. Das vollständige Bild: Hinweis: Das Präfix „serum” wird in AMM v4’s IDL und Feldnamen aus Gründen der Rückwärtskompatibilität beibehalten. Diese Konten sind nach der OpenBook Entfernung nicht mehr funktional.

AmmInfo

Das Root State Konto des Pools. Groß (≈ 752 Bytes), da es sowohl Pool als auch OpenBook Referenzen inline trägt.
Das Struct Layout ist unverändert (byte-kompatibel), daher funktionieren bestehende Deserialisierer weiterhin, aber nach der OpenBook Entfernung werden die oben als VERALTET markierten Felder nicht mehr geschrieben — die swap_* Volumenzähler sind bei ihrem letzten Wert eingefroren. Für Volumen Analytics verwenden Sie Trade Logs statt dieser Felder. Nur need_take_pnl_* und pool_open_time werden aktiv gepflegt.
Integrator-relevante Felder:
  • coin_vault, pc_vault — die SPL Token Vaults des Pools. coin ist token_0 nach Serum/OpenBook Konvention (Basis), pc ist token_1 (Quote).
  • coin_decimals, pc_decimals — entsprechend den Mints.
  • open_orders, target_orders, market — Legacy Referenzfelder. Sind noch auf AmmInfo vorhanden und werden noch positionell auf v1 Instruktionslayouts übergeben, aber das Programm liest oder validiert sie nicht mehr. Die V2 Swap Entrypoints lassen sie weg.
  • fees.swap_fee_numerator / swap_fee_denominator — die kombinierte Trade Gebühr. Standard 25 / 10_000 = 0.25%.
  • status — ein einzelner aufgezählter u64 Zustand, der Operationen kontrolliert, keine Bitmaske. Admin-setzbar via SetParams mit param = 0 (Status). Siehe Status unten.
  • lp_amount — der interne LP Gesamtbestand des Pools. Er ist nicht gleich lp_mint.supply: er liegt genau ein ganzes LP Token (10^coin_decimals Base Units) höher, weil dieser Betrag bei der Initialisierung gezählt, aber nie gemintet wird. Die gesamte Pro-rata Mathematik verwendet lp_amount, verwenden Sie ihn also ebenfalls.
  • amm_owner — wird bei der Erstellung aus dem hartcodierten Admin Key des Programms geschrieben, nicht vom Ersteller.
  • state_data.need_take_pnl_* — Delta zwischen Brutto aufgelaufenen Gebühren und dem, was eingezogen wurde. TakePnl setzt diese auf Null.

Die OpenBook Verdrahtung

Entfernt. Die OpenBook / Serum Abhängigkeit wurde aus dem Programm gelöscht (Upgrade 2026-07). Die in diesem Abschnitt beschriebenen Konten werden nicht mehr validiert oder verwendet. Sie bleiben als Referenzfelder auf AmmInfo und als Positionsplatzhalter auf den Legacy v1 Instruktionslayouts. Verwenden Sie die V2 Swap Entrypoints (SwapBaseInV2 / SwapBaseOutV2), die diese Konten komplett überspringen.
Wenn Sie eine Legacy v1 SwapBaseIn / SwapBaseOut, Deposit oder Withdraw Instruktion aufrufen, muss die Konto Anzahl immer noch dem alten Layout entsprechen (die Marktkonten nehmen ihre historischen Positionen ein), aber ihr Inhalt wird nicht mehr überprüft — kein CPI wird gegen sie ausgegeben. Neuer Code sollte die V2 Swap Varianten verwenden, die diese Konten überhaupt nicht benötigen.
Das amm_open_orders des AMM ist ein OpenBook-eigenes Konto, das den Limit Order State des Pools auf diesem Markt hält: aktive Orders, abgerechnete Guthaben, Referrer usw. amm_target_orders ist AMM-seitig: es hält das beabsichtigte Grid des AMM (Preis/Größe für jeden Order Slot), damit das Programm billig vergleichen kann, was derzeit gepostet ist, und die Differenz platzieren / stornieren kann.

Authority PDAs

Es gibt genau eine amm_authority PDA für das gesamte AMM v4 Programm. Sein Seed ist trivial (["amm authority"]) und sein Bump wird auf jedem AmmInfo gespeichert. Diese Authority signiert alle Token Bewegungen für alle AMM v4 Pools.
Es gibt keine zweite, Pool-scoped Authority: diese eine PDA deckt alles ab, was das Programm signiert. Ihr Bump ist 254 auf Mainnet und wird auf jedem AmmInfo als nonce gespiegelt; WithdrawExcessLamports leitet sie mit diesem hartcodierten Nonce erneut ab.

Vaults

Die SPL Token Vaults des Pools sind Standard Token Konten, deren owner amm_authority ist. Keine ATAs — ihre Adressen sind PDAs, die bei Initialize2 aus [AMM_V4_PROGRAM_ID, market, "coin_vault_associated_seed"] und [AMM_V4_PROGRAM_ID, market, "pc_vault_associated_seed"] abgeleitet werden. Der Mint ist kein Seed, und amm_id ist es auch nicht. Adressen werden auf AmmInfo gespeichert; die Ableitung ist eine einmalige Kuriosität. Token-2022 wird nicht unterstützt. Das Programm hardcoded die SPL Token Programm ID für alle Vault Bewegungen. Der Versuch, einen AMM v4 Pool an einen Token-2022 Mint zu binden, schlägt bei Initialize2 mit InvalidSplTokenProgram fehl.

LP Mint

Ein klassischer SPL Token Mint, dessen Authority amm_authority ist. Die Gesamtversorgung verfolgt LP Eigentum des Pools; das Verbrennen von LP gibt Token aus beiden Vaults proportional zurück. Es gibt einen Mirror im Pool State: AmmInfo.lp_amount. Er ist nicht gleich der Versorgung des Mints — er liegt genau ein ganzes LP Token (10^coin_decimals Base Units) höher, weil dieser Betrag bei der Initialisierung gezählt, aber nie gemintet wird. Jede Pro-rata Berechnung im Programm dividiert durch lp_amount, verwenden Sie also dieses Feld statt der On-Chain Versorgung des Mints.

Status

AmmInfo.status ist ein einzelner aufgezählter u64 Zustand, keine Bitmaske. Testen Sie ihn auf Gleichheit — ein Client, der status & 1 testet, klassifiziert jeden aktiven Pool falsch, denn der normale Handelszustand ist 6, bei dem Bit 0 gesetzt ist. Initialize2 schreibt 7, wenn open_time in der Zukunft liegt, andernfalls 6; ein Pool bei 7 wechselt beim ersten Swap ab state_data.pool_open_time selbst auf 6. Ein Wert außerhalb von 0..=7 lässt AmmStatus::from_u64 panicken. Das Raydium Multisig setzt den Zustand via SetParams mit param = 0 (Status); nur die Werte 1–7 werden akzeptiert. (AdminCancelOrders wurde entfernt.)

Beobachtung / Oracle

AMM v4 hat kein dediziertes Observation Konto, und seit der OpenBook Entfernung gibt es auch keinen Orderbuch State, aus dem sich eines ableiten ließe. Wenn Sie einen Raydium TWAP mit Programm Support benötigen, verwenden Sie CPMM oder CLMM — beide unterhalten einen ObservationState Ringpuffer. Andernfalls indexieren Sie die Swap Logs off-chain.

Ableitung der Pool Konten von Grund auf

Die Pool Konten von AMM v4 sind einfache PDAs, die auf den gebundenen Markt geschlüsselt sind — keine Seeded Keypairs und keine Pro-Pair PDAs. Jedes von ihnen verwendet dieselbe Drei-Seed Form [AMM_V4_PROGRAM_ID, market, <label>] unter AMM_V4_PROGRAM_ID:
Der gebundene Markt ist der einzige variable Seed, weshalb ein Markt genau einem AMM v4 Pool entspricht. Das SDK und die API berechnen diese für Sie vor; siehe raydium-sdk-v2’s Liquidity.getAssociatedPoolKeys. In der Praxis lesen Integratoren den vollständigen Kontosatz des Pools von GET https://api-v3.raydium.io/pools/info/ids?ids=<POOL_ID> oder vom SDK. Manuelle Ableitung ist selten erforderlich.

Lebenszyklus Kurzreferenz

Pools und ihre Konten bleiben unbegrenzt bestehen. Selbst wenn Liquidität vollständig abgezogen wird, bleibt AmmInfo erhalten.

Was wo zu lesen ist

Quellen: