Zum Hauptinhalt springen

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.

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Diese Seite ergänzt products/clmm/accounts (Beschreibung der Accounts) und products/clmm/math (Beschreibung der Mathematik). Sie ist maßgeblich für Argumente und Account-Reihenfolge; konkrete Byte-Layouts entnehmen Sie dem IDL.

Instruktionsübersicht

GruppeInstruktionHinweise
AdminCreateAmmConfigNeue Fee-Stufe definieren.
AdminUpdateAmmConfigRaten einer bestehenden Stufe ändern.
AdminUpdatePoolStatusOperationen eines Pools pausieren/fortsetzen.
AdminCreateSupportMintAssociatedToken-2022-Mint-Extension-Konfiguration für CLMM-Pools zulassen.
AdminCreateOperationAccountProgrammweiten Operation-Account einmalig initialisieren.
AdminUpdateOperationAccountWhitelist des Operation-Accounts anpassen.
AdminCreateDynamicFeeConfigWiederverwendbaren Dynamic-Fee-Parametersatz unter einem u16-Index anlegen.
AdminUpdateDynamicFeeConfigBestehende DynamicFeeConfig bearbeiten. Pools, die die Konfiguration bereits gespeichert haben, bleiben unverändert.
PoolCreatePoolCLMM-Pool an eine AmmConfig binden. Standardmäßiger FromInput-Fee-Pfad. Koexistiert mit CreateCustomizablePool.
PoolCreateCustomizablePoolEmpfohlen für neue Pools. Gleiche Struktur wie CreatePool, zusätzlich collect_fee_on und ein optionales enable_dynamic_fee-Flag.
PositionOpenPosition / OpenPositionV2 / OpenPositionWithToken22NftPosition-NFT minten. OpenPositionV2 ersetzt V1 (neues Account-Layout mit Bitmap-Extension-Slot); OpenPositionWithToken22Nft gibt das Position-NFT als Token-2022 statt als SPL Token aus. Neuer Code sollte V2 oder die Token-2022-Variante verwenden.
PositionIncreaseLiquidity / IncreaseLiquidityV2Liquidität zu einer bestehenden Position hinzufügen.
PositionDecreaseLiquidity / DecreaseLiquidityV2Liquidität entfernen; ausstehende Gebühren werden eingesammelt.
PositionClosePositionNFT verbrennen und PersonalPositionState schließen.
PositionCloseProtocolPositionNur Admin: Legacy-ProtocolPositionState-PDAs bereinigen. Das aktuelle Programm erstellt und liest keine ProtocolPositionState mehr — diese Instruktion existiert ausschließlich zur Rückforderung von Rent auf Accounts älterer Programmversionen.
SwapSwap / SwapV2Constant-Liquidity-Swap. Beide Varianten unterstützen Dynamic Fee, einseitiges Fee-Routing und Limit-Order-Matching; der einzige Unterschied besteht darin, dass SwapV2 Token-2022-Mints akzeptiert (V1 erfordert klassische SPL-Token-Vaults).
SwapSwapRouterBaseInMulti-Hop, vom Router genutzt.
Limit OrderOpenLimitOrderVerkaufsorder an einem Tick platzieren. Nicht gefüllte Token verbleiben am Tick; die Matching-Engine füllt sie, sobald der Preis diesen Tick passiert.
Limit OrderIncreaseLimitOrderBestehende offene Order aufstocken.
Limit OrderDecreaseLimitOrderOffene Order reduzieren oder stornieren; der ungefüllte Rest sowie bereits abgewickelte Ausgaben werden ausgezahlt.
Limit OrderSettleLimitOrderGefüllte Ausgabe-Token an den Order-Inhaber übermitteln. Aufrufbar durch den Inhaber oder den operativen Keeper.
Limit OrderCloseLimitOrderVollständig ausgeführten Order-Account schließen. Rent wird stets an den owner der Order zurückgegeben. Aufrufbar durch Inhaber oder Keeper.
FeesCollectProtocolFeeAdmin-Sweep der Protokollgebühren.
FeesCollectFundFeeAdmin-Sweep der Fondsgebühren.
RewardsInitializeRewardNeuen Reward-Stream an einen Pool anhängen.
RewardsSetRewardParamsEmissionsrate/Endzeitpunkt eines bestehenden Rewards ändern.
RewardsUpdateRewardInfosReward-Wachstum bis jetzt abrechnen (wird von jedem Swap/jeder Positionsänderung aufgerufen).
RewardsTransferRewardOwnerAutorität, die einen Reward-Stream einstellen oder auffüllen kann, übertragen.
RewardsCollectRemainingRewardsNach Ablauf von end_time eines Reward-Streams nicht zugeteilte Token an den Funder zurückführen.
UtilityInitTickArrayTick-Array-Account initialisieren (wird häufig zusammen mit OpenPosition gebündelt).
Die meisten nur-Admin-Instruktionen (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateSupportMintAssociated, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) sind durch den fest programmierten admin-Pubkey des Programms geschützt. Reward-Stream-Admin-Instruktionen (TransferRewardOwner, CollectRemainingRewards) werden durch den Reward-Funder, nicht durch den Programm-Admin, kontrolliert. Das Suffix V2 bedeutet: „Token-2022 auf Vaults/NFT unterstützt, Bitmap-Extension-Slot erforderlich”. Das SDK wählt für neue Pools standardmäßig V2.

CreatePool

Argumente
sqrt_price_x64: u128           // Anfangspreis
open_time:      u64            // Swaps vor diesem Zeitpunkt werden abgelehnt
Accounts (vereinfacht)
#NameWSHinweise
1pool_creatorWS
2amm_configGewählte Fee-Stufe.
3pool_stateWWird hier initialisiert.
4token_mint_0Sortiert.
5token_mint_1
6token_vault_0WWird hier initialisiert, Eigentümer ist die Pool-Authority-PDA.
7token_vault_1W
8observation_stateWWird hier initialisiert.
9tick_array_bitmap_extensionWWird hier initialisiert (V2).
10token_program
11token_program_2022
12system_program, rent
Vorbedingungen
  • token_mint_0 < token_mint_1 nach Byte-Reihenfolge.
  • amm_config.disable_create_pool == false.
  • Mints werden nicht durch die Token-2022-Extension-Allowlist abgelehnt.
Nachbedingungen
  • pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
  • pool_state.liquidity = 0 (noch keine Positionen).
  • pool_state.fee_on = FromInput (Legacy-Standard).
  • pool_state.dynamic_fee_info ist auf null gesetzt (Dynamic Fee deaktiviert).

CreateCustomizablePool

Empfohlen für neue Pools. Gleiche Wirkung wie CreatePool, zusätzlich mit pool-spezifischem Fee-Erhebungsmodus und optionalem Dynamic-Fee-Opt-in. Argumente
pub struct CreateCustomizableParams {
    pub sqrt_price_x64:    u128,
    pub collect_fee_on:    CollectFeeOn,   // FromInput | Token0Only | Token1Only
    pub enable_dynamic_fee: bool,
}
Accounts (vereinfacht) — wie CreatePool, zusätzlich bei enable_dynamic_fee = true:
#NameWSHinweise
Ndynamic_fee_configDie gemeinsam genutzte Konfiguration, von der ein Snapshot erstellt wird. Muss bereits vorhanden sein.
Vorbedingungen — wie CreatePool. Bei enable_dynamic_fee = false wird dynamic_fee_config ignoriert. Nachbedingungen
  • pool_state.fee_on wird auf die gewählte CollectFeeOn-Variante gesetzt.
  • Wenn Dynamic Fee aktiviert wurde: pool_state.dynamic_fee_info wird aus der übergebenen DynamicFeeConfig initialisiert (fünf Kalibrierungsparameter werden kopiert; Zustandsfelder auf null gesetzt).
  • Andernfalls: pool_state.dynamic_fee_info bleibt null (= Dynamic Fee für diesen Pool dauerhaft inaktiv).
