Registro de cambios

Registro fechado de actualizaciones de este conjunto de documentación. Los registros muestran qué capítulos cambiaron, por qué, y cuándo se verificó el contenido contra el estado de la cadena y el código fuente del programa.

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 →

Este es el registro de cambios de la documentación, es decir, el registro de actualizaciones de estas páginas desde el lanzamiento del proyecto. Para la línea de tiempo histórica del protocolo en sí, consulta introduction/history-and-milestones. Cada entrada aquí tiene una fecha, una lista de capítulos afectados, el motivo del cambio, y una fecha de verificación que indica cuándo se verificó por última vez el estado de la cadena y el código fuente del programa con el contenido escrito.

​

2026-05-18 — CLMM: órdenes limitadas, comisión unilateral, comisión dinámica

La próxima versión de CLMM añade tres capacidades a nivel de pool. Se pueden activar opcionalmente en el momento de la creación del pool y son compatibles hacia atrás con los pools y posiciones existentes.

​

TL;DR para integradores

• Las órdenes limitadas ahora son primitivos de CLMM de primera clase. Los proveedores de liquidez pueden abrir una orden de tick único en un pool que las admita; la orden se completa FIFO cuando un swap cruza el tick, y un guardián fuera de la cadena (limit_order_admin) puede liquidar el resultado sin que el propietario esté conectado. Siete nuevos métodos del SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) y tres nuevos puntos finales de Temp API bajo /limit-order/ (órdenes activas, historial por usuario, registro de eventos por PDA) cubren todo el flujo.
• Comisión unilateral (CollectFeeOn) permite que un pool cobre comisiones de swap del lado de entrada (heredado, modo 0), o siempre de token_0 (modo 1), o siempre de token_1 (modo 2). Útil cuando uno de los lados del par es el token contable canónico.
• Comisión dinámica permite que un pool opte por un recargo de seguimiento de volatilidad que aumenta con el movimiento rápido de ticks y disminuye con el tiempo, calibrado por una DynamicFeeConfig por nivel y una DynamicFeeInfo por pool. El nuevo punto final /main/clmm-dynamic-config expone la lista de niveles.
• Una nueva instrucción, CreateCustomizablePool, expone los tres controles en el momento de la creación del pool. El clásico CreatePool continúa funcionando para pools con comisión por defecto y sin órdenes limitadas.
• Cambio incompatible del indexador: los contadores de volumen por dirección (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) y contadores de comisión de por vida (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) en PoolState fueron jubilados en relleno para hacer espacio para fee_on e dynamic_fee_info. Los indexadores que leen esos campos directamente deben migrar al ring Observation de la cadena o a la API.

​

Por qué importa esto (para traders, proveedores de liquidez e integradores)

• Traders obtienen cotizaciones más ajustadas en pares de cola larga y impulsados por eventos: la comisión dinámica permite que el pool absorba recargos de volatilidad del tomador sin que los proveedores de liquidez tengan que ampliar activamente rangos, y las escaleras de órdenes limitadas profundizan la liquidez en la cadena a precios específicos sin comprometer el capital en todo el rango.
• Proveedores de liquidez obtienen una tercera estrategia junto con rangos concentrados y posiciones de rango completo: aparcar órdenes de precio exacto, completarse cuando el precio visita, liquidarse en el token de cotización. No se requiere reequilibrio activo para la porción completada.
• Integradores pueden modelar pools con comisión dinámica de forma determinista: el algoritmo y los parámetros están completamente en la cadena, los niveles de calibración son consultables, y la ruta de swap no cambia de forma (solo la comisión por paso varía).

​

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 de volatilidad máximo). Creado por CreateDynamicFeeConfig (admin), referenciado por CreateCustomizablePool cuando está habilitada la comisión dinámica.
• LimitOrderState — cuenta por orden (semillas de PDA: [owner, limit_order_nonce, order_nonce]) que contiene el pool, tick, lado, cantidad de entrada, relación no completada, fase de cohorte FIFO, y snapshots de mantenimiento de registros. El ciclo de vida es implícito (filled_amount vs total_amount, más existencia de cuenta): Open → Filled → Settled → Closed.
• LimitOrderNonce — contador que se incrementa monótonamente para cada (propietario, índice_nonce) que obtiene las semillas de PDA de orden limitada. El nonce_index: u8 permite que el mismo propietario particione órdenes en hasta 256 flujos de nonce independientes.

