Changelog

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.

​

Sin publicar — CLMM: órdenes límite, comisión unilateral, comisión dinámica

​

Resumen para integradores

• Las órdenes límite son ahora primitivas de primer nivel en CLMM. Los LPs pueden abrir una orden de un solo tick en un pool que las soporte; la orden se ejecuta en orden FIFO cuando un swap cruza el tick, y un keeper externo (limit_order_admin) puede liquidar la salida ejecutada sin que el propietario esté conectado. Siete nuevos métodos del SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) y tres nuevos endpoints de la API temporal bajo /limit-order/ (órdenes activas, historial por usuario, registro de eventos por PDA) cubren el flujo completo.
• La comisión unilateral (CollectFeeOn) permite que un pool cobre comisiones de swap desde el lado de entrada (modo heredado, 0), siempre desde token_0 (modo 1) o siempre desde token_1 (modo 2). Es útil cuando uno de los lados del par es el token de contabilidad canónico.
• La comisión dinámica permite que un pool adopte un recargo de seguimiento de volatilidad que aumenta con movimientos rápidos de tick y decae con el tiempo, calibrado por un DynamicFeeConfig por nivel y un DynamicFeeInfo por pool. El nuevo endpoint /main/clmm-dynamic-config expone la lista de niveles.
• Una nueva instrucción, CreateCustomizablePool, expone las tres opciones en el momento de crear el pool. El CreatePool clásico sigue funcionando para pools con comisión predeterminada y sin órdenes límite.
• Cambio disruptivo para indexadores: los contadores de volumen por dirección (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) y los contadores de comisiones acumuladas (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) de PoolState fueron retirados hacia padding para dar cabida a fee_on y dynamic_fee_info. Los indexadores que lean esos campos directamente deben migrar al anillo Observation on-chain o a la API.

​

Por qué esto importa (para traders, LPs e integradores)

• Los traders obtienen cotizaciones más ajustadas en pares de cola larga y orientados a eventos: la comisión dinámica permite que el pool absorba recargos de volatilidad del taker sin que los LPs tengan que ampliar rangos activamente, y las escalas de órdenes límite profundizan la liquidez on-chain a precios específicos sin comprometer capital en todo el rango.
• Los LPs disponen de una tercera estrategia junto a los rangos concentrados y las posiciones de rango completo: colocar órdenes a precio exacto, que se ejecuten cuando el precio llegue y liquidar en el token de cotización. No se requiere rebalanceo activo para la porción ejecutada.
• Los integradores pueden modelar pools de comisión dinámica de forma determinista: el algoritmo y los parámetros están completamente on-chain, los niveles de calibración son consultables y la ruta de swap no cambia en su forma (solo varía la comisión por paso).

​

Qué cambió en el programa

​

Nuevas cuentas

• DynamicFeeConfig — registro de calibración por nivel (período de filtro, período de decaimiento, factor de reducción, control de comisión dinámica, acumulador máximo de volatilidad). Se crea mediante CreateDynamicFeeConfig (admin) y es referenciado por CreateCustomizablePool cuando la comisión dinámica está habilitada.
• LimitOrderState — cuenta por orden (semillas PDA: [owner, limit_order_nonce, order_nonce]) que almacena el pool, el tick, el lado, el monto de entrada, la proporción no ejecutada, la fase de cohorte FIFO y los registros contables. El ciclo de vida es implícito (filled_amount frente a total_amount, más la existencia de la cuenta): Abierta → Ejecutada → Liquidada → Cerrada.
• LimitOrderNonce — contador con incremento monotónico por (propietario, índice de nonce) que alimenta las semillas PDA de la orden límite. El campo nonce_index: u8 permite al mismo propietario particionar órdenes en hasta 256 flujos de nonce independientes.

​

Reestructuración de PoolState

​

Adiciones a TickState (sin cambios disruptivos)

• order_phase: u64 — contador que distingue las cohortes de órdenes límite en este tick.
• orders_amount: u64 — total de entrada comprometida por todas las órdenes abiertas en este tick (no todas están completamente sin ejecutar).
• part_filled_orders_remaining: u64 — entrada todavía sin ejecutar en la cohorte que los swaps están consumiendo actualmente.
• unfilled_ratio_x64: u128 — proporción Q64.64 usada para calcular la cuota de ejecución de cada orden.

​

Nuevas instrucciones

• CreateDynamicFeeConfig (admin) — crea un nivel DynamicFeeConfig calibrado. Autoridad: el mismo multisig de tesorería que CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — actualiza los parámetros de un nivel existente.
• CreateCustomizablePool — punto de entrada para crear pools que expone collect_fee_on, enable_dynamic_fee y dynamic_fee_config. Coexiste con CreatePool; recomendamos CreateCustomizablePool para cualquier pool nuevo que necesite las nuevas opciones.
• OpenLimitOrder — abre una orden límite de un solo tick. Incrementa LimitOrderNonce, reserva LimitOrderState e inserta la orden en la cohorte FIFO del tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajusta la porción no ejecutada de una orden. Revierte en una orden completamente ejecutada con InvalidOrderPhase.
• SettleLimitOrder — transfiere la salida ejecutada a la ATA del propietario. El llamante puede ser el propietario o el keeper limit_order_admin del pool.
• CloseLimitOrder — cierra una orden completamente liquidada para recuperar la renta.

​

Cambios de comportamiento en SwapV2