fee_on und das Dynamic-Fee-Aktivierungsbit werden ausschließlich bei der Pool-Erstellung gesetzt. Es gibt keinen nachträglichen Upgrade-Pfad — Pools, die über das Legacy-CreatePool erstellt wurden, können weder Dynamic Fee noch einseitige Gebühren nachträglich erhalten. Neue Deployments sollten standardmäßig diese Instruktion verwenden.

OpenPositionV2 / OpenPositionWithToken22Nft

Neue Position innerhalb eines bestehenden Pools erstellen. Argumente
tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // gewünschtes L (oder 0, um die untenstehenden Beträge zu verwenden)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // NFT-Metadaten schreiben (Metaplex)
base_flag: Option<bool>       // true = an amount0 anpassen; false = an amount1 anpassen
Accounts (vereinfacht)
#NameWS
1payerWS
2position_nft_owner
3position_nft_mintWS (keypair)
4position_nft_accountWATA des Inhabers für das NFT.
5metadata_accountWMetaplex (optional, wenn with_metadata).
6pool_stateW
7protocol_position
8tick_array_lowerWWird erstellt, falls nicht initialisiert.
9tick_array_upperWEbenso.
10personal_positionWWird hier erstellt.
11token_account_0, token_account_1WQuell-ATAs des Nutzers.
12token_vault_0, token_vault_1W
13rent, system_program, token_program
14associated_token_program
15metadata_programOptional.
16token_program_2022V2.
17vault_0_mint, vault_1_mintV2.
18tick_array_bitmap_extensionWV2 (falls berührt).
Mathematik — siehe products/clmm/math. Abhängig von base_flag berechnet das Programm aus liquidity oder (amount_0_max, amount_1_max) das tatsächliche L sowie die tatsächlich verbrauchten Token-Beträge. Vorbedingungen
  • tick_lower < tick_upper, beide Vielfache von pool.tick_spacing, innerhalb von [MIN_TICK, MAX_TICK].
  • Erforderliche Tick-Arrays übergeben und initialisiert (oder in der Transaktion über InitTickArray-CPI erstellt).
  • Nutzer verfügt über mindestens amount_0_max und amount_1_max in den Quell-ATAs.
Nachbedingungen
  • personal_position existiert, liquidity ist gesetzt, fee_growth_inside_last wurde gespeichert.
  • Tick-Array-Einträge bei tick_lower und tick_upper aktualisiert (liquidity_gross += L, liquidity_net ± L, Fee-Growth-Snapshots gepflegt).
  • pool_state.liquidity += L, sofern die Position im Bereich liegt (tick_lower ≤ tick_current < tick_upper).
Häufige FehlerInvalidTickIndex, NotApproved, ZeroAmountSpecified, TransactionTooLarge (bei zu vielen Tick-Arrays).

IncreaseLiquidityV2

Liquidität zu einer bereits geöffneten Position hinzufügen. Argumente
liquidity: u128
amount_0_max: u64
amount_1_max: u64
base_flag: Option<bool>
Accounts — wie OpenPosition, jedoch ohne den NFT-Mint (die Position existiert bereits; das NFT wird als ATA des Inhabers mit 1 Token übergeben). Wirkung
  • Überträgt amount_0_actual / amount_1_actual vom Nutzer an die Vaults.
  • Erhöht personal_position.liquidity und pool_state.liquidity (wenn im Bereich) sowie liquidity_gross / liquidity_net der Endpunkt-Ticks entsprechend.
  • Sammelt ausstehende Gebühren und Rewards seit dem letzten Zugriff und schreibt sie in tokens_fees_owed_{0,1} / reward_amount_owed. Diese werden erst bei DecreaseLiquidity oder CollectReward ausgezahlt, nicht beim Erhöhen.

DecreaseLiquidityV2

Liquidität aus einer Position entfernen. Argumente
liquidity: u128
amount_0_min: u64
amount_1_min: u64
Accounts — gleiche Struktur wie IncreaseLiquidity. Wirkung
  • Berechnet (amount_0, amount_1) für das entfernte L auf Basis des aktuellen sqrt_price_x64.
  • Rechnet seit dem letzten Zugriff aufgelaufene Gebühren/Rewards ab, genau wie bei IncreaseLiquidity.
  • Überträgt amount_0 + fees_owed_0 und amount_1 + fees_owed_1 aus den Vaults an den Nutzer.
  • Vermindert die Liquiditätszähler; wenn personal_position.liquidity == 0 nach der Reduktion, ist die Position für ClosePosition freigegeben.
