> ## 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. # CLMM-Instruktionen > Vollständige CLMM-Instruktionsreferenz: Pool-Lebenszyklus, Positionsverwaltung, Swap und Reward-Streams. **Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.** [Englische Version ansehen →](/products/clmm/instructions) Diese Seite ergänzt [`products/clmm/accounts`](/de/products/clmm/accounts) (Beschreibung der Accounts) und [`products/clmm/math`](/de/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** ```rust theme={null} 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 // 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`](/de/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 ``` **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): 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`](/de/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)** | # | 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 * [`products/clmm/code-demos`](/de/products/clmm/code-demos) — ausführbare TypeScript-Beispiele. * [`products/clmm/fees`](/de/products/clmm/fees) — Details zur Gebühren- und Reward-Akkumulation. * [`reference/error-codes`](/de/reference/error-codes) — vollständige CLMM-Anchor-Fehlertabelle. Quellen: * [`raydium-io/raydium-clmm` — `programs/amm/src/instructions`](https://github.com/raydium-io/raydium-clmm) * Raydium SDK v2 — `@raydium-io/raydium-sdk-v2`