Comptes CLMM

Chaque compte qu’un pool CLMM touche : PoolState, AmmConfig, TickArrayState, TickArrayBitmapExtension, PersonalPositionState, et Observation.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.

Voir la version anglaise →

Cette page décrit la structure et le rôle de chaque compte. Les seeds sont canoniques et listés dans reference/program-addresses. Un pool CLMM est plus lourd en comptes qu’un pool CPMM car la liquidité est stockée de manière clairsemée sur la plage de ticks ; comprendre cette clairsemé est l’essentiel de cette page.

​

Inventaire des comptes

Un pool CLMM actif est décrit par les familles de comptes suivantes. Tous sont possédés par le programme CLMM sauf les deux mints et leurs vaults.

Compte	Objectif	Nombre par pool
AmmConfig	Palier de frais : taux de frais commerciaux, part du protocole, part du fonds, espacement des ticks par défaut. Partagé entre tous les pools de ce palier.	1 (partagé)
PoolState	sqrt_price_x64 actuel, tick actuel, liquidité totale, croissance des frais globaux, info de récompense, pointeur d’observation.	1
TickArrayState	Un bloc de TICK_ARRAY_SIZE ticks adjacents. Initialisé uniquement à la demande.	0 ≤ N ≤ plage
TickArrayBitmapExtension	Bitmap de débordement suivant quels tick arrays existent au-delà du bitmap inline dans PoolState.	0 ou 1
PersonalPositionState	Un par position LP. Stocke la plage, la liquidité, et la dernière croissance de frais/récompense vue. Autorité = propriétaire du NFT.	1 par position
Mint du NFT de position	Mint avec supply 1, associé à PersonalPositionState. Son compte de token est dégelé par défaut ; une V2 ouverte le gèle uniquement quand un mint sous-jacent correspond au filtre d’émetteur restreint.	1 par position
ObservationState	Buffer circulaire d’observations de prix pour le TWAP.	1
token_0_vault, token_1_vault	Comptes de token contenant les soldes du pool. Possédés par l’autorité du pool.	2
DynamicFeeConfig	Ensemble de paramètres réutilisable pour le mécanisme de frais dynamiques. Les pools créés via create_customizable_pool peuvent s’inscrire. Géré par l’admin.	partagé (par index)
LimitOrderState	Un par ordre limite ouvert. Enregistre le propriétaire, le tick, le côté, le montant total, snapshot de sortie réglée.	1 par ordre
LimitOrderNonce	Compteur par (wallet, nonce_index) qui dérive des PDAs d’ordre uniques.	1 par (wallet, index)

​

PoolState

L’état actif du pool, lu à chaque swap et à chaque changement de position.

// 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],
}

Champs que vous allez réellement utiliser :

• sqrt_price_x64 et tick_current sont l’état des prix du pool. Ils sont mis à jour ensemble à chaque swap. tick_current est le plancher de log_{1.0001}(price).
• liquidity est la liquidité active — la somme des valeurs L pour toutes les positions dont la plage contient tick_current. Elle change chaque fois qu’un swap traverse un tick et chaque fois qu’une position est ouverte/fermée/redimensionnée.
• fee_growth_global_{0,1}_x64 sont les frais cumulatifs gagnés par unité de liquidité sur tout l’historique du pool. Les positions lisent ceci pour calculer ce qui leur est dû.
• tick_spacing est verrouillé sur AmmConfig à l’initialisation et ne change jamais. Il détermine quels indices de tick sont autorisés à être des points d’extrémité de position.
• tick_array_bitmap est un bitmap inline couvrant la plage de ticks couramment utilisée autour du prix spot. Pour les pools dont les positions s’étendent loin, le suivi du débordement vit dans le TickArrayBitmapExtension séparé.
• fee_on est fixé à la création du pool. 0 (FromInput) reproduit le comportement classique d’Uniswap-V3. 1 et 2 acheminent les frais de swap vers un seul côté du carnet — voir products/clmm/fees pour les compromis.
• seed_index est [0, 0] pour chaque pool créé via CreatePool / CreateCustomizablePool (un pool canonique par paire). Une valeur non-zéro signifie que le pool a été créé via CreateCustomizablePoolV2 (nommé CreatePermissionedPool avant 2026-10-22) et l’index fait partie des seeds PDA du pool, permettant à plusieurs pools de coexister pour le même (config, mint0, mint1). Pour re-dériver l’adresse d’un tel pool, vous devez connaître son seed_index.
• dynamic_fee_info porte l’état de volatilité pour la surcharge de frais dynamiques. Quand activé, chaque swap recalcule un dynamic_fee_component en plus de AmmConfig.trade_fee_rate. La structure est documentée sous DynamicFeeInfo ci-dessous ; les pools sans frais dynamiques laissent la structure entière à zéro.

​

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],
}

Depuis la mise à jour 2026-09, CreateAmmConfig écrit le protocol_fee_owner::ID codé en dur du programme dans owner et le fund_fee_owner::ID dans fund_owner. Avant cela, il copiait la clé du signataire admin dans les deux. Les configs existantes conservent ce qu’elles ont été créées ou rotées, donc lisez les deux champs du compte. Les paramètres UpdateAmmConfig 3 / 4 les font toujours tourner. Les adresses sont dans reference/program-addresses.

Un ensemble typique de paliers de frais CLMM publiés (confirmez par rapport à GET https://api-v3.raydium.io/main/clmm-config) :

Index	trade_fee_rate	Espacement des ticks	Utilisation typique
0	100 (0,01%)	1	Paires stables, USDC/USDT
1	500 (0,05%)	10	Blue-chips corrélés
2	2_500 (0,25%)	60	Paires standard
3	10_000 (1,00%)	120	Volatiles ou long-tail

protocol_fee_rate et fund_fee_rate sont des fractions des frais commerciaux ; même convention que CPMM. Voir products/clmm/fees.

​

TickArrayState

CLMM ne stocke pas un enregistrement unique par tick. Cela représenterait des milliards de comptes. À la place, il regroupe TICK_ARRAY_SIZE ticks adjacents initialisés ou non (généralement 60 ou 88 selon la version du programme) dans un TickArrayState créé de manière paresseuse à la première utilisation.

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],
}

Les quatre champs de limite d’ordre sont zéro sur tout tick qui n’a jamais été utilisé pour un ordre limite. Quand des ordres sont ouverts sur un tick, le programme les suit comme une séquence de cohortes :

• order_phase est l’identifiant de la cohorte. Il s’incrémente chaque fois qu’une cohorte passe de « complètement non remplie » à « partiellement remplie ».
• orders_amount est le total du jeton d’entrée de la cohorte actuelle (la plus récente).
• part_filled_orders_remaining suit la cohorte précédente qui est actuellement remplie par les swaps en cours.
• unfilled_ratio_x64 est un multiplicateur Q64.64 porté sur la cohorte : quand un swap remplit X% de la cohorte, le ratio est multiplié par (1 − X). Chaque ordre ouvert stocke son propre snapshot (order_phase, unfilled_ratio_x64) au moment de l’ouverture, donc les mathématiques de règlement se réduisent à comparer les snapshots.

Règles :

• Un tick d’extrémité de position t doit satisfaire t % tick_spacing == 0. Le programme rejette les positions mal espacées.
• Le tableau du tick est situé à floor(t / (TICK_ARRAY_SIZE * tick_spacing)) * (TICK_ARRAY_SIZE * tick_spacing).
• Un tableau de ticks est initialisé de manière paresseuse : la première position ou le premier swap qui touche un tableau non initialisé le crée, en payant le loyer.
• Un tableau de ticks n’est jamais fermé par le programme. Une fois alloué, il persiste pour la durée de vie du pool, même après que chaque tick à l’intérieur revienne à liquidity_gross == 0. Les positions et swaps ultérieurs réutilisent le compte existant sans loyer supplémentaire. Il n’existe pas de chemin de nettoyage piloté par ClosePosition pour les tableaux de ticks.

​

TickArrayBitmapExtension

PoolState.tick_array_bitmap (en ligne) couvre la plage « proche du spot » — ±512 tableaux de ticks (TICK_ARRAY_BITMAP_SIZE = 512 ; le champ [u64; 16] est 1 024 bits divisés équitablement entre les indices de départ négatifs et positifs, donc les indices de tableau −512 … +511). En dehors de cette plage (pour les valeurs de tick extrêmes), le programme maintient un compte d’extension :

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

Si la plage de votre position est « normale », vous ne pensez jamais au compte d’extension. Les positions de plage complète (par exemple, (MIN_TICK, MAX_TICK)) le nécessitent ; le SDK le résout pour vous.

​

Positions

Une position CLMM est un ensemble de trois comptes plus un mint :

​

Position NFT mint

Un mint SPL Token ou Token-2022 avec une offre de 1. Le NFT de position dans le portefeuille du propriétaire est un ATA contenant ce jeton unique. Le programme lie l’autorisation au détenteur actuel du solde ATA du NFT, et non à une Pubkey stockée dans l’état.

Les nouveaux mints NFT de position définissent pool_state comme leur autorité de gel avant de frapper le jeton unique et de supprimer l’autorité de mint. Définir une autorité de gel ne gèle pas en soi le compte NFT. Le compte reste dégelé et transférable sauf si les deux conditions sont remplies : l’appelant utilise OpenPositionV2 ou OpenPositionWithToken22Nft, et au moins l’autorité de gel d’un mint de coffre-fort sous-jacent apparaît sur la liste des émetteurs restreints de CLMM. Ce n’est que dans ce cas que CLMM gèle le compte NFT après la frappe. Cela ne change aucun octet de PersonalPositionState ou PoolState.

​

PersonalPositionState

Un par position ouverte. Clé basée sur le mint NFT.

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 (obsolète)

Les versions plus anciennes de CLMM stockaient la comptabilité agrégée par (pool, tick_lower, tick_upper) dans un PDA ProtocolPositionState. Les versions plus récentes ne créent ni ne lisent plus ce compte. L’emplacement apparaît toujours sur les listes de comptes OpenPosition / IncreaseLiquidity / DecreaseLiquidity comme un UncheckedAccount pour la compatibilité ABI, mais le programme n’y écrit pas. Les comptes existants en chaîne sont vestigiaux ; l’administrateur peut appeler CloseProtocolPosition pour récupérer le loyer pour eux.

La comptabilité de plage agrégée est maintenant dérivée directement des deux ticks d’extrémité (liquidity_gross, liquidity_net, et les fee_growth_outside_* / reward_growths_outside_x64 par tick) dans TickArrayState. La formule de croissance des frais fee_growth_inside = global − outside_lower − outside_upper continue de fonctionner sans un compte de position agrégée.

​

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],
}

Le tampon d’observation de CLMM stocke un tick cumulatif, pas un prix cumulatif. Les consommateurs externes calculent le prix de la moyenne géométrique sur un intervalle à partir de (tick_cumulative[t1] − tick_cumulative[t0]) / (t1 − t0) puis price = 1.0001 ** tick. Voir algorithms/clmm-math.

​

DynamicFeeConfig et DynamicFeeInfo

Les paramètres de frais dynamiques vivent à deux endroits. Le modèle réutilisable — DynamicFeeConfig — est géré par l’administrateur et partagé entre les pools qui l’acceptent. L’état d’exécution par pool — DynamicFeeInfo — est intégré dans PoolState et mis à jour par chaque swap.

​

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],
}

Graine PDA : ["dynamic_fee_config", index.to_be_bytes()]. Créé via create_dynamic_fee_config (protégé par l’administrateur) et modifié via update_dynamic_fee_config. Un pool créé avec enable_dynamic_fee = true capture les cinq paramètres d’étalonnage de la configuration (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator) dans son propre DynamicFeeInfo au moment de la création ; les modifications ultérieures à DynamicFeeConfig n’affectent pas rétroactivement les pools existants.

​

DynamicFeeInfo (intégré dans 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],
}

Les quatre champs du bas sont l’état ; les cinq du haut sont l’étalonnage copié de DynamicFeeConfig. Les mathématiques des frais et les règles de décroissance sont documentées sous products/clmm/math et products/clmm/fees.

Constantes utilisées par la formule :

Constante	Valeur	Signification
VOLATILITY_ACCUMULATOR_SCALE	10_000	Granularité de l’accumulateur de volatilité
REDUCTION_FACTOR_DENOMINATOR	10_000	Dénominateur pour reduction_factor
DYNAMIC_FEE_CONTROL_DENOMINATOR	100_000	Dénominateur pour dynamic_fee_control
MAX_FEE_RATE_NUMERATOR	100_000	Plafond dur de 10% sur le taux de frais résultant

​

LimitOrderState

Un compte par ordre limite ouvert.

// 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],
}

Cycle de vie :

1. Ouverture — l’utilisateur appelle open_limit_order, dépose total_amount du jeton d’entrée, l’ordre est lié à une cohorte TickState.
2. (optionnel) Augmentation / Diminution — increase_limit_order ajoute à total_amount ; decrease_limit_order retourne les jetons non remplis (et tout résultat réglé jusqu’à ce point).
3. Règlement — quand la cohorte est complètement ou partiellement remplie, le propriétaire ou le gardien opérationnel appelle settle_limit_order pour pousser les jetons de sortie vers l’ATA du propriétaire.
4. Fermeture — une fois que unfilled_amount == 0, le compte est fermable. Le loyer retourne toujours à owner.

Graine PDA : [owner.as_ref(), limit_order_nonce.key().as_ref(), limit_order_nonce.order_nonce.to_be_bytes().as_ref()]. Le PDA de l’ordre est donc unique par (owner, nonce_index, order_nonce).

​

LimitOrderNonce

Compteur par (wallet, nonce_index) qui permet à un utilisateur unique d’exécuter plusieurs pipelines parallèles d’ordres limités sans collision sur les PDAs.

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],
}

Seed PDA : [user_wallet.as_ref(), &[nonce_index]]. La plupart des clients utilisent nonce_index = 0 et laissent order_nonce porter la cardinalité.

​

Permission (retiré)

Le compte Permission a été supprimé lors de la mise à jour du 2026-10-22. Il servait autrefois à contrôler CreatePermissionedPool, qui est maintenant le CreateCustomizablePoolV2 sans permission. Le programme ne lit ni ne ferme plus ces comptes, et les instructions CreatePermissionPda / ClosePermissionPda ont disparu. Les PDAs créés avant la mise à jour (["permission", authority], 280 octets) restent sur la chaîne en tant que données inactives ; ignorez-les lors du balayage des comptes appartenant à CLMM.

​

Dérivation des comptes clés

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;
}

Les chaînes de seed exactes doivent toujours être vérifiées par rapport à l’IDL on-chain et à reference/program-addresses.

​

Référence rapide du cycle de vie

Événement	Comptes créés	Comptes détruits
CreatePool	poolState, observation, token_0_vault, token_1_vault	—
OpenPosition[V2] / OpenPositionWithToken22Nft	NFT mint + ATA, personalPosition, possiblement nouveau(x) tickArrayState, tickArrayBitmapExtension s’il n’existe pas encore ; peut geler l’ATA du NFT pour un pool à émetteur restreint	—
IncreaseLiquidity	Possiblement nouveau(x) tickArrayState	—
DecreaseLiquidity	—	Possiblement efface les entrées de tick (mais le tickArrayState lui-même n’est pas fermé)
ClosePosition	—	NFT ATA, personalPosition, et Token-2022 NFT mint ; un mint NFT SPL classique reste à zéro d’approvisionnement. Le chemin gelé est d’abord dégelé via le pool passé dans les comptes restants.
SwapV2	Possiblement nouveau tickArrayState	—
OpenLimitOrder	limitOrderState, possiblement limitOrderNonce (init-if-needed), possiblement nouveau tickArrayState	—
IncreaseLimitOrder	—	—
DecreaseLimitOrder	—	Ferme limitOrderState si la commande est entièrement consommée
SettleLimitOrder	—	—
CloseLimitOrder	—	limitOrderState (loyer → owner)
CreateDynamicFeeConfig	dynamicFeeConfig	—
CreateCustomizablePool	poolState, observation, vaults — identique à CreatePool. Capture dynamicFeeConfig si enable_dynamic_fee = true.	—
CreateCustomizablePoolV2	poolState (à une adresse dérivée de seed_index), observation, vaults — comme CreateCustomizablePool. Sans permission.	—
CollectRewards	—	—
UpdateRewardInfos	—	—
CloseProtocolPosition (admin)	—	protocolPositionState vestigial (loyer → admin)

Les comptes TickArrayState ne sont jamais fermés par le programme — ils persistent pendant toute la durée de vie du pool. Une fois qu’un tableau de tick a été initialisé, il reste sur la chaîne même si chaque tick à l’intérieur revient à liquidity_gross == 0. La réutilisation d’un tableau de tick existant est gratuite ; seule la première position qui touche un tableau jamais initialisé paie son loyer.

​

Où lire quoi

• Mathématiques des ticks et mécanique des plages : products/clmm/ticks-and-positions.
• Parcours de swap et mathématiques de croissance des frais : products/clmm/math.
• Listes de comptes d’instruction : products/clmm/instructions.
• Frais et accumulation de récompenses : products/clmm/fees.
• IDs de programme canoniques et seeds : reference/program-addresses.

Sources :

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