Slippageamount_0_min und amount_1_min sind die Mindestbeträge, die der Nutzer nach Abzug etwaiger Token-2022-Transfergebühren auf der Ausgabeseite akzeptiert.

ClosePosition

Das Position-NFT verbrennen und PersonalPositionState schließen. Vorbedingungen
  • personal_position.liquidity == 0.
  • tokens_fees_owed_{0,1} == 0.
  • Alle Reward-Zähler reward_amount_owed == 0.
(D. h., zunächst alles einsammeln und Liquidität auf null reduzieren.) Wirkung
  • Verbrennt das NFT.
  • Schließt den NFT-Mint-Account und den personal_position-Account; die Rent wird an den payer zurückerstattet.

SwapV2

Durchläuft die Liquiditätskurve; entweder exakter Input oder exakter Output, abhängig von is_base_input. Argumente
amount: u64                  // Input, wenn is_base_input=true, sonst Output
other_amount_threshold: u64  // Mindest-Output oder maximaler Input
sqrt_price_limit_x64: u128   // harte Grenze; 0 ⇒ unbegrenzt
is_base_input: bool
Accounts (vereinfacht)
#NameWSHinweise
1payerS
2amm_config
3pool_stateW
4input_token_accountW
5output_token_accountW
6input_vaultW
7output_vaultW
8observation_stateW
9token_program
10token_program_2022V2.
11memo_programV2 (für bestimmte Token-2022-Pfade erforderlich).
12input_vault_mint, output_vault_mintV2.
13tick_array_bitmap_extension (optional)WWenn der Swap in die Extension hineinläuft.
14+tick_array (remaining)WAusreichend Arrays, um den erwarteten Swap-Bereich abzudecken.
Aufrufer übergeben eine geordnete Liste von Tick-Arrays, die den erwarteten Swap-Pfad abdecken; das Programm verwendet so viele wie nötig. Das SDK berechnet diese Liste über PoolUtils.computeAmountOutFormat oder den Quote-Endpunkt der API. Vorbedingungen
  • pool_state.status erlaubt Swaps.
  • now >= open_time.
  • sqrt_price_limit_x64 liegt für die gewählte Richtung auf der richtigen Seite von sqrt_price_x64.
Häufige FehlerExceededSlippage, SqrtPriceLimitOverflow, TickArrayNotFound, LiquidityInsufficient. Was SwapV2 intern tut, das Aufrufer wissen sollten (Release nach 2025):
  1. Dynamic-Fee-Zuschlag — wenn pool.dynamic_fee_info ungleich null ist, aktualisiert das Programm den Volatilitätsakkumulator anhand der seit dem letzten Swap zurückgelegten Tick-Distanz (mit den Filter-/Decay-Regeln aus products/clmm/fees) und addiert eine dynamic_fee_component zur AmmConfig.trade_fee_rate. Die Gesamtgebühr ist auf 10 % begrenzt (MAX_FEE_RATE_NUMERATOR / 1_000_000).
  2. Limit-Order-Matching — wenn der Preispfad einen Tick mit offenen Limit Orders kreuzt, füllt das Programm zuerst die verfügbare Limit-Order-Liquidität an diesem Tick (FIFO nach order_phase) und fährt dann entlang der LP-Liquiditätskurve fort. Gefüllte Beträge aktualisieren tick.unfilled_ratio_x64 und tick.part_filled_orders_remaining für die spätere Abrechnung; die Orders selbst bleiben unverändert, bis der Inhaber SettleLimitOrder aufruft.
  3. Einseitiges Fee-Routing — wenn pool.fee_on = Token0Only oder Token1Only, berechnet der Swap-Schritt denselben Input-Output-Handel; die Gebühr wird dann an die konfigurierte Seite weitergeleitet. Bei Richtungen, bei denen die konfigurierte Fee-Seite die Ausgabe ist, wird die Gebühr vom Swap-Output abgezogen (der Nutzer erhält out − fee); bei Richtungen, bei denen sie der Input ist, entspricht das Verhalten FromInput. Siehe is_fee_on_input(zero_for_one) und is_fee_on_token0(zero_for_one) auf PoolState.
