Instrucciones CLMM

​

Inventario de instrucciones

​

CreatePool

sqrt_price_x64: u128           // precio inicial
open_time:      u64            // swaps rechazados antes de este tiempo

• token_mint_0 < token_mint_1 por orden de bytes.
• amm_config.disable_create_pool == false.
• Los mints no son rechazados por la lista blanca de extensión Token-2022.

• pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
• pool_state.liquidity = 0 (sin posiciones aún).
• pool_state.fee_on = FromInput (predeterminado heredado).
• pool_state.dynamic_fee_info está en cero (comisión dinámica deshabilitada).

​

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 establecido a la variante CollectFeeOn elegida.
• Si la comisión dinámica fue habilitada: pool_state.dynamic_fee_info se inicializa desde el DynamicFeeConfig suministrado (cinco parámetros de calibración copiados; campos de estado en cero).
• De lo contrario: pool_state.dynamic_fee_info está en cero (= comisión dinámica inactiva para siempre en este pool).

​

CreatePermissionedPool

customizable_params: CreateCustomizableParams   // mismo struct que CreateCustomizablePool
seed_index:          u16                          // debe ser distinto de cero; plegado en las semillas del PDA del pool

• seed_index != 0. Un seed_index de 0 está reservado para pools heredados y se rechaza aquí; el componente de semilla [0, 0] es lo que hace que una dirección de pool heredada se colapse a la forma clásica de cuatro semillas.
• El PDA permission para payer existe (creado por un administrador a través de CreatePermissionPda).
• Mismas reglas de mint/lista blanca que CreatePool.

• Un nuevo pool_state existe en la dirección derivada de seed_index, con pool_state.seed_index = seed_index.
• Todo otro estado posterior coincide con CreateCustomizablePool (modo de comisión, comisión dinámica opcional).

​

OpenPositionV2 / OpenPositionWithToken22Nft

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // L deseada (o 0 para usar montos abajo)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // escribe metadatos del NFT (Metaplex)
base_flag: Option<bool>       // true = ajusta a amount0; false = ajusta a amount1

• tick_lower < tick_upper, ambos múltiplos de pool.tick_spacing, dentro de [MIN_TICK, MAX_TICK].
• Matrices de tick requeridas pasadas e inicializadas (o creadas aquí a través de CPI InitTickArray en la transacción).
• El usuario tiene al menos amount_0_max y amount_1_max en las ATAs de fuente.

• personal_position existe, liquidity establecida, fee_growth_inside_last capturada.
• Entradas de matriz de tick en tick_lower y tick_upper actualizadas (liquidity_gross += L, liquidity_net ± L, instantáneas de crecimiento de comisión mantenidas).
• pool_state.liquidity += L si la posición está en rango (tick_lower ≤ tick_current < tick_upper).
• El mint del NFT de posición registra pool_state como autoridad de congelación. La autoridad de acuñación se elimina después de que se acuña el único NFT. Registrar la autoridad de congelación no cambia el estado de la cuenta de token del NFT.
• La cuenta de token del NFT permanece descongelada a menos que la instrucción sea OpenPositionV2 u OpenPositionWithToken22Nft y la autoridad de congelación de cualquier mint de bóveda coincida con la lista de emisores restringidos de CLMM. Solo esa ruta V2 coincidente congela la cuenta. OpenPosition V1 no congela.

​

IncreaseLiquidityV2

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

• Transfiere amount_0_actual / amount_1_actual del usuario → bóvedas.
• Incrementa personal_position.liquidity y pool_state.liquidity (si está en rango), y el liquidity_gross / liquidity_net del tick de punto final en consecuencia.
• Recopila comisiones y recompensas adeudadas desde el último toque y las acredita a tokens_fees_owed_{0,1} / reward_amount_owed. Esos se pagan solo en DecreaseLiquidity o CollectReward, no en aumento.

​

DecreaseLiquidityV2

liquidity: u128
amount_0_min: u64
amount_1_min: u64

• Calcula (amount_0, amount_1) para la L eliminada dado el sqrt_price_x64 actual.
• Liquida comisiones/recompensas acumuladas desde el último toque, igual que IncreaseLiquidity.
• Transfiere amount_0 + fees_owed_0 y amount_1 + fees_owed_1 fuera de las bóvedas al usuario.
• Decrementa contadores de liquidez; si el nuevo personal_position.liquidity == 0, la posición es elegible para ClosePosition.

​

ClosePosition

• NFT descongelado: ninguno requerido; una cuenta de pool adicional es inofensiva porque el controlador no la lee.
• NFT congelado: añade personal_position.pool_id como la primera cuenta restante. El programa la carga como PoolState y usa sus semillas de PDA para firmar el descongelamiento.

• personal_position.liquidity == 0.
• tokens_fees_owed_{0,1} == 0.
• Todos los contadores de recompensas reward_amount_owed == 0.

• Si la cuenta de token del NFT está congelada, verifica que la primera cuenta restante sea igual a personal_position.pool_id, luego la descongela con el PDA del pool.
• Quema el NFT.
• Cierra la cuenta de token del NFT y personal_position, reembolsando alquiler a nft_owner. Si el NFT de posición usa Token-2022, también cierra el mint del NFT; los mints de Token SPL clásico no pueden cerrarse y permanecen con suministro cero.

​

SwapV2

amount: u64                  // entrada si is_base_input=true, salida de lo contrario
other_amount_threshold: u64  // mín. salida o máx. entrada
sqrt_price_limit_x64: u128   // límite duro; 0 ⇒ sin límite
is_base_input: bool

• pool_state.status permite swap.
• now >= open_time.
• sqrt_price_limit_x64 está en el lado correcto de sqrt_price_x64 para la dirección.