1. Comisión dinámica (cuando está habilitada): el DynamicFeeInfo del pool se actualiza en cada paso (decaimiento → acumulación → tope), y el recargo resultante se añade sobre la comisión base de ese paso.
2. Emparejamiento de órdenes límite (cuando el paso cruza un tick inicializado con órdenes abiertas): parte de la entrada del swap se consume en orden FIFO para ejecutar la cohorte en ese tick, actualizando unfilled_ratio_x64 de forma atómica.
3. Enrutamiento de comisión unilateral (cuando fee_on != 0): la comisión se toma de token_0 o token_1 independientemente de la dirección del swap, en lugar de tomarse siempre del lado de entrada.

​

Nuevos códigos de error

• 6040 OrderAlreadyFilled
• 6041 InvalidOrderPhase
• 6042 InvalidLimitOrderAmount
• 6043 OrderPhaseSaturated
• 6044 InvalidDynamicFeeConfigParams
• 6045 InvalidFeeOn
• 6046 ZeroSqrtPrice
• 6047 ZeroLiquidity
• 6048 MissingBaseFlag
• 6049 MissingMintAccount
• 6050 MissingTokenProgram2022

​

Qué cambió en el SDK (@raydium-io/raydium-sdk-v2)

• Nuevos métodos en raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Nuevos helpers REST en raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Nuevos tipos: enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Reorganización interna: utils/ se movió a libraries/. El barrel del paquete no cambia; solo las importaciones directas bajo @raydium-io/raydium-sdk-v2/utils/... necesitan actualizarse a …/libraries/....

​

Qué cambió en las APIs

• api-v3 — dos nuevos endpoints bajo /main/:
  • GET /main/clmm-dynamic-config — lista de niveles DynamicFeeConfig.
  • GET /main/clmm-limit-order-config — configuración de órdenes límite por pool.
• temp-api-v1 — tres nuevos endpoints bajo /limit-order/:
  • GET /limit-order/order/list?wallet=… — órdenes actualmente activas de una billetera (abiertas y parcialmente ejecutadas, servidas desde la caché Redis del indexador; el mismo payload cubre ambas fases mediante totalAmount / filledAmount / pendingSettle).
  • GET /limit-order/history/order/list-by-user?wallet=… — historial de órdenes límite de una billetera. Filtros opcionales: poolId, mint1, mint2, hideCancel. Paginación por cursor mediante nextPageId / size (máx. 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — registro de eventos por PDA (open / increase / decrease / settle / close) para uno o más PDAs de órdenes límite separados por coma. Paginación por cursor mediante nextPageId / size (máx. 100).

​

Superficie de autoridad

​

Páginas actualizadas

• products/clmm/overview — nueva sección «Novedades» y punteros de siguientes pasos actualizados.
• products/clmm/accounts — tres nuevas cuentas, reestructuración de PoolState con aviso de migración, adiciones a TickState, nuevos helpers de PDA.
• products/clmm/instructions — siete nuevas instrucciones, addendum al comportamiento de SwapV2, matriz de cambios de estado actualizada.
• products/clmm/fees — sección de comisión unilateral, sección de comisión dinámica con tabla de parámetros.
• products/clmm/math — pseudocódigo de emparejamiento de órdenes límite, derivación de comisión dinámica.
• products/clmm/code-demos — demo de createCustomizablePool, recorrido completo de órdenes límite, nuevos casos problemáticos.
• algorithms/clmm-math — referencia cruzada al emparejamiento de órdenes límite y comisión dinámica en el bucle de swap multi-tick.
• sdk-api/typescript-sdk — sección de adiciones al módulo CLMM, nota de migración utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — dos nuevos endpoints con esquemas de respuesta.
• api-reference/openapi/temp-api-v1.yaml — tres nuevos endpoints de órdenes límite (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) con sus esquemas de solicitud y respuesta.
• api-reference/api-v3/overview — nota sobre los nuevos endpoints de configuración CLMM.
• api-reference/temp-api-v1/overview — nota sobre los nuevos endpoints de órdenes activas, historial por usuario y eventos por PDA.
• reference/error-codes — once nuevos códigos de error CLMM (6040–6050) más cinco códigos heredados eliminados; los códigos numéricos a partir de los puntos de eliminación han desplazado su valor.
• security/admin-and-multisig — nueva fila de admin DynamicFeeConfig y fila de keeper limit_order_admin, con explicación de autoridad acotada.

• Código fuente de raydium-clmm.
• Código fuente de @raydium-io/raydium-sdk-v2.
• Código fuente de api-v3 y temp-api-v1.

​

2026-04-26 — Publicación inicial

• Despliegues de programas en vivo en Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Documentación pública de Raydium y referencias on-chain hasta abril de 2026.

​

Convenciones de la documentación

• Versionado: esta documentación usa versionado basado en calendario (YYYY-MM-DD). Cada actualización crea una nueva entrada al inicio del archivo.
• Fecha de verificación: cada entrada registra cuándo se comprobó por última vez que el contenido coincide con el estado on-chain/API y el código fuente del programa. Si no se indica, se asume la fecha principal de la entrada.
• Cambios disruptivos: se señalan con una advertencia destacada en las páginas afectadas y se etiquetan en la entrada correspondiente.
• Cobertura: este registro de cambios cubre el conjunto de documentación en sí. La línea de tiempo histórica del propio protocolo está en introduction/history-and-milestones y es la fuente de verdad sobre «cuándo ocurrió X en Raydium».

​

Correcciones

​

Referencias útiles

• introduction/history-and-milestones — la línea de tiempo del protocolo.
• security/audits — historial de auditorías.
• ray/protocol-fees — distribución de comisiones del protocolo.
• reference/program-addresses — fuente de verdad de los IDs de programa.