Consulta Cuentas → DynamicFeeConfig y DynamicFeeInfo y Cuentas → LimitOrderState.

​

Reestructuración de PoolState

Grupo de campos	Diseño antiguo	Diseño nuevo
Contadores de volumen por dirección	swap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1	Plegado en padding5: [u128; 4]
Contadores de comisión de por vida	total_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1	Plegado en padding6: [u64; 4]
Comisión unilateral	—	fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Comisión dinámica	—	dynamic_fee_info: DynamicFeeInfo (incrustado)

El tamaño total de la cuenta es sin cambios. Indexadores: cambia el seguimiento de volumen desde PoolState al ring Observation o a la API. Los contadores jubilados no se ponen a cero en los pools existentes (contienen lo que sea que hayan llevado por último), por lo que releerlos después de la actualización devolverá datos antiguos.

​

Adiciones de TickState (sin cambios incompatibles)

Se añaden cuatro nuevos campos al final de TickState, reemplazando parte de su relleno final:

• order_phase: u64 — contador que desambigua cohortes de órdenes limitadas en este tick.
• orders_amount: u64 — entrada total comprometida por todas las órdenes abiertas en este tick (no todas están completamente sin completar).
• part_filled_orders_remaining: u64 — entrada aún sin completar en la cohorte que actualmente está siendo consumida por swaps.
• unfilled_ratio_x64: u128 — relación Q64.64 utilizada para calcular la cuota de relleno de cada orden.

El diseño de matriz de ticks, tamaño y semillas de PDA no cambian.

​

Nuevas instrucciones

• CreateDynamicFeeConfig (admin) — crear un nivel DynamicFeeConfig calibrado. Autoridad: el mismo multisig de tesorería que CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — actualizar los parámetros de un nivel existente.
• CreateCustomizablePool — punto de entrada de creación de pool que expone collect_fee_on, enable_dynamic_fee, y dynamic_fee_config. Coexiste con CreatePool; recomendamos CreateCustomizablePool para cualquier nuevo pool que necesite los nuevos controles.
• OpenLimitOrder — abrir una orden limitada de tick único. Incrementa LimitOrderNonce, asigna LimitOrderState, coloca la orden en la cohorte FIFO en el tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajustar la porción sin completar de una orden. Revierte en una orden completada con InvalidOrderPhase.
• SettleLimitOrder — barrida del resultado completado hacia el ATA del propietario. El llamador puede ser el propietario o el guardián limit_order_admin del pool.
• CloseLimitOrder — cerrar una orden completamente liquidada para recuperar el alquiler.

​

Cambios de comportamiento de SwapV2

La ruta de swap en sí no cambia de forma, pero tres cosas ahora suceden en el camino:

1. Comisión dinámica (cuando está habilitada): la DynamicFeeInfo del pool se actualiza en cada paso (decaimiento → acumulación → límite), y el recargo resultante se añade encima de la comisión base para ese paso.
2. Coincidencia de órdenes limitadas (cuando el paso cruza un tick inicializado que tiene órdenes abiertas): parte de la entrada de swap se consume FIFO para completar la cohorte en ese tick, con unfilled_ratio_x64 actualizado atómicamente.
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 siempre del lado de entrada.

Cada uno de estos es un no-op cuando el pool fue creado con los valores por defecto heredados. Consulta Instrucciones → SwapV2 para la matriz de cambios de estado actualizada.

​

Nuevos códigos de error

La enumeración ErrorCode fue renumerada en esta versión: cinco variantes heredadas (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) fueron removidas, y once variantes nuevas fueron añadidas. Porque Anchor numera errores por orden de enumeración desde 6000, cada código de error en o después de las posiciones removidas ha cambiado — los clientes que codificaron valores numéricos necesitan remapear.

Los nuevos códigos son:

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

Las cadenas completas y la tabla posterior al cambio para todos los errores de CLMM están en Códigos de error.

​

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 ayudantes REST en raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Nuevos tipos: enumeración CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Reorganización interna: utils/ movido a libraries/. El barril del paquete no cambia; solo las importaciones profundas bajo @raydium-io/raydium-sdk-v2/utils/... necesitan actualización a …/libraries/....

Los recorridos de TypeScript de punta a punta viven en products/clmm/code-demos.

​

Qué cambió en las APIs