Swap (V1) implementiert dieselbe Dynamic Fee, dasselbe einseitige Fee-Routing und dasselbe Limit-Order-Matching wie SwapV2; der einzige fehlende Aspekt ist die Token-2022-Unterstützung — beide Vaults müssen klassische SPL-Token sein. Pools mit einem Token-2022-Mint müssen über SwapV2 geswappt werden. Der Aggregator und das SDK bevorzugen für jedes CLMM-Leg bereits V2, sodass Aufrufer nicht nach Mint-Typ unterscheiden müssen.

OpenLimitOrder

Verkaufsorder an einem bestimmten Tick platzieren. Die Order sitzt in einer per-Tick-FIFO-Kohorte und wird gefüllt, wenn der Preis diesen Tick passiert. Argumente
nonce_index:    u8       // vom Nutzer gewählter Nonce-Account-Index (0..255 pro Wallet)
zero_for_one:   bool     // true: token0 gegen token1 verkaufen; false: token1 gegen token0
tick_index:     i32      // muss ein Vielfaches von pool.tick_spacing sein
amount:         u64      // Input-Token-Betrag
Accounts (vereinfacht)
#NameWSHinweise
1payerWSOrder-Inhaber; zahlt Rent.
2pool_stateW
3tick_arrayWDas Tick-Array, das tick_index enthält.
4limit_order_nonceWPDA. init_if_needed — wird bei der ersten Order des Nutzers unter diesem nonce_index erstellt.
5limit_orderWPDA. Wird hier initialisiert.
6input_token_accountWInput-ATA des Nutzers.
7input_vaultWPool-Input-Vault.
8input_vault_mintToken-2022-Gebührenbehandlung.
9input_token_programSPL oder Token-2022.
10system_program, rent
Vorbedingungen
  • tick_index % pool.tick_spacing == 0 und innerhalb von [MIN_TICK, MAX_TICK].
  • tick_index liegt auf der richtigen Seite von pool.tick_current für die gewählte Richtung (token0 verkaufen → Tick muss oberhalb des aktuellen liegen, und umgekehrt). Eine Order an einem bereits überquerten Tick würde sofort gematcht und wird abgelehnt.
  • pool_state.status erlaubt Limit-Order-Operationen (Bit 5).
Nachbedingungen
  • limit_order existiert und hat tick.order_phase sowie tick.unfilled_ratio_x64 zum Öffnungszeitpunkt gespeichert.
  • tick.orders_amount += amount (in der aktuellen Kohorte).
  • limit_order_nonce.order_nonce += 1.
  • OpenLimitOrderEvent wird ausgelöst.
Häufige FehlerInvalidLimitOrderAmount (null oder unterhalb des Pool-Minimums), InvalidTickIndex (außerhalb von [MIN_TICK, MAX_TICK] oder auf der falschen Seite von tick_current für die gewählte Richtung), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

IncreaseLimitOrder

Bestehende offene Order aufstocken. Nur durch den owner der Order aufrufbar. Argumente
amount: u64    // zusätzlicher Input-Token-Betrag
Accounts — wie OpenLimitOrder, jedoch ohne den Nonce-Account; die limit_order-PDA wird direkt übergeben. Vorbedingungen
  • limit_order.owner == signer.
  • Die Order befindet sich noch in derselben Kohorte (tick.order_phase == limit_order.order_phase). Hat die Kohorte bereits begonnen sich zu füllen, ist die Order teilweise abgerechnet — der Aufrufer sollte zunächst DecreaseLimitOrder oder SettleLimitOrder aufrufen, um den Status voranzubringen.
Wirkung
  • Überträgt amount vom Inhaber-ATA an input_vault.
  • limit_order.total_amount += amount; tick.orders_amount += amount.

