CLMM-Anweisungen

​

Anweisungsübersicht

​

CreatePool

sqrt_price_x64: u128           // Anfangspreis
open_time:      u64            // Swaps werden vor dieser Zeit abgelehnt

• token_mint_0 < token_mint_1 nach Byte-Reihenfolge.
• amm_config.disable_create_pool == false.
• Mints werden nicht durch die Token-2022-Erweiterungs-Allowlist abgelehnt.

• 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 (dynamische Gebühr deaktiviert).

​

CreateCustomizablePool

pub struct CreateCustomizableParams {
    pub sqrt_price_x64:    u128,
    pub collect_fee_on:    CollectFeeOn,   // FromInput | Token0Only | Token1Only
    pub enable_dynamic_fee: bool,
}

• pool_state.fee_on auf die gewählte CollectFeeOn-Variante gesetzt.
• Wenn dynamische Gebühr aktiviert wurde: pool_state.dynamic_fee_info wird aus der bereitgestellten DynamicFeeConfig initialisiert (fünf Kalibrierungsparameter kopiert; Zustandsfelder auf Null gesetzt).
• Andernfalls: pool_state.dynamic_fee_info ist auf Null gesetzt (= dynamische Gebühr für immer inaktiv für diesen Pool).

​

CreatePermissionedPool

customizable_params: CreateCustomizableParams   // gleiche Struktur wie CreateCustomizablePool
seed_index:          u16                          // muss ungleich Null sein; wird in die Pool-PDA-Seeds gefaltet

• seed_index != 0. Ein seed_index von 0 ist für Legacy-Pools reserviert und wird hier abgelehnt; die [0, 0]-Seed-Komponente ist das, was eine Legacy-Pool-Adresse zum Zusammenbruch in die klassische Vier-Seed-Form führt.
• Die permission-PDA für payer existiert (erstellt von einem Admin über CreatePermissionPda).
• Gleiche Mint- / Allowlist-Regeln wie CreatePool.

• Ein neuer pool_state existiert unter der seed_index-abgeleiteten Adresse, mit pool_state.seed_index = seed_index.
• Alle anderen Post-State-Matches CreateCustomizablePool (Gebührenmodus, optionale dynamische Gebühr).

​

OpenPositionV2 / OpenPositionWithToken22Nft

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 Beträge unten zu verwenden)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // schreibe NFT-Metadaten (Metaplex)
base_flag: Option<bool>       // true = passe zu amount0 an; false = passe zu amount1 an

• tick_lower < tick_upper, beide Vielfache von pool.tick_spacing, innerhalb von [MIN_TICK, MAX_TICK].
• Die beiden Tick-Array-PDAs werden übergeben. Sie müssen nicht bereits existieren — get_or_create_tick_array ordnet eine fehlende innerhalb dieser Anweisung auf Kosten von payer zu. Es gibt keine separate Init-Tick-Array-Anweisung.
• Der Benutzer hat mindestens amount_0_max und amount_1_max in den Quell-ATAs.

• personal_position existiert, liquidity gesetzt, fee_growth_inside_last abgebildet.
• Tick-Array-Einträge bei tick_lower und tick_upper aktualisiert (liquidity_gross += L, liquidity_net ± L, Gebührenwachstums-Snapshots gepflegt).
• pool_state.liquidity += L, wenn die Position im Bereich ist (tick_lower ≤ tick_current < tick_upper).
• Der Positions-NFT-Mint zeichnet pool_state als Freeze-Autorität auf. Die Mint-Autorität wird nach dem Prägen der einzelnen NFT entfernt. Das Aufzeichnen der Freeze-Autorität ändert den Zustand des NFT-Token-Kontos nicht.
• Das NFT-Token-Konto bleibt aufgetaut, es sei denn, die Anweisung ist OpenPositionV2 oder OpenPositionWithToken22Nft und die Freeze-Autorität eines Vault-Mints entspricht CLMMs Liste der eingeschränkten Aussteller. Nur dieser passende V2-Pfad friert das Konto ein. OpenPosition V1 friert nicht ein.

​

IncreaseLiquidityV2

liquidity: u128
amount_0_max: u64
amount_1_max: u64
base_flag: Option<bool>

• Überträgt amount_0_actual / amount_1_actual von Benutzer → Vaults.
• Erhöht personal_position.liquidity und pool_state.liquidity (wenn im Bereich), und die Endpunkt-Tick-liquidity_gross / liquidity_net entsprechend.
• Sammelt Gebühren und Rewards, die seit der letzten Berührung fällig sind und schreibt sie token_fees_owed_{0,1} / reward_amount_owed gut. Diese werden nur bei DecreaseLiquidity / DecreaseLiquidityV2 ausgezahlt, nicht bei Erhöhung — es gibt keine eigenständige Collect-Anweisung.

​

DecreaseLiquidityV2

liquidity: u128
amount_0_min: u64
amount_1_min: u64

• Berechnet (amount_0, amount_1) für das entfernte L gegeben aktuelles sqrt_price_x64.
• Setzt Gebühren/Rewards ab, die seit der letzten Berührung aufgelaufen sind, gleich wie IncreaseLiquidity.
• Überträgt amount_0 + fees_owed_0 und amount_1 + fees_owed_1 aus Vaults zum Benutzer.
• Verringert Liquiditätszähler; wenn die neue personal_position.liquidity == 0, ist die Position berechtigt für ClosePosition.

​

ClosePosition

• Aufgetaute NFT: keine erforderlich; ein zusätzliches Pool-Konto ist harmlos, da der Handler es nicht liest.
• Gefrorene NFT: hängen Sie personal_position.pool_id als erstes verbleibendes Konto an. Das Programm lädt es als PoolState und verwendet seine PDA-Seeds zum Signieren des Auftauens.

• personal_position.liquidity == 0.
• tokens_fees_owed_{0,1} == 0.
• Alle Reward-Zähler reward_amount_owed == 0.

• Wenn das NFT-Token-Konto eingefroren ist, überprüft, ob das erste verbleibende Konto personal_position.pool_id entspricht, und taut es dann mit der Pool-PDA auf.
• Verbrennt die NFT.
• Schließt das NFT-Token-Konto und personal_position, erstattet Miete an nft_owner. Wenn die Positions-NFT Token-2022 verwendet, schließt es auch den NFT-Mint; klassische SPL Token-Mints können nicht geschlossen werden und bleiben mit Angebot Null.

​

SwapV2

amount: u64                  // Eingabe, wenn is_base_input=true, Ausgabe andernfalls
other_amount_threshold: u64  // Min-Out oder Max-In
sqrt_price_limit_x64: u128   // harte Grenze; 0 ⇒ unbegrenzt
is_base_input: bool

• pool_state.status erlaubt Swap.
• now >= open_time.
• sqrt_price_limit_x64 ist auf der korrekten Seite von sqrt_price_x64 für die Richtung.

1. Dynamic-Fee-Zuschlag — wenn pool.dynamic_fee_info ungleich Null ist, aktualisiert das Programm den Volatilitäts-Akkumulator unter Verwendung der seit dem letzten Swap durchquerten Tick-Distanz (mit den Filter-/Decay-Regeln aus products/clmm/fees) und fügt eine dynamic_fee_component auf AmmConfig.trade_fee_rate hinzu. Die Gesamtgebühr ist auf 10% begrenzt (MAX_FEE_RATE_NUMERATOR / 1_000_000).
2. Limit-Order-Matching — wenn der Preis-Walk einen Tick kreuzt, der offene Limit-Orders hält, erfüllt das Programm zuerst verfügbare Limit-Order-Liquidität bei diesem Tick (FIFO nach order_phase), dann geht es entlang der LP-Liquiditätskurve weiter. Erfüllte Beträge aktualisieren tick.unfilled_ratio_x64 und tick.part_filled_orders_remaining für spätere Abwicklung; Orders selbst bleiben unausgegeben, bis ihr Eigentümer SettleLimitOrder aufruft.
3. Einseitige Gebührenrouting — wenn pool.fee_on = Token0Only oder Token1Only, berechnet der Swap-Schritt immer noch die gleiche Input-Output-Trade; die Gebühr wird dann zur konfigurierten Seite geleitet. Für Richtungen, bei denen die konfigurierte Gebührenseite die Ausgabe ist, wird die Gebühr von der Swap-Ausgabe abgezogen (der Benutzer erhält out − fee); für Richtungen, bei denen sie die Eingabe ist, entspricht das Verhalten FromInput. Siehe is_fee_on_input(zero_for_one) und is_fee_on_token0(zero_for_one) auf PoolState.

​

OpenLimitOrder

nonce_index:    u8       // vom Benutzer gewählter Nonce-Konto-Index (0..255 pro Wallet)
zero_for_one:   bool     // true: verkaufe token0 für token1; false: verkaufe token1 für token0
tick_index:     i32      // muss ein Vielfaches von pool.tick_spacing sein
amount:         u64      // Input-Token-Betrag

• Weder input_token_account noch output_token_account ist eingefroren (andernfalls NotApproved).
• pool_state.status erlaubt sowohl Swap (Bit 4) als auch Limit-Order (Bit 5) Operationen (andernfalls NotApproved).
• tick_index % pool.tick_spacing == 0 und innerhalb von [MIN_TICK, MAX_TICK].
• tick_index ist auf der rechten Seite von pool.tick_current für die gewählte Richtung (Verkauf von token0 → Tick muss über aktuell sein, und umgekehrt). Der Verkauf bei einem bereits gekreuzten Tick würde sofort erfüllt und wird abgelehnt.

• limit_order existiert, Snapshot von tick.order_phase und tick.unfilled_ratio_x64 zur Öffnungszeit.
• tick.orders_amount += amount (in der aktuellen Kohorte).
• limit_order_nonce.order_nonce += 1.
• OpenLimitOrderEvent emittiert.

​

IncreaseLimitOrder

amount: u64    // zusätzlicher Input-Token-Betrag

• limit_order.owner == signer.
• Die Order ist immer noch in der gleichen Kohorte (tick.order_phase == limit_order.order_phase). Wenn die Kohorte bereits mit dem Füllen begonnen hat, ist die Order teilweise abgewickelt — der Aufrufer sollte zuerst DecreaseLimitOrder oder SettleLimitOrder aufrufen, um voranzukommen.

• Überträgt amount von Eigentümer-ATA zu input_vault.
• limit_order.total_amount += amount; tick.orders_amount += amount.

​

DecreaseLimitOrder

amount:     u64    // Input-Token-Betrag zum Abheben (max = unerfüllter Rest)
amount_min: u64    // Slippage-Boden auf der Input-seitigen Abhebung

• Berechnet den erfüllten Betrag der Order aus der unfilled_ratio_x64 der Kohorte seit der Öffnung neu.
• Sendet erfüllte Ausgabe zu output_token_account.
• Sendet amount unerfüllter Eingabe zurück zu input_token_account.
• Aktualisiert limit_order entsprechend. Wenn der neue unerfüllte Rest Null ist, schließt das Programm das Konto und erstattet Miete an owner.

​

SettleLimitOrder

• Berechnet die kumulierte Ausgabe, die unter Verwendung von (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) geschuldet wird.
• Überträgt das Delta zu output_token_account.
• Aktualisiert limit_order.settled_output.
• Schließt die Order nicht; sie ist immer noch gegen verbleibende Eingabe offen.

​

CloseLimitOrder

• Die Order hat einen unerfüllten Rest von Null (entweder amount == total_amount wurde erfüllt und abgewickelt, oder der Eigentümer hat die Order zuvor auf Null verringert und vergessen zu schließen).

• Schließt limit_order; Miete wird an limit_order.owner gesendet.

​

CreateDynamicFeeConfig (Admin)

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; Gewinn auf der Volatilitäts-zu-Gebühren-Kurve
max_volatility_accumulator:  u32   // Obergrenze

​

UpdateDynamicFeeConfig (Admin)

​

CollectProtocolFee / CollectFundFee

​

CollectExcessLamports