• api-v3 — dos nuevos puntos finales bajo /main/:
  • GET /main/clmm-dynamic-config — lista de niveles DynamicFeeConfig.
  • GET /main/clmm-limit-order-config — configuración de órdenes limitadas por pool.
• temp-api-v1 — tres nuevos puntos finales bajo /limit-order/:
  • GET /limit-order/order/list?wallet=… — órdenes aparcadas actualmente de una cartera (abiertas y parcialmente completadas, servidas desde el caché Redis del indexador; la misma carga útil cubre ambas fases a través de totalAmount / filledAmount / pendingSettle).
  • GET /limit-order/history/order/list-by-user?wallet=… — órdenes limitadas históricas de una cartera. Filtros opcionales: poolId, mint1, mint2, hideCancel. Paginación por cursor a través de 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 una o más PDAs de orden limitada separadas por comas. Paginación por cursor a través de nextPageId / size (máx 100).

Los cinco están documentados en la pestaña API Reference.

​

Superficie de autoridad

El limit_order_admin es un guardián operacional fuera de la cadena, no un multisig. Solo puede llamar a SettleLimitOrder y CloseLimitOrder en órdenes existentes, y el resultado de una liquidación siempre se deposita en el ATA del propietario. No puede mutar campos de pool, abrir o modificar órdenes, o firmar por nada más. Consulta Claves de administrador y multisig → CLMM.

​

Páginas actualizadas

• products/clmm/overview — nueva sección “Novedades” y punteros de pasos siguientes actualizados.
• products/clmm/accounts — tres nuevas cuentas, reestructuración de PoolState con advertencia de migración, adiciones de TickState, nuevos ayudantes de PDA.
• products/clmm/instructions — siete nuevas instrucciones, apéndice de 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 coincidencia de órdenes limitadas, derivación de comisión dinámica.
• products/clmm/code-demos — demostración de createCustomizablePool, recorrido completo de órdenes limitadas, nuevas trampas.
• algorithms/clmm-math — referencia cruzada a coincidencia de órdenes limitadas y comisión dinámica en el bucle de swap multi-tick.
• sdk-api/typescript-sdk — sección de adiciones del módulo CLMM, nota de migración utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — dos nuevos puntos finales con esquemas de respuesta.
• api-reference/openapi/temp-api-v1.yaml — tres nuevos puntos finales de órdenes limitadas (/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 puntos finales de configuración de CLMM.
• api-reference/temp-api-v1/overview — nota sobre los nuevos puntos finales de órdenes activas, historial por usuario, y eventos por PDA.
• reference/error-codes — once nuevos códigos de error de CLMM (6040–6050) más cinco códigos heredados removidos; los códigos numéricos después de los puntos de eliminación han cambiado.
• security/admin-and-multisig — nueva fila de admin de DynamicFeeConfig y fila de guardián limit_order_admin, con explicador de autoridad acotada.

Verificado contra:

• Fuente de raydium-clmm.
• Fuente de @raydium-io/raydium-sdk-v2.
• Fuente de api-v3 y temp-api-v1.

​

2026-04-26 — Publicación inicial

Primera versión pública del conjunto de documentación de Raydium.

Verificado contra:

• Implementaciones de programas en vivo en Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Referencias públicas de Raydium y en la cadena a través de abril de 2026.

A partir de ahora, cada actualización de protocolo, auditoría o revisión de documentación se registra como una nueva entrada en este archivo.

​

Convenciones de documentación

• Versionado: esta documentación utiliza versionado basado en calendario (YYYY-MM-DD). Cada actualización crea una nueva entrada en la parte superior del archivo.
• Fecha verificada: cada entrada registra cuándo se verificó por última vez el contenido con el estado de la cadena / API y el código fuente del programa. Si no se indica, asume la fecha principal de la entrada.
• Cambios incompatibles: se destacan en una advertencia recuadrada en las páginas afectadas y se etiquetan en la entrada a continuación.
• Cobertura: este registro de cambios cubre el conjunto de documentación en sí. La línea de tiempo histórica del protocolo vive en introduction/history-and-milestones y es la fuente de verdad para “cuándo sucedió X en Raydium”.

​

Correcciones

Si encuentras un error en esta documentación, abre un problema o una solicitud de extracción en el repositorio de documentación. Las correcciones se registran en este registro de cambios.

​

Punteros

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