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 →

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):

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)

#	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 — ausführbare TypeScript-Beispiele.
• products/clmm/fees — Details zur Gebühren- und Reward-Akkumulation.
• reference/error-codes — vollständige CLMM-Anchor-Fehlertabelle.

Quellen:

• raydium-io/raydium-clmm — programs/amm/src/instructions
• Raydium SDK v2 — @raydium-io/raydium-sdk-v2