1. Recargo de comisión dinámica — si pool.dynamic_fee_info es distinto de cero, el programa actualiza el acumulador de volatilidad usando la distancia de tick recorrida desde el último swap (con las reglas de filtro/decaimiento de products/clmm/fees) y añade un dynamic_fee_component encima de AmmConfig.trade_fee_rate. La comisión total está limitada al 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000).
2. Coincidencia de órdenes limitadas — cuando el recorrido de precio cruza un tick que contiene órdenes limitadas abiertas, el programa primero completa la liquidez de orden limitada disponible en ese tick (FIFO por order_phase), luego procede a lo largo de la curva de liquidez de LP. Los montos completados actualizan tick.unfilled_ratio_x64 y tick.part_filled_orders_remaining para liquidación posterior; las órdenes en sí permanecen sin gastar hasta que su propietario llama a SettleLimitOrder.
3. Enrutamiento de comisión de un lado — cuando pool.fee_on = Token0Only o Token1Only, el paso de swap aún calcula el mismo comercio entrada-salida; la comisión se enruta entonces al lado configurado. Para direcciones donde el lado de comisión configurado es la salida, la comisión se deduce de la salida del swap (el usuario recibe out − fee); para direcciones donde es la entrada, el comportamiento coincide con FromInput. Ver is_fee_on_input(zero_for_one) e is_fee_on_token0(zero_for_one) en PoolState.

​

OpenLimitOrder

nonce_index:    u8       // índice de cuenta nonce elegido por el usuario (0..255 por billetera)
zero_for_one:   bool     // true: vende token0 por token1; false: vende token1 por token0
tick_index:     i32      // debe ser múltiplo de pool.tick_spacing
amount:         u64      // monto de token de entrada

• Ni input_token_account ni output_token_account están congeladas (de lo contrario NotApproved).
• pool_state.status permite tanto la operación de swap (bit 4) como la de orden limitada (bit 5) (de lo contrario NotApproved).
• tick_index % pool.tick_spacing == 0 y dentro de [MIN_TICK, MAX_TICK].
• tick_index está en el lado correcto de pool.tick_current para la dirección elegida (vender token0 → tick debe estar arriba del actual, y viceversa). Vender en un tick ya cruzado sería coincidido inmediatamente y se rechaza.

• limit_order existe, capturando tick.order_phase y tick.unfilled_ratio_x64 en el momento de apertura.
• tick.orders_amount += amount (en la cohorte actual).
• limit_order_nonce.order_nonce += 1.
• OpenLimitOrderEvent emitido.

​

IncreaseLimitOrder

amount: u64    // monto de token de entrada adicional

• limit_order.owner == signer.
• La orden aún está en la misma cohorte (tick.order_phase == limit_order.order_phase). Si la cohorte ya ha comenzado a completarse, la orden está parcialmente liquidada — el llamador debe llamar a DecreaseLimitOrder o SettleLimitOrder primero para avanzar.

• Transfiere amount de la ATA del propietario a input_vault.
• limit_order.total_amount += amount; tick.orders_amount += amount.

​

DecreaseLimitOrder

amount:     u64    // monto de token de entrada a retirar (máx. = resto no completado)
amount_min: u64    // piso de deslizamiento en el retiro del lado de entrada

• Recalcula el monto completado de la orden desde el unfilled_ratio_x64 de la cohorte desde la apertura.
• Envía salida completada a output_token_account.
• Envía amount de entrada no completada de vuelta a input_token_account.
• Actualiza limit_order en consecuencia. Si el nuevo resto no completado es cero, el programa cierra la cuenta y reembolsa alquiler a owner.

​

SettleLimitOrder

• Calcula la salida acumulada adeudada usando (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64).
• Transfiere el delta a output_token_account.
• Actualiza limit_order.settled_output.
• No cierra la orden; aún está abierta contra cualquier entrada restante.

​

CloseLimitOrder

• La orden tiene cero resto no completado (ya sea amount == total_amount fue completado y liquidado, o el propietario disminuyó previamente la orden a cero y olvidó cerrar).

• Cierra limit_order; el alquiler se envía a limit_order.owner.

​

CreateDynamicFeeConfig (admin)

index:                       u16
filter_period:               u16   // segundos; p. ej. 30
decay_period:                u16   // segundos; p. ej. 600. Debe ser > filter_period
reduction_factor:            u16   // 1..10_000; p. ej. 5_000 = 50% retención por ventana de decaimiento
dynamic_fee_control:         u32   // 1..100_000; ganancia en la curva volatilidad-a-comisión
max_volatility_accumulator:  u32   // techo

​

UpdateDynamicFeeConfig (admin)

​

CollectProtocolFee / CollectFundFee

​

InitializeReward

open_time:     u64
end_time:      u64
emissions_per_second_x64: u128   // Q64.64

• Menos de 3 flujos actualmente activos en el pool.
• El financiador deposita total_emission = emissions_per_second × (end_time − open_time) de token de recompensa en la bóveda como parte de esta instrucción.
• Mint de recompensa en la lista blanca por operation_state.

​

SetRewardParams

​

UpdateRewardInfos

​

CollectReward

• Liquida crecimiento de recompensas (mismo patrón que comisiones).
• Transfiere el monto adeudado a la ATA del destinatario, pone a cero reward_amount_owed[i].

​

Matriz de cambio de estado

​

Dónde ir a continuación

• products/clmm/code-demos — muestras de TypeScript ejecutables.
• products/clmm/fees — detalles sobre acumulación de comisiones y recompensas.
• reference/error-codes — tabla completa de errores de Anchor de CLMM.

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