CLMM-Konten

Jedes Konto, das ein CLMM-Pool berührt: PoolState, AmmConfig, TickArrayState, TickArrayBitmapExtension, PersonalPositionState und Observation.

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.

Englische Version ansehen →

Diese Seite beschreibt das Layout und die Rolle jedes Kontos. Seeds sind kanonisch und in reference/program-addresses aufgelistet. Ein CLMM-Pool ist kontointensiver als ein CPMM-Pool, da Liquidität spärlich über den Tick-Bereich verteilt ist; das Verständnis dieser Spärlichkeit ist der Kern dieser Seite.

​

Kontobestand

Ein aktiver CLMM-Pool wird durch die folgenden Kontofamilien beschrieben. Alle werden vom CLMM-Programm verwaltet, außer den beiden Mints und ihren Vaults.

Konto	Zweck	Anzahl pro Pool
AmmConfig	Gebührentier: Handelsgebührsatz, Protokollanteil, Fondsanteil, Standard-Tick-Abstand. Gemeinsam für alle Pools in diesem Tier.	1 (gemeinsam)
PoolState	Aktueller sqrt_price_x64, aktueller Tick, Gesamtliquidität, globale Gebührenwachstumswerte, Reward-Info, Observation-Zeiger.	1
TickArrayState	Ein Block von TICK_ARRAY_SIZE benachbarten Ticks. Nur bei Bedarf initialisiert.	0 ≤ N ≤ Bereich
TickArrayBitmapExtension	Overflow-Bitmap, die verfolgt, welche Tick-Arrays über die Inline-Bitmap in PoolState hinaus existieren.	0 oder 1
PersonalPositionState	Eine pro LP-Position. Speichert den Bereich, die Liquidität und das zuletzt gesehene Gebühren-/Reward-Wachstum. Authority = NFT-Besitzer.	1 pro Position
Position-NFT-Mint	Mint mit Angebot 1, verknüpft mit PersonalPositionState. Sein Token-Konto ist standardmäßig nicht eingefroren; V2 friert es nur ein, wenn ein zugrunde liegender Mint dem Filter für eingeschränkte Aussteller entspricht.	1 pro Position
ObservationState	Ringpuffer von Preisbeobachtungen für den TWAP.	1
token_0_vault, token_1_vault	Token-Konten, die die Pool-Guthaben halten. Verwaltet durch Pool-Authority.	2
DynamicFeeConfig	Wiederverwendbarer Parametersatz für den dynamischen Gebührenmechanismus. Pools, die über create_customizable_pool erstellt werden, können sich anmelden. Admin-verwaltet.	gemeinsam (pro Index)
LimitOrderState	Eine pro offene Limit-Order. Speichert Besitzer, Tick, Seite, Gesamtbetrag, Snapshot der abgerechneten Ausgabe.	1 pro Order
LimitOrderNonce	Pro-(wallet, nonce_index) Zähler, der eindeutige Order-PDAs ableitet.	1 pro (Wallet, Index)

​

PoolState

Der Live-Status des Pools, gelesen bei jedem Swap und jeder Positionsänderung.

// programs/amm/src/states/pool.rs
pub struct PoolState {
    pub bump:           [u8; 1],
    pub amm_config:     Pubkey,            // fee tier binding
    pub owner:          Pubkey,            // admin (multisig)
    pub token_mint_0:   Pubkey,
    pub token_mint_1:   Pubkey,
    pub token_vault_0:  Pubkey,
    pub token_vault_1:  Pubkey,
    pub observation_key: Pubkey,

    pub mint_decimals_0: u8,
    pub mint_decimals_1: u8,
    pub tick_spacing:   u16,               // inherited from amm_config at init

    pub liquidity:      u128,              // total active (in-range) liquidity
    pub sqrt_price_x64: u128,              // Q64.64 of sqrt(price)
    pub tick_current:   i32,               // current tick index

    pub padding3:       u16,
    pub padding4:       u16,

    // Global fee growth per unit of liquidity, Q64.64.
    pub fee_growth_global_0_x64: u128,
    pub fee_growth_global_1_x64: u128,

