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 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
| Gruppe | Instruktion | Hinweise |
|---|
| Admin | CreateAmmConfig | Neue Fee-Stufe definieren. |
| Admin | UpdateAmmConfig | Raten einer bestehenden Stufe ändern. |
| Admin | UpdatePoolStatus | Operationen eines Pools pausieren/fortsetzen. |
| Admin | CreateSupportMintAssociated | Token-2022-Mint-Extension-Konfiguration für CLMM-Pools zulassen. |
| Admin | CreateOperationAccount | Programmweiten Operation-Account einmalig initialisieren. |
| Admin | UpdateOperationAccount | Whitelist des Operation-Accounts anpassen. |
| Admin | CreateDynamicFeeConfig | Wiederverwendbaren Dynamic-Fee-Parametersatz unter einem u16-Index anlegen. |
| Admin | UpdateDynamicFeeConfig | Bestehende DynamicFeeConfig bearbeiten. Pools, die die Konfiguration bereits gespeichert haben, bleiben unverändert. |
| Pool | CreatePool | CLMM-Pool an eine AmmConfig binden. Standardmäßiger FromInput-Fee-Pfad. Koexistiert mit CreateCustomizablePool. |
| Pool | CreateCustomizablePool | Empfohlen für neue Pools. Gleiche Struktur wie CreatePool, zusätzlich collect_fee_on und ein optionales enable_dynamic_fee-Flag. |
| Position | OpenPosition / OpenPositionV2 / OpenPositionWithToken22Nft | Position-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. |
| Position | IncreaseLiquidity / IncreaseLiquidityV2 | Liquidität zu einer bestehenden Position hinzufügen. |
| Position | DecreaseLiquidity / DecreaseLiquidityV2 | Liquidität entfernen; ausstehende Gebühren werden eingesammelt. |
| Position | ClosePosition | NFT verbrennen und PersonalPositionState schließen. |
| Position | CloseProtocolPosition | Nur 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. |
| Swap | Swap / SwapV2 | Constant-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). |
| Swap | SwapRouterBaseIn | Multi-Hop, vom Router genutzt. |
| Limit Order | OpenLimitOrder | Verkaufsorder an einem Tick platzieren. Nicht gefüllte Token verbleiben am Tick; die Matching-Engine füllt sie, sobald der Preis diesen Tick passiert. |
| Limit Order | IncreaseLimitOrder | Bestehende offene Order aufstocken. |
| Limit Order | DecreaseLimitOrder | Offene Order reduzieren oder stornieren; der ungefüllte Rest sowie bereits abgewickelte Ausgaben werden ausgezahlt. |
| Limit Order | SettleLimitOrder | Gefüllte Ausgabe-Token an den Order-Inhaber übermitteln. Aufrufbar durch den Inhaber oder den operativen Keeper. |
| Limit Order | CloseLimitOrder | Vollständig ausgeführten Order-Account schließen. Rent wird stets an den owner der Order zurückgegeben. Aufrufbar durch Inhaber oder Keeper. |
| Fees | CollectProtocolFee | Admin-Sweep der Protokollgebühren. |
| Fees | CollectFundFee | Admin-Sweep der Fondsgebühren. |
| Rewards | InitializeReward | Neuen Reward-Stream an einen Pool anhängen. |
| Rewards | SetRewardParams | Emissionsrate/Endzeitpunkt eines bestehenden Rewards ändern. |
| Rewards | UpdateRewardInfos | Reward-Wachstum bis jetzt abrechnen (wird von jedem Swap/jeder Positionsänderung aufgerufen). |
| Rewards | TransferRewardOwner | Autorität, die einen Reward-Stream einstellen oder auffüllen kann, übertragen. |
| Rewards | CollectRemainingRewards | Nach Ablauf von end_time eines Reward-Streams nicht zugeteilte Token an den Funder zurückführen. |
| Utility | InitTickArray | Tick-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)
| # | Name | W | S | Hinweise |
|---|
| 1 | pool_creator | W | S | |
| 2 | amm_config | | | Gewählte Fee-Stufe. |
| 3 | pool_state | W | | Wird hier initialisiert. |
| 4 | token_mint_0 | | | Sortiert. |
| 5 | token_mint_1 | | | |
| 6 | token_vault_0 | W | | Wird hier initialisiert, Eigentümer ist die Pool-Authority-PDA. |
| 7 | token_vault_1 | W | | |
| 8 | observation_state | W | | Wird hier initialisiert. |
| 9 | tick_array_bitmap_extension | W | | Wird hier initialisiert (V2). |
| 10 | token_program | | | |
| 11 | token_program_2022 | | | |
| 12 | system_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:
| # | Name | W | S | Hinweise |
|---|
| N | dynamic_fee_config | | | Die 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)
| # | Name | W | S | |
|---|
| 1 | payer | W | S | |
| 2 | position_nft_owner | | | |
| 3 | position_nft_mint | W | S (keypair) | |
| 4 | position_nft_account | W | | ATA des Inhabers für das NFT. |
| 5 | metadata_account | W | | Metaplex (optional, wenn with_metadata). |
| 6 | pool_state | W | | |
| 7 | protocol_position | | | |
| 8 | tick_array_lower | W | | Wird erstellt, falls nicht initialisiert. |
| 9 | tick_array_upper | W | | Ebenso. |
| 10 | personal_position | W | | Wird hier erstellt. |
| 11 | token_account_0, token_account_1 | W | | Quell-ATAs des Nutzers. |
| 12 | token_vault_0, token_vault_1 | W | | |
| 13 | rent, system_program, token_program | | | |
| 14 | associated_token_program | | | |
| 15 | metadata_program | | | Optional. |
| 16 | token_program_2022 | | | V2. |
| 17 | vault_0_mint, vault_1_mint | | | V2. |
| 18 | tick_array_bitmap_extension | W | | V2 (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 Fehler — InvalidTickIndex, 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.
Slippage — amount_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)
| # | Name | W | S | Hinweise |
|---|
| 1 | payer | | S | |
| 2 | amm_config | | | |
| 3 | pool_state | W | | |
| 4 | input_token_account | W | | |
| 5 | output_token_account | W | | |
| 6 | input_vault | W | | |
| 7 | output_vault | W | | |
| 8 | observation_state | W | | |
| 9 | token_program | | | |
| 10 | token_program_2022 | | | V2. |
| 11 | memo_program | | | V2 (für bestimmte Token-2022-Pfade erforderlich). |
| 12 | input_vault_mint, output_vault_mint | | | V2. |
| 13 | tick_array_bitmap_extension (optional) | W | | Wenn der Swap in die Extension hineinläuft. |
| 14+ | tick_array (remaining) | W | | Ausreichend 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 Fehler — ExceededSlippage, SqrtPriceLimitOverflow, TickArrayNotFound, LiquidityInsufficient.
Was SwapV2 intern tut, das Aufrufer wissen sollten (Release nach 2025):
- 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).
- 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.
- 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)
| # | Name | W | S | Hinweise |
|---|
| 1 | payer | W | S | Order-Inhaber; zahlt Rent. |
| 2 | pool_state | W | | |
| 3 | tick_array | W | | Das Tick-Array, das tick_index enthält. |
| 4 | limit_order_nonce | W | | PDA. init_if_needed — wird bei der ersten Order des Nutzers unter diesem nonce_index erstellt. |
| 5 | limit_order | W | | PDA. Wird hier initialisiert. |
| 6 | input_token_account | W | | Input-ATA des Nutzers. |
| 7 | input_vault | W | | Pool-Input-Vault. |
| 8 | input_vault_mint | | | Token-2022-Gebührenbehandlung. |
| 9 | input_token_program | | | SPL oder Token-2022. |
| 10 | system_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 Fehler — InvalidLimitOrderAmount (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):
| # | Name | W | S |
|---|
| 1 | owner | | S |
| 2 | pool_state | W | |
| 3 | tick_array | W | |
| 4 | limit_order | W | |
| 5 | input_token_account | W | |
| 6 | output_token_account | W | |
| 7 | input_vault | W | |
| 8 | output_vault | W | |
| 9 | input_vault_mint, output_vault_mint | | |
| 10 | token_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
| # | Name | W | S | |
|---|
| 1 | signer | | S | owner oder limit_order_admin |
| 2 | pool_state | | | |
| 3 | tick_array | | | |
| 4 | limit_order | W | | |
| 5 | output_token_account | W | | Output-ATA des Inhabers. |
| 6 | output_vault | W | | Pool-Output-Vault. |
| 7 | output_vault_mint | | | |
| 8 | output_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
| # | Name | W | S | Hinweise |
|---|
| 1 | owner | W | S | Fest programmierter Admin-Pubkey. |
| 2 | dynamic_fee_config | W | | PDA, wird hier initialisiert. |
| 3 | system_program | | | |
Häufige Fehler — InvalidDynamicFeeConfigParams, 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
| # | Name | W | S | |
|---|
| 1 | reward_funder | W | S | |
| 2 | funder_token_account | W | | |
| 3 | amm_config | | | |
| 4 | pool_state | W | | |
| 5 | operation_state | | | CLMM-Operation-State-PDA, der die Reward-Erstellung steuert. |
| 6 | reward_token_mint | | | |
| 7 | reward_token_vault | W | | Wird hier initialisiert. |
| 8 | reward_token_program | | | |
| 9 | system_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
| # | Name | W | S | |
|---|
| 1 | nft_owner | | S | |
| 2 | nft_account | | | ATA des Inhabers mit dem Position-NFT. |
| 3 | personal_position | W | | |
| 4 | pool_state | W | | |
| 5 | protocol_position | | | |
| 6 | reward_token_vault | W | | |
| 7 | recipient_token_account | W | | |
| 8 | token_program | | | |
| 9 | token_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
| Instruktion | pool.liquidity | pool.fee_growth_global | pool.reward_growth_global | personal_position.liquidity | Tick-Array |
|---|
CreatePool | 0 | 0 | — | — | — |
OpenPosition | + wenn im Bereich | — | — | neu | liquidity_gross/net hinzufügen |
IncreaseLiquidity | + wenn im Bereich | ausstehend abrechnen | ausstehend abrechnen | + | anpassen |
DecreaseLiquidity | − wenn im Bereich | ausstehend abrechnen | ausstehend abrechnen | − | anpassen |
ClosePosition | — | — | — | aufgelöst | — |
SwapV2 | ± bei Kreuzungen | + | — | — | kreuzen & outside umkehren; Limit-Order-Kohorten matchen |
OpenLimitOrder | — | — | — | — | orders_amount += amount am Ziel-Tick |
IncreaseLimitOrder | — | — | — | — | orders_amount += amount |
DecreaseLimitOrder | — | — | — | — | orders_amount -=, kann Kohorte schließen |
SettleLimitOrder | — | — | — | — | — (Tick nur lesend) |
CloseLimitOrder | — | — | — | — | — |
CreateCustomizablePool | 0 | 0 | — | — | — |
UpdateRewardInfos | — | — | + | — | — |
CollectReward | — | — | ausstehend abrechnen | — | — |
Weiterführende Ressourcen
Quellen: