> ## Documentation Index > Fetch the complete documentation index at: https://docs.raydium.io/llms.txt > Use this file to discover all available pages before exploring further. # Instrucciones CLMM > Referencia completa de instrucciones CLMM: ciclo de vida del pool, gestión de posiciones, swap y flujos de recompensas. **Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.** [Ver versión en inglés →](/products/clmm/instructions) Esta página complementa [`products/clmm/accounts`](/es/products/clmm/accounts) (descripción de las cuentas) y [`products/clmm/math`](/es/products/clmm/math) (explicación de la matemática). Es la referencia definitiva para argumentos y orden de cuentas; los layouts de bytes provienen del IDL. ## Inventario de instrucciones | Grupo | Instrucción | Notas | | ----------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Admin | `CreateAmmConfig` | Define un nuevo nivel de comisión. | | Admin | `UpdateAmmConfig` | Modifica las tasas en un nivel existente. | | Admin | `UpdatePoolStatus` | Pausa/reanuda las operaciones de un pool. | | Admin | `CreateSupportMintAssociated` | Agrega a la lista de permitidos una configuración de extensión de mint Token-2022 para su uso en pools CLMM. | | Admin | `CreateOperationAccount` | Inicializa la cuenta de operaciones del programa (operación única). | | Admin | `UpdateOperationAccount` | Modifica la lista blanca de la cuenta de operaciones. | | Admin | `CreateDynamicFeeConfig` | Crea un conjunto de parámetros de comisión dinámica reutilizable bajo un índice u16. | | Admin | `UpdateDynamicFeeConfig` | Modifica un `DynamicFeeConfig` existente. Los pools que ya tomaron una instantánea de él no se ven afectados. | | Pool | `CreatePool` | Inicializa un pool CLMM vinculado a un `AmmConfig`. Ruta de comisión estándar FromInput. Coexiste con `CreateCustomizablePool`. | | Pool | `CreateCustomizablePool` | Recomendado para nuevos pools. Tiene la misma forma que `CreatePool` más `collect_fee_on` y una bandera `enable_dynamic_fee` opcional. | | Position | `OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft` | Acuña un NFT de posición. `OpenPositionV2` reemplaza a V1 (layout de cuentas más nuevo con la ranura de extensión bitmap); `OpenPositionWithToken22Nft` emite el NFT de posición como Token-2022 en lugar de SPL Token. El código nuevo debería usar V2 o la variante Token-2022. | | Position | `IncreaseLiquidity` / `IncreaseLiquidityV2` | Agrega liquidez a una posición existente. | | Position | `DecreaseLiquidity` / `DecreaseLiquidityV2` | Retira liquidez; cobra las comisiones pendientes. | | Position | `ClosePosition` | Quema el NFT y cierra el `PersonalPositionState`. | | Position | `CloseProtocolPosition` | Solo para admins: limpieza de PDAs `ProtocolPositionState` heredadas. El programa actual ya no crea ni lee `ProtocolPositionState`; esta instrucción existe únicamente para recuperar el alquiler de cuentas creadas por versiones antiguas del programa. | | Swap | `Swap` / `SwapV2` | Swap de liquidez constante. Ambas variantes aplican comisión dinámica, enrutamiento de comisión unilateral y coincidencia de órdenes límite; la única diferencia es que `SwapV2` acepta mints Token-2022 (la variante V1 requiere que ambos vaults sean SPL Token clásico). | | Swap | `SwapRouterBaseIn` | Multi-hop, utilizado por el router. | | Limit order | `OpenLimitOrder` | Coloca una orden de venta en un tick. Los tokens sin ejecutar quedan en el tick; el motor de coincidencia los llena a medida que el precio lo atraviesa. | | Limit order | `IncreaseLimitOrder` | Agrega monto a una orden abierta existente. | | Limit order | `DecreaseLimitOrder` | Reduce o cancela una orden abierta; devuelve el remanente sin ejecutar más cualquier output ya liquidado. | | Limit order | `SettleLimitOrder` | Envía los tokens de output ejecutados al dueño de la orden. Puede ser llamado por el dueño o por el keeper operacional. | | Limit order | `CloseLimitOrder` | Cierra una cuenta de orden completamente consumida. El alquiler siempre regresa al `owner` de la orden. Puede ser llamado por el dueño o el keeper. | | Fees | `CollectProtocolFee` | Barrido de comisiones de protocolo por parte del admin. | | Fees | `CollectFundFee` | Barrido de comisiones de fondo por parte del admin. | | Rewards | `InitializeReward` | Adjunta un nuevo flujo de recompensas a un pool. | | Rewards | `SetRewardParams` | Cambia la tasa de emisión o el final de una recompensa existente. | | Rewards | `UpdateRewardInfos` | Liquida el crecimiento de recompensas hasta ahora (llamado por cualquier swap o cambio de posición). | | Rewards | `TransferRewardOwner` | Transfiere la autoridad que puede configurar o recargar un flujo de recompensas. | | Rewards | `CollectRemainingRewards` | Tras el `end_time` de un flujo de recompensas, recupera los tokens no asignados para el financiador. | | Utility | `InitTickArray` | Inicializa una cuenta de tick array (frecuentemente agrupada con `OpenPosition`). | La mayoría de las instrucciones solo para admins (`CreateAmmConfig`, `UpdateAmmConfig`, `UpdatePoolStatus`, `CreateSupportMintAssociated`, `CreateOperationAccount`, `UpdateOperationAccount`, `CloseProtocolPosition`) están protegidas por la clave pública `admin` codificada en el programa. Las instrucciones de admin de flujos de recompensas (`TransferRewardOwner`, `CollectRemainingRewards`) están protegidas por el financiador de la recompensa, no por el admin del programa. El sufijo V2 significa "admite Token-2022 en vaults / NFT, requiere la ranura de extensión bitmap". El SDK usa V2 por defecto para nuevos pools. ## `CreatePool` **Argumentos** ``` sqrt_price_x64: u128 // precio inicial open_time: u64 // los swaps se rechazan antes de este tiempo ``` **Cuentas (resumen)** | # | Nombre | W | S | Notas | | -- | ----------------------------- | - | - | ------------------------------------------------------- | | 1 | `pool_creator` | W | S | | | 2 | `amm_config` | | | Nivel de comisión elegido. | | 3 | `pool_state` | W | | `init` aquí. | | 4 | `token_mint_0` | | | Ordenado. | | 5 | `token_mint_1` | | | | | 6 | `token_vault_0` | W | | `init` aquí, propiedad de la PDA de autoridad del pool. | | 7 | `token_vault_1` | W | | | | 8 | `observation_state` | W | | `init` aquí. | | 9 | `tick_array_bitmap_extension` | W | | `init` aquí (V2). | | 10 | `token_program` | | | | | 11 | `token_program_2022` | | | | | 12 | `system_program`, `rent` | | | | **Precondiciones** * `token_mint_0 < token_mint_1` por orden de bytes. * `amm_config.disable_create_pool == false`. * Los mints no están rechazados por la lista de permitidos de extensiones Token-2022. **Postcondiciones** * `pool_state.sqrt_price_x64 = sqrt_price_x64`, `tick_current = floor(log_{1.0001}(price))`. * `pool_state.liquidity = 0` (sin posiciones todavía). * `pool_state.fee_on = FromInput` (valor predeterminado heredado). * `pool_state.dynamic_fee_info` se inicializa en cero (comisión dinámica desactivada). ## `CreateCustomizablePool` Recomendado para nuevos pools. Tiene el mismo efecto que `CreatePool` más el modo de cobro de comisiones por pool y una activación opcional de comisión dinámica. **Argumentos** ```rust theme={null} pub struct CreateCustomizableParams { pub sqrt_price_x64: u128, pub collect_fee_on: CollectFeeOn, // FromInput | Token0Only | Token1Only pub enable_dynamic_fee: bool, } ``` **Cuentas (resumen)** — iguales a `CreatePool` más, cuando `enable_dynamic_fee = true`: | # | Nombre | W | S | Notas | | - | -------------------- | - | - | --------------------------------------------------------------------------------------- | | N | `dynamic_fee_config` | | | La configuración compartida de la que se toma la instantánea. Debe existir previamente. | **Precondiciones** — iguales a `CreatePool`. Si `enable_dynamic_fee = false`, `dynamic_fee_config` se ignora. **Postcondiciones** * `pool_state.fee_on` se establece según la variante `CollectFeeOn` elegida. * Si se activó la comisión dinámica: `pool_state.dynamic_fee_info` se inicializa desde el `DynamicFeeConfig` proporcionado (se copian los cinco parámetros de calibración; los campos de estado se ponen a cero). * De lo contrario: `pool_state.dynamic_fee_info` se pone a cero (= comisión dinámica inactiva permanentemente para este pool). `fee_on` y el bit de activación de comisión dinámica se establecen **únicamente** en la creación del pool. No existe una actualización en el lugar: los pools creados con el `CreatePool` heredado no pueden obtener retroactivamente comisión dinámica ni comisión unilateral. Los nuevos despliegues deben usar esta instrucción por defecto. ## `OpenPositionV2` / `OpenPositionWithToken22Nft` Crea una nueva posición dentro de un pool existente. **Argumentos** ``` tick_lower_index: i32 tick_upper_index: i32 tick_array_lower_start_index: i32 tick_array_upper_start_index: i32 liquidity: u128 // L deseado (o 0 para usar los amounts siguientes) amount_0_max: u64 amount_1_max: u64 with_metadata: bool // escribir metadatos del NFT (Metaplex) base_flag: Option // true = ajustar a amount0; false = ajustar a amount1 ``` **Cuentas (resumen)** | # | Nombre | W | S | | | -- | ----------------------------------------- | - | ----------- | ---------------------------------------- | | 1 | `payer` | W | S | | | 2 | `position_nft_owner` | | | | | 3 | `position_nft_mint` | W | S (keypair) | | | 4 | `position_nft_account` | W | | ATA del dueño para el NFT. | | 5 | `metadata_account` | W | | Metaplex (opcional, si `with_metadata`). | | 6 | `pool_state` | W | | | | 7 | `protocol_position` | | | | | 8 | `tick_array_lower` | W | | Se crea si no está inicializado. | | 9 | `tick_array_upper` | W | | Igual. | | 10 | `personal_position` | W | | Se crea aquí. | | 11 | `token_account_0`, `token_account_1` | W | | ATAs de origen del usuario. | | 12 | `token_vault_0`, `token_vault_1` | W | | | | 13 | `rent`, `system_program`, `token_program` | | | | | 14 | `associated_token_program` | | | | | 15 | `metadata_program` | | | Opcional. | | 16 | `token_program_2022` | | | V2. | | 17 | `vault_0_mint`, `vault_1_mint` | | | V2. | | 18 | `tick_array_bitmap_extension` | W | | V2 (si se toca). | **Matemática** — ver [`products/clmm/math`](/es/products/clmm/math). Dado `base_flag`, el programa resuelve `liquidity` o `(amount_0_max, amount_1_max)` para obtener el `L` real y los amounts de tokens consumidos. **Precondiciones** * `tick_lower < tick_upper`, ambos múltiplos de `pool.tick_spacing`, dentro de `[MIN_TICK, MAX_TICK]`. * Los tick arrays requeridos se pasan y están inicializados (o se crean aquí vía CPI `InitTickArray` en la transacción). * El usuario tiene al menos `amount_0_max` y `amount_1_max` en las ATAs de origen. **Postcondiciones** * `personal_position` existe, `liquidity` establecido, `fee_growth_inside_last` registrado como instantánea. * Las entradas del tick array en `tick_lower` y `tick_upper` se actualizan (`liquidity_gross += L`, `liquidity_net ± L`, instantáneas de crecimiento de comisiones mantenidas). * `pool_state.liquidity += L` si la posición está en rango (`tick_lower ≤ tick_current < tick_upper`). **Errores comunes** — `InvalidTickIndex`, `NotApproved`, `ZeroAmountSpecified`, `TransactionTooLarge` (si hay demasiados tick arrays). ## `IncreaseLiquidityV2` Agrega liquidez a una posición ya abierta. **Argumentos** ``` liquidity: u128 amount_0_max: u64 amount_1_max: u64 base_flag: Option ``` **Cuentas** — igual que `OpenPosition` sin el mint del NFT (la posición ya existe; el NFT se pasa como la ATA del dueño que contiene 1 token). **Efecto** * Transfiere `amount_0_actual` / `amount_1_actual` del usuario a los vaults. * Incrementa `personal_position.liquidity` y `pool_state.liquidity` (si está en rango), así como `liquidity_gross` / `liquidity_net` de los ticks extremos. * **Cobra las comisiones y recompensas pendientes desde el último toque** y las acredita en `tokens_fees_owed_{0,1}` / `reward_amount_owed`. Estos montos solo se pagan en `DecreaseLiquidity` o `CollectReward`, no al incrementar. ## `DecreaseLiquidityV2` Retira liquidez de una posición. **Argumentos** ``` liquidity: u128 amount_0_min: u64 amount_1_min: u64 ``` **Cuentas** — misma forma que `IncreaseLiquidity`. **Efecto** * Calcula `(amount_0, amount_1)` para el `L` retirado dado el `sqrt_price_x64` actual. * Liquida las comisiones y recompensas acumuladas desde el último toque, igual que `IncreaseLiquidity`. * Transfiere `amount_0 + fees_owed_0` y `amount_1 + fees_owed_1` de los vaults al usuario. * Decrementa los contadores de liquidez; si el nuevo `personal_position.liquidity == 0`, la posición es elegible para `ClosePosition`. **Slippage** — `amount_0_min` y `amount_1_min` son los mínimos que el usuario acepta neto de las comisiones de transferencia Token-2022 en el lado de salida. ## `ClosePosition` Quema el NFT de posición y cierra `PersonalPositionState`. **Precondiciones** * `personal_position.liquidity == 0`. * `tokens_fees_owed_{0,1} == 0`. * Todos los contadores de recompensas `reward_amount_owed == 0`. (Es decir, primero cobra todo y reduce a cero.) **Efecto** * Quema el NFT. * Cierra la cuenta del mint del NFT y la cuenta `personal_position`, devolviendo el alquiler al `payer`. ## `SwapV2` Recorre la curva de liquidez; entrada exacta *o* salida exacta según `is_base_input`. **Argumentos** ``` amount: u64 // entrada si is_base_input=true, salida en caso contrario other_amount_threshold: u64 // mínimo de salida o máximo de entrada sqrt_price_limit_x64: u128 // límite estricto; 0 ⇒ sin límite is_base_input: bool ``` **Cuentas (resumen)** | # | Nombre | W | S | Notas | | --- | ---------------------------------------- | - | - | --------------------------------------------------------------- | | 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 (requerido para algunas rutas Token-2022). | | 12 | `input_vault_mint`, `output_vault_mint` | | | V2. | | 13 | `tick_array_bitmap_extension` (opcional) | W | | Si el swap entra en la extensión. | | 14+ | `tick_array` (restantes) | W | | Suficientes arrays para cubrir el rango esperado del recorrido. | Los callers pasan una lista ordenada de tick arrays que cubren el recorrido esperado del swap; el programa usa los que necesite. El SDK calcula esta lista mediante `PoolUtils.computeAmountOutFormat` o el endpoint de cotización de la API. **Precondiciones** * `pool_state.status` permite el swap. * `now >= open_time`. * `sqrt_price_limit_x64` está en el lado correcto de `sqrt_price_x64` según la dirección. **Errores comunes** — `ExceededSlippage`, `SqrtPriceLimitOverflow`, `TickArrayNotFound`, `LiquidityInsufficient`. **Lo que `SwapV2` hace internamente y que los callers deben saber** (versión post-2025): 1. **Recargo por comisión dinámica** — si `pool.dynamic_fee_info` es distinto de cero, el programa actualiza el acumulador de volatilidad usando la distancia en ticks recorrida desde el último swap (con las reglas de filtrado/decaimiento de [`products/clmm/fees`](/es/products/clmm/fees)) y suma un `dynamic_fee_component` sobre `AmmConfig.trade_fee_rate`. La comisión total está limitada al 10% (`MAX_FEE_RATE_NUMERATOR / 1_000_000`). 2. **Coincidencia de órdenes límite** — cuando el recorrido de precio cruza un tick que tiene órdenes límite abiertas, el programa primero completa la liquidez de las órdenes límite disponibles en ese tick (FIFO por `order_phase`) y luego continúa por la curva de liquidez LP. Los amounts ejecutados actualizan `tick.unfilled_ratio_x64` y `tick.part_filled_orders_remaining` para liquidación posterior; las órdenes permanecen sin pagar hasta que su dueño llame a `SettleLimitOrder`. 3. **Enrutamiento de comisión unilateral** — cuando `pool.fee_on = Token0Only` o `Token1Only`, el paso del swap calcula el mismo intercambio entrada-salida; la comisión se enruta luego al lado configurado. En las direcciones donde el lado de comisión configurado es la salida, la comisión se deduce del output del swap (el usuario recibe `out − fee`); en las direcciones donde es la entrada, el comportamiento coincide con `FromInput`. Ver `is_fee_on_input(zero_for_one)` y `is_fee_on_token0(zero_for_one)` en `PoolState`. `Swap` (V1) implementa la misma comisión dinámica, enrutamiento de comisión unilateral y coincidencia de órdenes límite que `SwapV2`; la única característica que le falta es el soporte de Token-2022: ambos vaults deben ser SPL Token clásico. Los pools con cualquier mint Token-2022 deben operarse vía `SwapV2`. El agregador y el SDK ya prefieren V2 para cada tramo CLMM, por lo que los callers no necesitan ramificar según el tipo de mint. ## `OpenLimitOrder` Coloca una orden de venta en un tick específico. La orden se sitúa en una cola FIFO por tick y se ejecuta a medida que el precio la atraviesa. **Argumentos** ``` nonce_index: u8 // índice de cuenta-nonce elegido por el usuario (0..255 por wallet) zero_for_one: bool // true: vender token0 por token1; false: vender token1 por token0 tick_index: i32 // debe ser múltiplo de pool.tick_spacing amount: u64 // cantidad del token de entrada ``` **Cuentas (resumen)** | # | Nombre | W | S | Notas | | -- | ------------------------ | - | - | ---------------------------------------------------------------------------------------- | | 1 | `payer` | W | S | Dueño de la orden; paga el alquiler. | | 2 | `pool_state` | W | | | | 3 | `tick_array` | W | | El tick array que contiene `tick_index`. | | 4 | `limit_order_nonce` | W | | PDA. `init_if_needed` — se crea en la primera orden del usuario bajo este `nonce_index`. | | 5 | `limit_order` | W | | PDA. `init` aquí. | | 6 | `input_token_account` | W | | ATA de entrada del usuario. | | 7 | `input_vault` | W | | Vault de entrada del pool. | | 8 | `input_vault_mint` | | | Manejo de comisiones Token-2022. | | 9 | `input_token_program` | | | SPL o Token-2022. | | 10 | `system_program`, `rent` | | | | **Precondiciones** * `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 (al vender token0 → el tick debe estar por encima del actual, y viceversa). Vender en un tick ya cruzado se ejecutaría de inmediato y es rechazado. * `pool_state.status` permite la operación de orden límite (bit 5). **Postcondiciones** * `limit_order` existe, registrando `tick.order_phase` y `tick.unfilled_ratio_x64` al momento de apertura. * `tick.orders_amount += amount` (en la cohorte actual). * `limit_order_nonce.order_nonce += 1`. * Se emite `OpenLimitOrderEvent`. **Errores comunes** — `InvalidLimitOrderAmount` (cero o por debajo del mínimo del pool), `InvalidTickIndex` (fuera de `[MIN_TICK, MAX_TICK]`, o en el lado incorrecto de `tick_current` para la dirección elegida), `TickAndSpacingNotMatch` (`tick_index % pool.tick_spacing != 0`), `OrderPhaseSaturated`. ## `IncreaseLimitOrder` Agrega monto a una orden abierta existente. Solo puede ser llamado por el `owner` de la orden. **Argumentos** ``` amount: u64 // cantidad adicional del token de entrada ``` **Cuentas** — igual que `OpenLimitOrder` sin la cuenta nonce; la PDA `limit_order` se pasa directamente. **Precondiciones** * `limit_order.owner == signer`. * La orden sigue en la misma cohorte (`tick.order_phase == limit_order.order_phase`). Si la cohorte ya comenzó a ejecutarse, la orden está parcialmente liquidada: el caller debería llamar primero a `DecreaseLimitOrder` o `SettleLimitOrder` para avanzar. **Efecto** * Transfiere `amount` desde la ATA del dueño al `input_vault`. * `limit_order.total_amount += amount`; `tick.orders_amount += amount`. ## `DecreaseLimitOrder` Reduce o cancela completamente una orden abierta. Devuelve el remanente sin ejecutar al dueño, más cualquier output ya liquidado por ejecuciones parciales anteriores. **Argumentos** ``` amount: u64 // cantidad del token de entrada a retirar (máx. = remanente sin ejecutar) amount_min: u64 // piso de slippage en el retiro del lado de entrada ``` **Cuentas** — ambos lados de token, entrada y salida: | # | Nombre | 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` | | | **Efecto** * Recalcula el amount ejecutado de la orden a partir del `unfilled_ratio_x64` de la cohorte desde la apertura. * Envía el output ejecutado a `output_token_account`. * Devuelve `amount` de la entrada sin ejecutar a `input_token_account`. * Actualiza `limit_order` en consecuencia. Si el nuevo remanente sin ejecutar es cero, el programa cierra la cuenta y devuelve el alquiler al `owner`. ## `SettleLimitOrder` Envía los tokens de output ejecutados al dueño sin cambiar el remanente sin ejecutar de la orden. Útil cuando los keepers de `auto_withdraw` quieren pagar de forma gradual ejecuciones parciales prolongadas. **Caller** — el `owner` de la orden o el `limit_order_admin` del programa (una billetera caliente operacional fuera de la cadena que ejecuta un bucle de keeper automatizado). El keeper no tiene otra autoridad: no puede mover fondos del usuario más allá de enviar el output ejecutado a la ATA del `owner` de la orden. **Cuentas** | # | Nombre | W | S | | | - | ---------------------- | - | - | ----------------------------- | | 1 | `signer` | | S | dueño *o* `limit_order_admin` | | 2 | `pool_state` | | | | | 3 | `tick_array` | | | | | 4 | `limit_order` | W | | | | 5 | `output_token_account` | W | | ATA de salida del dueño. | | 6 | `output_vault` | W | | Vault de salida del pool. | | 7 | `output_vault_mint` | | | | | 8 | `output_token_program` | | | | **Efecto** * Calcula el output acumulado adeudado 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; sigue abierta frente a cualquier entrada restante. ## `CloseLimitOrder` Cierra una cuenta de orden completamente consumida. El alquiler siempre se devuelve a `limit_order.owner` independientemente de quién firme. **Caller** — el `owner` o el `limit_order_admin`. **Precondiciones** * La orden tiene remanente sin ejecutar igual a cero (ya sea porque `amount == total_amount` fue ejecutado y liquidado, o porque el dueño redujo previamente la orden a cero y olvidó cerrarla). **Efecto** * Cierra `limit_order`; el alquiler se envía a `limit_order.owner`. ## `CreateDynamicFeeConfig` (admin) Crea un conjunto de parámetros reutilizable bajo un índice u16. **Argumentos** ``` 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% de retención por ventana de decaimiento dynamic_fee_control: u32 // 1..100_000; ganancia en la curva volatilidad-comisión max_volatility_accumulator: u32 // techo ``` **Cuentas** | # | Nombre | W | S | Notas | | - | -------------------- | - | - | ---------------------------------- | | 1 | `owner` | W | S | Clave pública de admin codificada. | | 2 | `dynamic_fee_config` | W | | PDA, `init` aquí. | | 3 | `system_program` | | | | **Errores comunes** — `InvalidDynamicFeeConfigParams` si `decay_period <= filter_period` o algún campo con valor 0 está fuera de los límites. ## `UpdateDynamicFeeConfig` (admin) Modifica un `DynamicFeeConfig` existente. Los pools que ya tomaron una instantánea de la configuración en el momento de su creación **no** se actualizan retroactivamente; solo los pools recién creados que referencien esta configuración obtendrán los nuevos valores. **Argumentos** — los mismos cinco campos de calibración que `CreateDynamicFeeConfig` (`filter_period`, `decay_period`, `reduction_factor`, `dynamic_fee_control`, `max_volatility_accumulator`); el `index` se fija en la creación y no se vuelve a pasar aquí. ## `CollectProtocolFee` / `CollectFundFee` Tienen la misma forma que `CollectProtocolFee` / `CollectFundFee` de CPMM. El firmante debe coincidir con `AmmConfig.owner` / `AmmConfig.fund_owner`. Barre las comisiones de protocolo/fondo acumuladas de los vaults del pool hacia un destinatario, poniendo a cero los campos `PoolState.protocol_fees_*` / `fund_fees_*` correspondientes. ## `InitializeReward` Adjunta un nuevo flujo de recompensas a un pool. Pueden estar activos hasta 3 flujos simultáneamente. **Argumentos** ``` open_time: u64 end_time: u64 emissions_per_second_x64: u128 // Q64.64 ``` **Cuentas** | # | Nombre | W | S | | | - | ------------------------ | - | - | -------------------------------------------------------------------------- | | 1 | `reward_funder` | W | S | | | 2 | `funder_token_account` | W | | | | 3 | `amm_config` | | | | | 4 | `pool_state` | W | | | | 5 | `operation_state` | | | PDA de estado de operaciones CLMM que controla la creación de recompensas. | | 6 | `reward_token_mint` | | | | | 7 | `reward_token_vault` | W | | `init` aquí. | | 8 | `reward_token_program` | | | | | 9 | `system_program`, `rent` | | | | **Precondiciones** * Menos de 3 flujos activos actualmente en el pool. * El financiador deposita `total_emission = emissions_per_second × (end_time − open_time)` en tokens de recompensa en el vault como parte de esta instrucción. * Mint de recompensa en la lista blanca según `operation_state`. ## `SetRewardParams` Extiende, recarga o cambia la tasa de emisión de un flujo de recompensas existente. Normalmente es llamado por el creador del pool o el multisig de Raydium. Las restricciones están en cadena: generalmente puedes extender `end_time` o aumentar las emisiones, pero no reducirlas retroactivamente. Consulta la lista de propietarios de `operation_state`. ## `UpdateRewardInfos` Contabilidad pura: liquida `reward_growth_global_x64` al tiempo actual multiplicando `emissions_per_second × Δt / liquidity`. Es llamado internamente por cada instrucción que toca la liquidez. Se expone como instrucción independiente porque actores externos (interfaces, cranks) a veces quieren activarla. ## `CollectReward` El dueño de la posición reclama los tokens de recompensa adeudados. **Cuentas** | # | Nombre | W | S | | | - | ------------------------- | - | - | ---------------------------------------------- | | 1 | `nft_owner` | | S | | | 2 | `nft_account` | | | ATA del dueño que contiene el NFT de posición. | | 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` | | | | **Efecto** * Liquida el crecimiento de recompensas (mismo patrón que las comisiones). * Transfiere el monto adeudado a la ATA destinataria, poniendo `reward_amount_owed[i]` a cero. ## Matriz de cambios de estado | Instrucción | `pool.liquidity` | `pool.fee_growth_global` | `pool.reward_growth_global` | `personal_position.liquidity` | Tick array | | ------------------------ | ---------------- | ------------------------ | --------------------------- | ----------------------------- | ----------------------------------------------------------- | | `CreatePool` | 0 | 0 | — | — | — | | `OpenPosition` | + si en rango | — | — | nuevo | agrega liquidity\_gross/net | | `IncreaseLiquidity` | + si en rango | liquida adeudado | liquida adeudado | + | ajusta | | `DecreaseLiquidity` | − si en rango | liquida adeudado | liquida adeudado | − | ajusta | | `ClosePosition` | — | — | — | destruido | — | | `SwapV2` | ± en cruces | + | — | — | cruza y voltea outside; coincide cohortes de órdenes límite | | `OpenLimitOrder` | — | — | — | — | `orders_amount += amount` en el tick objetivo | | `IncreaseLimitOrder` | — | — | — | — | `orders_amount += amount` | | `DecreaseLimitOrder` | — | — | — | — | `orders_amount -=`, puede cerrar cohorte | | `SettleLimitOrder` | — | — | — | — | — (solo lectura en tick) | | `CloseLimitOrder` | — | — | — | — | — | | `CreateCustomizablePool` | 0 | 0 | — | — | — | | `UpdateRewardInfos` | — | — | + | — | — | | `CollectReward` | — | — | liquida adeudado | — | — | ## Siguientes pasos * [`products/clmm/code-demos`](/es/products/clmm/code-demos) — ejemplos ejecutables en TypeScript. * [`products/clmm/fees`](/es/products/clmm/fees) — detalles sobre el cálculo de comisiones y recompensas. * [`reference/error-codes`](/es/reference/error-codes) — tabla completa de errores Anchor de CLMM. Fuentes: * [`raydium-io/raydium-clmm` — `programs/amm/src/instructions`](https://github.com/raydium-io/raydium-clmm) * Raydium SDK v2 — `@raydium-io/raydium-sdk-v2`