    // Accrued-but-not-swept protocol fees (per mint).
    pub protocol_fees_token_0: u64,
    pub protocol_fees_token_1: u64,

    // Reserved padding for future upgrades.
    pub padding5: [u128; 4],

    // Status bitmask. Bits 0-5: open-position, decrease-liquidity,
    // collect-fee, collect-reward, swap, limit-order. A set bit disables
    // the corresponding operation.
    pub status:  u8,

    // Fee-collection mode (CollectFeeOn).
    //   0 = FromInput (deduct fee from the swap input — Uniswap-V3 default)
    //   1 = Token0Only (always deduct fee from token0 vault)
    //   2 = Token1Only (always deduct fee from token1 vault)
    pub fee_on: u8,

    // Client-supplied index (u16 LE) folded into the pool PDA seeds by
    // create_customizable_pool_v2. [0, 0] for pools created via CreatePool /
    // CreateCustomizablePool (the seed component collapses to empty).
    pub seed_index: [u8; 2],
    pub padding: [u8; 4],

    // Live reward streams (up to REWARD_NUM = 3).
    pub reward_infos: [RewardInfo; 3],

    // Inline bitmap tracking initialized tick-arrays in the primary range.
    pub tick_array_bitmap: [u64; 16],

    // Reserved padding for future upgrades.
    pub padding6: [u64; 4],

    pub fund_fees_token_0: u64,
    pub fund_fees_token_1: u64,

    pub open_time:    u64,                 // currently disabled by the program
    pub recent_epoch: u64,

    // Per-pool dynamic-fee state. Zero-valued unless the pool was
    // created with `enable_dynamic_fee = true` via create_customizable_pool.
    pub dynamic_fee_info: DynamicFeeInfo,

    // Reserved for future upgrades.
    pub padding1: [u64; 14],
    pub padding2: [u64; 32],
}

Felder, die Sie tatsächlich verwenden werden:

• sqrt_price_x64 und tick_current sind der Preisstatus des Pools. Sie werden bei jedem Swap zusammen aktualisiert. tick_current ist die Untergrenze von log_{1.0001}(price).
• liquidity ist die aktive Liquidität — die Summe der L-Werte für alle Positionen, deren Bereich tick_current enthält. Sie ändert sich jedes Mal, wenn ein Swap einen Tick kreuzt, und jedes Mal, wenn eine Position geöffnet/geschlossen/angepasst wird.
• fee_growth_global_{0,1}_x64 sind die kumulativen Gebühren pro Liquiditätseinheit über die gesamte Pool-Historie. Positionen lesen dies, um zu berechnen, was ihnen geschuldet wird.
• tick_spacing ist bei der Initialisierung an die AmmConfig gebunden und ändert sich nie. Es bestimmt, welche Tick-Indizes als Positionsendpunkte zulässig sind.
• tick_array_bitmap ist eine Inline-Bitmap, die den häufig verwendeten Tick-Bereich um den Spotpreis abdeckt. Für Pools, deren Positionen weit reichen, lebt die Overflow-Verfolgung in der separaten TickArrayBitmapExtension.
• fee_on ist bei der Pool-Erstellung festgelegt. 0 (FromInput) reproduziert das klassische Uniswap-V3-Verhalten. 1 und 2 leiten die Swap-Gebühr auf eine einzelne Seite des Buches — siehe products/clmm/fees für Abwägungen.
• seed_index ist [0, 0] für jeden Pool, der über CreatePool / CreateCustomizablePool erstellt wird (ein kanonischer Pool pro Paar). Ein nicht-null Wert bedeutet, dass der Pool über CreateCustomizablePoolV2 (vor 2026-10-22 CreatePermissionedPool genannt) erstellt wurde und der Index Teil der Pool-PDA-Seeds ist, was mehrere Pools für dasselbe (config, mint0, mint1) ermöglicht. Um die Adresse eines solchen Pools erneut abzuleiten, müssen Sie seinen seed_index kennen.
• dynamic_fee_info trägt Volatilitätsstatus für den dynamischen Gebührenzuschlag. Wenn aktiviert, berechnet jeder Swap eine dynamic_fee_component zusätzlich zu AmmConfig.trade_fee_rate neu. Das Layout ist unter DynamicFeeInfo unten dokumentiert; Pools ohne dynamische Gebühr lassen die gesamte Struktur null.

​

AmmConfig

pub struct AmmConfig {
    pub bump: u8,
    pub index: u16,                       // uses "amm_config"+u16 seed

    pub owner:             Pubkey,        // protocol-fee owner (CollectProtocolFee)
    pub protocol_fee_rate: u32,           // fraction of trade fee to protocol, denom 1e6
    pub trade_fee_rate:    u32,           // trade fee in 1e6ths of volume
    pub tick_spacing:      u16,           // default spacing for pools using this config
    pub fund_fee_rate:     u32,           // fraction of trade fee to fund, denom 1e6
    pub padding_u32: u32,

    pub fund_owner: Pubkey,               // fund-fee owner (CollectFundFee)
    pub padding: [u64; 3],
}

Seit dem Upgrade von 2026-09 schreibt CreateAmmConfig die hardcodierte protocol_fee_owner::ID des Programms in owner und fund_fee_owner::ID in fund_owner. Davor kopierte es den Schlüssel des Admin-Signers in beide. Bestehende Konfigurationen behalten, was sie erstellt oder rotiert wurden, also lesen Sie beide Felder vom Konto. UpdateAmmConfig-Parameter 3 / 4 rotieren sie immer noch. Adressen sind in reference/program-addresses aufgelistet.

Ein typischer veröffentlichter Satz von CLMM-Gebührentiers (bestätigen Sie gegen GET https://api-v3.raydium.io/main/clmm-config):

Index	trade_fee_rate	Tick-Abstand	Typische Verwendung
0	100 (0,01%)	1	Stabile Paare, USDC/USDT
1	500 (0,05%)	10	Korrelierte Blue-Chips
2	2_500 (0,25%)	60	Standard-Paare
3	10_000 (1,00%)	120	Volatile oder Long-Tail

protocol_fee_rate und fund_fee_rate sind Anteile der Handelsgebühr; gleiche Konvention wie CPMM. Siehe products/clmm/fees.

​

TickArrayState

CLMM speichert nicht einen einzelnen Datensatz pro Tick. Das würde Milliarden von Konten bedeuten. Stattdessen gruppiert es TICK_ARRAY_SIZE benachbarte initialisierte oder nicht initialisierte Ticks (typischerweise 60 oder 88, je nach Programmversion) in einen TickArrayState, der bei der ersten Verwendung lazy erstellt wird.

pub const TICK_ARRAY_SIZE: usize = 60;
pub const TICK_ARRAY_SIZE_USIZE: usize = 60;

pub struct TickArrayState {
    pub pool_id:                Pubkey,
    pub start_tick_index:       i32,                            // lowest tick in this array
    pub ticks:                  [TickState; TICK_ARRAY_SIZE],   // 60 entries
    pub initialized_tick_count: u8,
    pub recent_epoch:           u64,
    pub padding:                [u8; 107],
}

pub struct TickState {
    pub tick:                       i32,
    pub liquidity_net:              i128,                       // ΔL when crossing this tick upward
    pub liquidity_gross:            u128,                       // total L referencing this tick
    pub fee_growth_outside_0_x64:   u128,                       // see math.mdx
    pub fee_growth_outside_1_x64:   u128,
    pub reward_growths_outside_x64: [u128; 3],

    // Limit-order bookkeeping. All zero for ticks that have never carried
    // a limit order. See products/clmm/math for the matching algorithm.
    pub order_phase:                  u64,                      // monotonic FIFO cohort id
    pub orders_amount:                u64,                      // unfilled tokens in current cohort
    pub part_filled_orders_remaining: u64,                      // remaining tokens of partially-filled cohort
    pub unfilled_ratio_x64:           u128,                     // Q64.64; starts at 1.0 and shrinks as fills occur

    pub padding:                    [u32; 3],
}

Die vier Limit-Order-Felder sind null auf jedem Tick, der noch nie für eine Limit-Order verwendet wurde. Wenn Orders auf einem Tick eröffnet werden, verfolgt das Programm sie als eine Sequenz von Kohorten:

• order_phase ist die Kohorten-ID. Sie erhöht sich jedes Mal, wenn eine Kohorte von „vollständig ungefüllt” zu „teilweise gefüllt” übergeht.
• orders_amount ist die Input-Token-Summe der aktuellen (neuesten) Kohorte.
• part_filled_orders_remaining verfolgt die vorherige Kohorte, die derzeit durch laufende Swaps gefüllt wird.
• unfilled_ratio_x64 ist ein Q64.64-Multiplikator, der auf der Kohorte gespeichert wird: Wenn ein Swap X% der Kohorte füllt, wird das Verhältnis mit (1 − X) multipliziert. Jede offene Order speichert ihren eigenen (order_phase, unfilled_ratio_x64)-Snapshot zum Zeitpunkt der Eröffnung, sodass die Settle-Mathematik auf den Vergleich von Snapshots reduziert wird.

Regeln:

• Ein Positions-Endpunkt-Tick t muss t % tick_spacing == 0 erfüllen. Das Programm lehnt Positionen mit falscher Abstände ab.
• Das Array des Ticks befindet sich unter floor(t / (TICK_ARRAY_SIZE * tick_spacing)) * (TICK_ARRAY_SIZE * tick_spacing).
• Ein Tick-Array wird lazy initialisiert: Die erste Position oder der erste Swap, der ein nicht initialisiertes Array berührt, erstellt es und zahlt die Miete.
• Ein Tick-Array wird vom Programm nie geschlossen. Nach der Zuweisung bleibt es für die Lebensdauer des Pools bestehen, auch nachdem jeder Tick darin zu liquidity_gross == 0 zurückgekehrt ist. Nachfolgende Positionen und Swaps verwenden das vorhandene Konto ohne zusätzliche Miete wieder. Es gibt keinen ClosePosition-gesteuerten Bereinigungspfad für Tick-Arrays.

​

TickArrayBitmapExtension

PoolState.tick_array_bitmap (inline) deckt den „nahe am Spot”-Bereich ab — ±512 Tick-Arrays (TICK_ARRAY_BITMAP_SIZE = 512; das [u64; 16]-Feld ist 1.024 Bits, gleichmäßig zwischen negativen und positiven Start-Indizes aufgeteilt, also Array-Indizes −512 … +511). Außerhalb dieses Bereichs (für extreme Tick-Werte) verwaltet das Programm ein Erweiterungskonto:

pub struct TickArrayBitmapExtension {
    pub pool_id: Pubkey,
    pub positive_tick_array_bitmap: [[u64; 8]; 14],
    pub negative_tick_array_bitmap: [[u64; 8]; 14],
}

Wenn der Bereich Ihrer Position „normal” ist, denken Sie nie über das Erweiterungskonto nach. Full-Range-Positionen (z. B. (MIN_TICK, MAX_TICK)) erfordern es; das SDK löst es für Sie auf.

​

Positionen

Eine CLMM-Position ist ein Bündel aus drei Konten plus einem Mint:

​

Position-NFT-Mint

Ein SPL-Token oder Token-2022-Mint mit Supply 1. Das Position-NFT in der Wallet des Besitzers ist ein ATA, das diesen einzelnen Token hält. Das Programm bindet die Autorisierung an den aktuellen Inhaber des NFT-ATA-Guthabens, nicht an einen in der State gespeicherten Pubkey.

Neue Position-NFT-Mints setzen pool_state als ihre Freeze-Authority, bevor sie den einzelnen Token prägen und die Mint-Authority entfernen. Das Setzen einer Freeze-Authority friert das NFT-Konto nicht selbst ein. Das Konto bleibt ungefroren und übertragbar, es sei denn, beide Bedingungen sind erfüllt: Der Aufrufer verwendet OpenPositionV2 oder OpenPositionWithToken22Nft, und mindestens eine zugrunde liegende Vault-Mint-Freeze-Authority erscheint auf CLMMs Restricted-Issuer-Liste. Nur dann friert CLMM das NFT-Konto nach dem Prägen ein. Dies ändert keine PersonalPositionState- oder PoolState-Bytes.

​

PersonalPositionState

Eines pro offene Position. Basierend auf dem NFT-Mint.

pub struct PersonalPositionState {
    pub bump: [u8; 1],
    pub nft_mint: Pubkey,                 // this position's NFT mint
    pub pool_id:  Pubkey,

    pub tick_lower_index: i32,
    pub tick_upper_index: i32,

    pub liquidity: u128,                  // this position's L

    // Fee-growth snapshots at last time the position was touched.
    pub fee_growth_inside_0_last_x64: u128,
    pub fee_growth_inside_1_last_x64: u128,
    pub token_fees_owed_0: u64,           // accrued since last collect
    pub token_fees_owed_1: u64,

    pub reward_infos: [PositionRewardInfo; 3],
    pub recent_epoch: u64,
    pub padding: [u64; 7],
}

pub struct PositionRewardInfo {
    pub growth_inside_last_x64: u128,
    pub reward_amount_owed: u64,
}

​

ProtocolPositionState (veraltet)

Ältere CLMM-Versionen speicherten aggregierte Pro-(pool, tick_lower, tick_upper)-Buchführung in einem ProtocolPositionState-PDA. Neuere Versionen erstellen oder lesen dieses Konto nicht mehr. Der Slot erscheint immer noch in den OpenPosition- / IncreaseLiquidity- / DecreaseLiquidity-Kontolisten als UncheckedAccount für ABI-Kompatibilität, aber das Programm schreibt nicht darauf. Vorhandene Konten in der Chain sind vestigial; der Admin kann CloseProtocolPosition aufrufen, um die Miete dafür zurückzufordern.

Die aggregierte Bereichsbuchführung wird jetzt direkt aus den zwei Endpunkt-Ticks (liquidity_gross, liquidity_net und den Pro-Tick-fee_growth_outside_* / reward_growths_outside_x64) in TickArrayState abgeleitet. Die Fee-Growth-Inside-Formel fee_growth_inside = global − outside_lower − outside_upper funktioniert weiterhin ohne ein aggregiertes Positions-Konto.

​

Observation

pub const OBSERVATION_NUM: usize = 100;

pub struct Observation {
    pub block_timestamp: u32,
    pub tick_cumulative: i64,                            // Σ tick_current × Δt
    pub padding:         [u64; 4],
}

pub struct ObservationState {
    pub initialized:       bool,
    pub recent_epoch:      u64,
    pub observation_index: u16,
    pub pool_id:           Pubkey,
    pub observations:      [Observation; OBSERVATION_NUM], // 100 entries
    pub padding:           [u64; 4],
}

CLMMs Observation-Buffer speichert einen kumulativen Tick, keinen kumulativen Preis. Externe Consumer berechnen den geometrischen Mittelpreis über ein Intervall aus (tick_cumulative[t1] − tick_cumulative[t0]) / (t1 − t0) und dann price = 1.0001 ** tick. Siehe algorithms/clmm-math.

​

DynamicFeeConfig und DynamicFeeInfo

Parameter für dynamische Gebühren befinden sich an zwei Stellen. Die wiederverwendbare Vorlage — DynamicFeeConfig — wird vom Admin verwaltet und von Pools gemeinsam genutzt, die sich dafür entscheiden. Der Pro-Pool-Laufzeitzustand — DynamicFeeInfo — ist in PoolState eingebettet und wird bei jedem Swap aktualisiert.

​

DynamicFeeConfig

// programs/amm/src/states/pool_fee.rs
pub struct DynamicFeeConfig {
    pub index:                       u16,    // identifier; PDA seed component
    pub filter_period:               u16,    // seconds — within this window the volatility reference is held
    pub decay_period:                u16,    // seconds — beyond this window the reference fully decays
    pub reduction_factor:            u16,    // fixed-point in [1, 10_000); applied at decay
    pub dynamic_fee_control:         u32,    // fixed-point in (0, 100_000); fee-rate gain
    pub max_volatility_accumulator:  u32,    // ceiling on the volatility accumulator
    pub padding:                     [u64; 8],
}

PDA-Seed: ["dynamic_fee_config", index.to_be_bytes()]. Erstellt über create_dynamic_fee_config (Admin-gated) und modifiziert über update_dynamic_fee_config. Ein Pool, der mit enable_dynamic_fee = true erstellt wird, speichert die fünf Kalibrierungsparameter der Config (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator) zum Erstellungszeitpunkt in seinen eigenen DynamicFeeInfo; spätere Änderungen an DynamicFeeConfig beeinflussen bestehende Pools nicht rückwirkend.

​

DynamicFeeInfo (eingebettet in PoolState)

pub struct DynamicFeeInfo {
    pub filter_period:                u16,
    pub decay_period:                 u16,
    pub reduction_factor:             u16,
    pub dynamic_fee_control:          u32,
    pub max_volatility_accumulator:   u32,
    pub tick_spacing_index_reference: i32,    // tick-spacing-units; reference for next swap
    pub volatility_reference:         u32,    // running floor for the accumulator
    pub volatility_accumulator:       u32,    // current cumulative volatility (capped)
    pub last_update_timestamp:        u64,
    pub padding:                      [u8; 46],
}

Die unteren vier Felder sind State; die oberen fünf sind Kalibrierung, die aus DynamicFeeConfig kopiert wurde. Die Gebühren-Mathematik und die Decay-Regeln sind unter products/clmm/math und products/clmm/fees dokumentiert.

Von der Formel verwendete Konstanten:

Konstante	Wert	Bedeutung
VOLATILITY_ACCUMULATOR_SCALE	10_000	Granularität des Volatilitäts-Akkumulators
REDUCTION_FACTOR_DENOMINATOR	10_000	Nenner für reduction_factor
DYNAMIC_FEE_CONTROL_DENOMINATOR	100_000	Nenner für dynamic_fee_control
MAX_FEE_RATE_NUMERATOR	100_000	Hard Cap von 10% auf die resultierende Gebührenrate

​

LimitOrderState

Ein Konto pro offene Limit-Order.

// programs/amm/src/states/limit_order.rs
pub struct LimitOrderState {
    pub pool_id:            Pubkey,
    pub owner:              Pubkey,
    pub tick_index:         i32,
    pub zero_for_one:       bool,    // direction: true sells token0 for token1
    pub order_phase:        u64,     // snapshot of TickState.order_phase at open time
    pub total_amount:       u64,     // input-token amount placed
    pub filled_amount:      u64,     // informational; computed precisely on settle
    pub settle_base:        u64,     // unfilled remainder at last settle/decrease
    pub settled_output:     u64,     // cumulative output-token paid to owner
    pub open_time:          u64,
    pub unfilled_ratio_x64: u128,    // Q64.64 snapshot of TickState.unfilled_ratio_x64 at open
    pub padding:            [u64; 4],
}

Lebenszyklus:

1. Open — Der Benutzer ruft open_limit_order auf, hinterlegt total_amount des Input-Tokens, die Order wird an eine TickState-Kohorte gebunden.
2. (optional) Increase / Decrease — increase_limit_order addiert zu total_amount; decrease_limit_order gibt ungefüllte Tokens zurück (und jede bis dahin abgerechnete Ausgabe).
3. Settle — Wenn die Kohorte vollständig oder teilweise gefüllt ist, ruft der Besitzer oder der operationale Keeper settle_limit_order auf, um Output-Tokens an das ATA des Besitzers zu übertragen.
4. Close — Sobald unfilled_amount == 0, ist das Konto schließbar. Die Miete wird immer an owner zurückgegeben.

PDA-Seed: [owner.as_ref(), limit_order_nonce.key().as_ref(), limit_order_nonce.order_nonce.to_be_bytes().as_ref()]. Das Order-PDA ist daher eindeutig pro (owner, nonce_index, order_nonce).

​

LimitOrderNonce

Ein Pro-(wallet, nonce_index)-Zähler, der es einem einzelnen Benutzer ermöglicht, mehrere parallele Pipelines von Limit-Orders auszuführen, ohne auf PDAs zu kollidieren.

pub struct LimitOrderNonce {
    pub user_wallet: Pubkey,
    pub nonce_index: u8,             // user-chosen, 0..255
    pub order_nonce: u64,            // monotonic, incremented every time a new order is opened
    pub padding:     [u64; 4],
}

PDA-Seed: [user_wallet.as_ref(), &[nonce_index]]. Die meisten Clients verwenden nonce_index = 0 und lassen order_nonce die Kardinalität tragen.

​

Permission (veraltet)

Das Permission-Konto wurde im Upgrade vom 2026-10-22 entfernt. Es sperrte früher CreatePermissionedPool, das jetzt die erlaubnisfreie CreateCustomizablePoolV2 ist. Das Programm liest oder schließt diese Konten nicht mehr, und die Anweisungen CreatePermissionPda / ClosePermissionPda sind weg. PDAs, die vor dem Upgrade erstellt wurden (["permission", authority], 280 Bytes), bleiben als inerte Daten in der Chain; ignorieren Sie sie beim Scannen von CLMM-eigenen Konten.

​

Ableitung der Schlüsselkonten

import { PublicKey } from "@solana/web3.js";

const CLMM_PROGRAM_ID = new PublicKey(
  "CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK"
); // see reference/program-addresses

function i32ToBytes(n: number): Buffer {
  const b = Buffer.alloc(4);
  b.writeInt32BE(n);
  return b;
}

export function deriveClmmAccounts(
  ammConfig: PublicKey,
  token0Mint: PublicKey,           // must already be sorted
  token1Mint: PublicKey,
) {
  const [poolState] = PublicKey.findProgramAddressSync(
    [Buffer.from("pool"), ammConfig.toBuffer(),
     token0Mint.toBuffer(), token1Mint.toBuffer()],
    CLMM_PROGRAM_ID,
  );
  // NOTE: pools created via CreateCustomizablePoolV2 append a non-zero u16
  // seed_index (LE) as a 5th seed — see deriveCustomizablePoolV2 below.
  const [observation] = PublicKey.findProgramAddressSync(
    [Buffer.from("observation"), poolState.toBuffer()],
    CLMM_PROGRAM_ID,
  );
  const [tickArrayBitmapExtension] = PublicKey.findProgramAddressSync(
    [Buffer.from("pool_tick_array_bitmap_extension"), poolState.toBuffer()],
    CLMM_PROGRAM_ID,
  );
  return { poolState, observation, tickArrayBitmapExtension };
}

export function deriveTickArray(
  pool: PublicKey,
  startTickIndex: number,
) {
  const [tickArray] = PublicKey.findProgramAddressSync(
    [Buffer.from("tick_array"), pool.toBuffer(), i32ToBytes(startTickIndex)],
    CLMM_PROGRAM_ID,
  );
  return tickArray;
}

export function deriveDynamicFeeConfig(index: number) {
  const idx = Buffer.alloc(2);
  idx.writeUInt16BE(index);
  const [pda] = PublicKey.findProgramAddressSync(
    [Buffer.from("dynamic_fee_config"), idx],
    CLMM_PROGRAM_ID,
  );
  return pda;
}

export function deriveCustomizablePoolV2(
  ammConfig: PublicKey,
  token0Mint: PublicKey,           // must already be sorted
  token1Mint: PublicKey,
  seedIndex: number,               // non-zero u16
) {
  const idx = Buffer.alloc(2);
  idx.writeUInt16LE(seedIndex);    // little-endian, unlike the u16 seeds above
  const [pool] = PublicKey.findProgramAddressSync(
    [Buffer.from("pool"), ammConfig.toBuffer(),
     token0Mint.toBuffer(), token1Mint.toBuffer(), idx],
    CLMM_PROGRAM_ID,
  );
  return pool;
}

export function deriveLimitOrderNonce(
  wallet: PublicKey,
  nonceIndex: number,
) {
  const [pda] = PublicKey.findProgramAddressSync(
    [wallet.toBuffer(), Buffer.from([nonceIndex & 0xff])],
    CLMM_PROGRAM_ID,
  );
  return pda;
}

export function deriveLimitOrder(
  wallet: PublicKey,
  nonceAccount: PublicKey,
  orderNonce: bigint,
) {
  const nonceBytes = Buffer.alloc(8);
  nonceBytes.writeBigUInt64BE(orderNonce);
  const [pda] = PublicKey.findProgramAddressSync(
    [wallet.toBuffer(), nonceAccount.toBuffer(), nonceBytes],
    CLMM_PROGRAM_ID,
  );
  return pda;
}

export function derivePersonalPosition(nftMint: PublicKey) {
  const [personalPosition] = PublicKey.findProgramAddressSync(
    [Buffer.from("position"), nftMint.toBuffer()],
    CLMM_PROGRAM_ID,
  );
  return personalPosition;
}

Die genauen Seed-Strings sollten immer gegen die On-Chain-IDL und reference/program-addresses überprüft werden.

​

Lebenszyklus-Kurzreferenz

Ereignis	Erstellte Konten	Gelöschte Konten
CreatePool	poolState, observation, token_0_vault, token_1_vault	—
OpenPosition[V2] / OpenPositionWithToken22Nft	NFT-Mint + ATA, personalPosition, möglicherweise neue tickArrayState(s), tickArrayBitmapExtension falls noch nicht vorhanden; kann die NFT-ATA für einen Pool mit eingeschränktem Emittenten einfrieren	—
IncreaseLiquidity	Möglicherweise neue tickArrayState(s)	—
DecreaseLiquidity	—	Möglicherweise löscht Tick-Einträge (aber tickArrayState selbst wird nicht geschlossen)
ClosePosition	—	NFT-ATA, personalPosition und Token-2022-NFT-Mint; ein klassischer SPL-NFT-Mint bleibt bei Angebot null. Der eingefrorene Pfad wird zuerst aufgetaut über den Pool, der in verbleibenden Konten übergeben wird.
SwapV2	Möglicherweise neue tickArrayState	—
OpenLimitOrder	limitOrderState, möglicherweise limitOrderNonce (init-if-needed), möglicherweise neue tickArrayState	—
IncreaseLimitOrder	—	—
DecreaseLimitOrder	—	Schließt limitOrderState, wenn Order vollständig verbraucht ist
SettleLimitOrder	—	—
CloseLimitOrder	—	limitOrderState (Miete → owner)
CreateDynamicFeeConfig	dynamicFeeConfig	—
CreateCustomizablePool	poolState, observation, Vaults — wie CreatePool. Erstellt Snapshot von dynamicFeeConfig, wenn enable_dynamic_fee = true.	—
CreateCustomizablePoolV2	poolState (unter einer seed_index-abgeleiteten Adresse), observation, Vaults — wie CreateCustomizablePool. Erlaubnisfrei.	—
CollectRewards	—	—
UpdateRewardInfos	—	—
CloseProtocolPosition (Admin)	—	Vestigiales protocolPositionState (Miete → Admin)

TickArrayState-Konten werden vom Programm niemals geschlossen — sie bleiben für die Lebensdauer des Pools bestehen. Sobald ein Tick-Array initialisiert wurde, bleibt es in der Chain, auch wenn jeder Tick darin zu liquidity_gross == 0 zurückkehrt. Die Wiederverwendung eines bestehenden Tick-Arrays ist kostenlos; nur die erste Position, die ein noch nie initialisiertes Array berührt, zahlt dessen Miete.

​

Was wo zu lesen ist

• Tick-Mathematik und Range-Mechaniken: products/clmm/ticks-and-positions.
• Swap-Ablauf und Fee-Growth-Mathematik: products/clmm/math.
• Anweisungs-Kontolisten: products/clmm/instructions.
• Gebühren und Reward-Abgrenzung: products/clmm/fees.
• Kanonische Programm-IDs und Seeds: reference/program-addresses.

Quellen:

• raydium-io/raydium-clmm — programs/amm/src/states