DecreaseLimitOrder

Offene Order reduzieren oder vollständig stornieren. Zahlt den ungefüllten Rest an den Inhaber zurück, zuzüglich bereits durch frühere Teilfüllungen abgerechneter Ausgaben. Argumente
amount:     u64    // zurückzuziehender Input-Token-Betrag (max = ungefüllter Rest)
amount_min: u64    // Slippage-Untergrenze für die Input-seitige Auszahlung
Accounts — beide Token-Seiten (Input und Output):
#NameWS
1ownerS
2pool_stateW
3tick_arrayW
4limit_orderW
5input_token_accountW
6output_token_accountW
7input_vaultW
8output_vaultW
9input_vault_mint, output_vault_mint
10token_program, token_program_2022
Wirkung
  • Berechnet den gefüllten Betrag der Order aus dem unfilled_ratio_x64 der Kohorte seit der Öffnung neu.
  • Sendet gefüllten Output an output_token_account.
  • Sendet amount des ungefüllten Inputs zurück an input_token_account.
  • Aktualisiert limit_order entsprechend. Ist der verbleibende ungefüllte Rest null, schließt das Programm den Account und erstattet die Rent an owner zurück.

SettleLimitOrder

Gefüllte Output-Token an den Inhaber übermitteln, ohne den ungefüllten Rest der Order zu ändern. Nützlich, wenn auto_withdraw-Keeper lang laufende Teilfüllungen schrittweise auszahlen möchten. Aufrufer — entweder der owner der Order oder der limit_order_admin des Programms (ein Off-Chain-operativer Hot Wallet, der eine automatisierte Keeper-Schleife betreibt). Der Keeper hat keine weitere Autorität — er kann Nutzergelder ausschließlich als gefüllten Output an die owner-ATA der Order weiterleiten. Accounts
#NameWS
1signerSowner oder limit_order_admin
2pool_state
3tick_array
4limit_orderW
5output_token_accountWOutput-ATA des Inhabers.
6output_vaultWPool-Output-Vault.
7output_vault_mint
8output_token_program
Wirkung
  • Berechnet den kumulativen geschuldeten Output anhand von (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
  • Überträgt die Differenz an output_token_account.
  • Aktualisiert limit_order.settled_output.
  • Schließt die Order nicht; sie bleibt für verbleibenden Input offen.

CloseLimitOrder

Vollständig ausgeführten Order-Account schließen. Die Rent wird stets an limit_order.owner zurückgegeben, unabhängig davon, wer unterschreibt. Aufrufer — entweder owner oder limit_order_admin. Vorbedingungen
  • Die Order hat einen ungefüllten Rest von null (entweder wurde amount == total_amount gefüllt und abgerechnet, oder der Inhaber hat die Order zuvor auf null reduziert und vergessen zu schließen).
Wirkung
  • Schließt limit_order; Rent wird an limit_order.owner gesendet.

CreateDynamicFeeConfig (Admin)

Wiederverwendbaren Parametersatz unter einem u16-Index anlegen. Argumente
index:                       u16
filter_period:               u16   // Sekunden; z. B. 30
decay_period:                u16   // Sekunden; z. B. 600. Muss > filter_period sein
reduction_factor:            u16   // 1..10_000; z. B. 5_000 = 50 % Retention pro Decay-Fenster
dynamic_fee_control:         u32   // 1..100_000; Verstärkung auf der Volatilitäts-zu-Gebühren-Kurve
max_volatility_accumulator:  u32   // Obergrenze
Accounts
#NameWSHinweise
1ownerWSFest programmierter Admin-Pubkey.
2dynamic_fee_configWPDA, wird hier initialisiert.
3system_program
Häufige FehlerInvalidDynamicFeeConfigParams, wenn decay_period <= filter_period oder ein Feld mit Wert 0 außerhalb des gültigen Bereichs liegt.

UpdateDynamicFeeConfig (Admin)

Bestehende DynamicFeeConfig bearbeiten. Pools, die die Konfiguration bereits zum Erstellungszeitpunkt gespeichert haben, werden nicht rückwirkend aktualisiert; nur neu erstellte Pools, die auf diese Konfiguration verweisen, übernehmen die neuen Werte. Argumente — dieselben fünf Kalibrierungsfelder wie bei CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index wird bei der Erstellung festgelegt und hier nicht erneut übergeben.

CollectProtocolFee / CollectFundFee

Identische Struktur wie CPMMs CollectProtocolFee / CollectFundFee. Der Unterzeichner muss AmmConfig.owner / AmmConfig.fund_owner entsprechen. Aufgelaufene Protokoll-/Fondsgebühren werden aus den Pool-Vaults an einen Empfänger übertragen; die entsprechenden Felder PoolState.protocol_fees_* / fund_fees_* werden auf null gesetzt.

InitializeReward

Neuen Reward-Stream an einen Pool anhängen. Maximal 3 Streams können gleichzeitig aktiv sein. Argumente
open_time:     u64
end_time:      u64
emissions_per_second_x64: u128   // Q64.64
Accounts
#NameWS
1reward_funderWS
2funder_token_accountW
3amm_config
4pool_stateW
5operation_stateCLMM-Operation-State-PDA, der die Reward-Erstellung steuert.
6reward_token_mint
7reward_token_vaultWWird hier initialisiert.
8reward_token_program
9system_program, rent
Vorbedingungen
  • Weniger als 3 Streams derzeit am Pool aktiv.
  • Der Funder hinterlegt im Rahmen dieser Instruktion total_emission = emissions_per_second × (end_time − open_time) Reward-Token im Vault.
  • Reward-Mint gemäß operation_state auf der Whitelist.

SetRewardParams

Bestehenden Reward-Stream verlängern, auffüllen oder die Emissionsrate ändern. Wird typischerweise vom Pool-Ersteller oder dem Raydium-Multisig aufgerufen. Die Einschränkungen sind on-chain: end_time kann in der Regel verlängert oder die Emissionen erhöht werden, eine rückwirkende Verringerung ist nicht möglich. Prüfen Sie die Inhaberliste von operation_state.

UpdateRewardInfos

Reine Buchhaltung — rechnet reward_growth_global_x64 durch Multiplikation von emissions_per_second × Δt / liquidity auf den aktuellen Zeitpunkt ab. Wird intern von jeder liquiditätsberührenden Instruktion aufgerufen. Als eigenständige Instruktion verfügbar, da externe Akteure (UIs, Cranks) diese Abrechnung manchmal manuell auslösen möchten.

CollectReward

Position-Inhaber beansprucht ausstehende Reward-Token. Accounts
#NameWS
1nft_ownerS
2nft_accountATA des Inhabers mit dem Position-NFT.
3personal_positionW
4pool_stateW
5protocol_position
6reward_token_vaultW
7recipient_token_accountW
8token_program
9token_program_2022
Wirkung
  • Rechnet Reward-Wachstum ab (gleiche Logik wie bei Gebühren).
  • Überträgt den geschuldeten Betrag an die Empfänger-ATA; reward_amount_owed[i] wird auf null gesetzt.

Zustandsänderungsmatrix

Instruktionpool.liquiditypool.fee_growth_globalpool.reward_growth_globalpersonal_position.liquidityTick-Array
CreatePool00
OpenPosition+ wenn im Bereichneuliquidity_gross/net hinzufügen
IncreaseLiquidity+ wenn im Bereichausstehend abrechnenausstehend abrechnen+anpassen
DecreaseLiquidity− wenn im Bereichausstehend abrechnenausstehend abrechnenanpassen
ClosePositionaufgelöst
SwapV2± bei Kreuzungen+kreuzen & outside umkehren; Limit-Order-Kohorten matchen
OpenLimitOrderorders_amount += amount am Ziel-Tick
IncreaseLimitOrderorders_amount += amount
DecreaseLimitOrderorders_amount -=, kann Kohorte schließen
SettleLimitOrder— (Tick nur lesend)
CloseLimitOrder
CreateCustomizablePool00
UpdateRewardInfos+
CollectRewardausstehend abrechnen

Weiterführende Ressourcen

Quellen: