Versiones y migración

​

Estado de un vistazo

La conclusión más importante de esta tabla: AMM v4 no está deprecado, y CPMM es el nuevo estándar — pero coexisten deliberadamente. Los pools de AMM v4 tienen años de historial de trading y no se están migrando forzosamente. La elección de en qué programa lanzar un nuevo pool es una recomendación, no una restricción.

​

AMM v4 — estado y trayectoria

AMM v4 es el diseño original del pool de Raydium: fijación de precios de producto constante (x · y = k). Se lanzó como un AMM híbrido con integración de libro de órdenes de OpenBook (anteriormente Serum) que reflejaba porciones de la curva como órdenes limitadas en un mercado vinculado. La integración de OpenBook ha sido desactivada desde entonces — los pools ya no comparten liquidez con OpenBook y todos los swaps se ejecutan puramente contra la curva a través de los puntos de entrada de swap V2. AMM v4 hoy es, en la práctica, un AMM de producto constante puro con las cuentas de OpenBook preservadas como estado inerte.

​

Qué está congelado

• Sin nuevas estructuras de comisiones. La estructura de comisiones de AMM v4 es por pool y se estableció en el despliegue. Los nuevos pools aceptan la misma comisión de trading codificada ~0.25%, ~12% para el protocolo.
• Sin nuevo trabajo de características. El equipo no ha añadido nuevas instrucciones a AMM v4 desde que CPMM se convirtió en el nuevo estándar. El programa está en modo de administración — solo correcciones de errores, sin expansión de alcance.
• Sin soporte de Token-2022. AMM v4 fue escrito antes de que Token-2022 existiera y la integración nunca fue adaptada. Los mints de Token-2022 tienen que usar CPMM (o CLMM, donde sea apropiado).
• Integración de OpenBook desactivada. Cada pool de AMM v4 sigue vinculado a una cuenta de mercado de OpenBook correspondiente en cadena, pero el pool ya no publica ni mantiene órdenes en ese mercado. Una interrupción de OpenBook ya no afecta los swaps de AMM v4.

​

Qué sigue funcionando

• Los pools existentes se negocian normalmente. No se forzó ninguna migración de estado; los pools v4 creados en 2021 siguen siendo el lugar activo para muchos pares de alto volumen en 2026.
• Los LPs pueden depositar, retirar y cosechar recompensas de granjas como de costumbre. La migración a CPMM es opcional.
• Los agregadores siguen enrutando a través de él. Jupiter y la API de Raydium Trade indexan los pools v4 como lugares de primera clase.

​

Cuándo seguir usando AMM v4

Honestamente: raramente. Los casos en los que v4 es la mejor opción son limitados:

• El par ya tiene un pool v4 profundo y bien negociado y quieres añadir liquidez a la profundidad existente en lugar de dividir un mercado.

(El enrutamiento integrado de OpenBook ya no es una razón para elegir AMM v4 — esa integración está desactivada.) En todos los demás casos, lanza nuevos pools en CPMM. Consulta user-flows/choosing-a-pool-type para el árbol de decisión completo.

​

CPMM — curva de adopción y migración v4 → CPMM

CPMM (creador de mercado de producto constante, nombre interno raydium-cp-swap) fue desplegado en 2024 como una reescritura de sala limpia destinada a ser el nuevo pool de producto constante estándar. Es estructuralmente el más simple de los programas de Raydium: puro x · y = k, sin libro de órdenes, soporte nativo de Token-2022, huella de transacción más pequeña.

​

Qué obtiene CPMM sobre AMM v4

• Mejores economías de LP por defecto. La AmmConfig predeterminada de CPMM enruta el 100% de las comisiones de trading a los LPs (con la comisión de protocolo conmutable por nivel). AMM v4 codifica ~12% para el protocolo.
• Costo de creación de pool más bajo. No se necesita mercado de OpenBook. La creación es una transacción, ~0.15 SOL de alquiler vs ~0.6 SOL para v4.
• Token-2022. Mints de comisión de transferencia, mints de gancho de transferencia (con advertencias), transferencias confidenciales — todo soportado en CPMM, nada en v4.
• Superficie de integrador más limpia. CPMM tiene un crate publicado amigable con Anchor-CPI (raydium-cp-swap), una lista de cuentas más simple e IDL estable. AMM v4 envía un IDL pero nunca tuvo un crate CPI de Rust mantenido.
• Lista de cuentas más pequeña por swap. ~10 cuentas vs ~17 para v4 (que lleva las cuentas del mercado de OpenBook incluso cuando no las usa).

​

Cuándo vale la pena la migración

Para un pool activamente negociado, el aumento de comisión de LP por sí solo generalmente justifica la migración en unos pocos meses. La aritmética: un pool que gana 0.25% × $X de volumen diario da 0.03% al protocolo en v4 (el 12% faltante). En CPMM eso vuelve a los LPs. Durante un año, eso se compone significativamente. Para un pool de bajo volumen, la migración es más sobre prepararse para el futuro — mejores valores predeterminados, soporte de Token-2022 si alguna vez lo necesitas, integraciones más fáciles.

​

Cómo funciona la migración

No hay actualización en el lugar. La migración es una secuencia crear-nuevo-pool, drenar-pool-antiguo, rellenar-nuevo-pool. El paso a paso completo está en user-flows/migrate-amm-v4-to-cpmm; la forma de alto nivel:

1. Crea un nuevo pool CPMM para el mismo par, en el mismo nivel de comisión que quieres preservar.
2. Coordina con los LPs: anuncia una ventana durante la cual el pool antiguo se drena y el nuevo pool se siembra.
3. Cada LP se retira del pool v4 y deposita en el nuevo pool CPMM.
4. (Opcional) Configura una granja del lado de CPMM para atraer LPs incentivados al nuevo pool.
5. Observa cómo el volumen migra a medida que los agregadores se reequilibran hacia el pool más profundo.

La cadena en sí no impone nada de esto — la API de Raydium y el frontend simplemente favorecen el pool que sea más profundo, y los agregadores enrutan a través del que sea más barato para el usuario.

​

CLMM — programa único, estable entre versiones

CLMM está en su primera versión de programa. No ha habido v2 — las mejoras se han enviado como actualizaciones en el lugar al mismo ID de programa (detrás del multisig con bloqueo de tiempo de 24h), no como una nueva generación. Eso significa que no hay historia de migración de CLMM: las posiciones existentes permanecen donde están, y el comportamiento del programa puede cambiar sutilmente cuando se envía una actualización, pero los diseños de cuentas y PDAs son estables. Lo que ha cambiado en las actualizaciones de CLMM:

• Instrucción SwapV2 añadida para soportar correctamente la matemática de comisión de transferencia de Token-2022. El antiguo Swap sigue siendo invocable; las nuevas integraciones deben dirigirse a SwapV2.
• Extensiones de flujo de recompensas — el conteo de ranura RewardInfo fue aumentado (el original 3 → aún 3 actualmente, pero el patrón de reserva fue ajustado). No se necesita migración de datos.
• Compactación de matriz de ticks — optimización interna para reducir CU en swaps que cruzan muchos ticks. Externamente invisible.
• Reconstrucción de Anchor 1.0 (2026-09-30): se mueve de Anchor 0.32.1 a 1.0.2 y añade el admin CollectExcessLamports. Ninguna instrucción o diseño de cuenta orientada al usuario cambió. Consulta la entrada del changelog.

El IDL vive en el repositorio dedicado raydium-idl (consulta sdk-api/anchor-idl). Si estás ejecutando un SDK más antiguo contra el programa actual, el peor caso es perder las nuevas instrucciones.

​

Farm v3 → v5 → v6

De todos los programas de Raydium, Farm tiene el historial de versiones más explícito y la única ruta de migración forzada. Las tres generaciones son programas separados con IDs de programa separados y diseños de estado separados.

​

Generaciones

​

Por qué existen tres generaciones

• v3 → v5: necesitaba múltiples flujos de recompensa concurrentes (p. ej., granjas de doble incentivo). El diseño de flujo único de v3 no podía soportarlo sin un rediseño.
• v5 → v6: la tasa de emisión entera u64 de v5 limita la tasa mínima expresable a “1 unidad de token por segundo.” Para un mint de 9 decimales, eso es 1 lamport/seg — demasiado grueso para programas de baja emisión. La tasa fraccionaria Q64.64 de v6 soluciona esto. v6 también elevó la actualización basada en slots a reloj de pared, y añadió soporte de Token-2022.

​

Qué permanece igual entre generaciones

• El patrón de contabilidad “depositar LP, acumular contador por acción, reclamar al retirar” es idéntico en v3/v5/v6. La matemática no cambia; solo la precisión del contador de tasa y el número de flujos soportados.
• UserStake (v3/v5) y UserLedger (v6) son conceptualmente el mismo registro, con diseños diferentes. El SDK normaliza ambos.

​

Ruta de migración

No hay migración en el lugar entre versiones de granjas. Para pasar de v3/v5 a v6:

1. Espera a que terminen las emisiones de la granja existente (o redúcelas).
2. Los stakers se retiran y reclaman recompensas pendientes en la granja antigua.
3. El operador de la granja crea una nueva granja v6 contra el mismo mint de staking.
4. Los stakers vuelven a hacer stake en la nueva granja.

La realidad en cadena son dos cuentas de granja no relacionadas. Un usuario con stake en ambas tiene dos registros UserLedger (v6) / UserStake (v5).

​

Qué significa “fase de cierre” para v3 y v5

• Los programas v3 y v5 siguen siendo desplegados e invocables. Las granjas existentes aún pueden distribuir recompensas pendientes y aceptar retiros.
• La interfaz de usuario de Raydium aún muestra granjas v3 y v5 con recompensas activas; una vez que pasa el end_time de una granja v3/v5, la interfaz la oculta de “activas” pero la mantiene reclamable.
• El equipo no creará nuevas granjas v3/v5. Los ayudantes del SDK para “crear granja” enrutan solo a v6.
• v3 y v5 están recibiendo actualizaciones de seguridad pero no trabajo de características. Si se encuentra un error crítico, se corrige; si una característica podría ser útil, se añade a v6 en su lugar.

El detalle completo por versión está en products/farm-staking/accounts e products/farm-staking/instructions.

​

LaunchLab — programa único, configuración en evolución

LaunchLab está en su primera versión de programa. Como CLMM, las mejoras se envían como actualizaciones en el lugar detrás del bloqueo de tiempo de 24h — no como nuevas generaciones. Lo que ha evolucionado a través de actualizaciones:

• Ranura de comisión del creador. Añadida para que los lanzamientos puedan enrutar una porción de las comisiones de trading de CPMM posteriores a la graduación al creador original. Consulta products/launchlab/creator-fees.
• Configurabilidad de fórmula de curva. Originalmente codificada como cuadrática; ahora LaunchConfig selecciona de un pequeño conjunto de formas de curva.

Los lanzamientos existentes de LaunchLab no se ven afectados por actualizaciones — una vez que se inicializa un lanzamiento, sus parámetros se congelan hasta la graduación.

​

Compatibilidad de versiones entre programas

Algunas notas de compatibilidad entre productos que los integradores encuentran rutinariamente:

• SwapV2 de CLMM no es la misma instrucción que Swap. Si tu cliente solo habla Swap, manejará silenciosamente mal las comisiones de transferencia de Token-2022 — la matemática es incorrecta por el monto de la comisión. Actualiza a SwapV2.
• Staking de Farm v6 con posiciones de CLMM no es soportado de la manera que lo es el staking de token LP. Las posiciones de CLMM son NFTs, no tokens LP fungibles. CLMM tiene su propio mecanismo de recompensas nativo en su lugar — consulta products/clmm/fees.
• Los pools de CPMM respaldados por mints de Token-2022 funcionan en granjas solo en Farm v6. v3 y v5 rechazan mints de staking de Token-2022.
• Los pools de AMM v4 nunca tienen mints de LP de Token-2022. Si ves uno, es falso — AMM v4 no soporta esa combinación.

​

Dónde leer más

• introduction/history-and-milestones — la línea de tiempo de lanzamiento cronológica y por qué cada versión llegó cuando lo hizo.
• user-flows/migrate-amm-v4-to-cpmm — el manual del operador para el movimiento v4 → CPMM.
• user-flows/choosing-a-pool-type — árbol de decisión para nuevos despliegues de pools.
• products/farm-staking/accounts — esquema lado a lado para v3 / v5 / v6.
• reference/changelog — qué ha cambiado en esta documentación a medida que las versiones de programas han evolucionado.

Fuentes:

• Páginas de capítulos por producto citadas en línea arriba.
• Raydium SDK v2 — la lógica de despacho consciente de versión confirma a qué programa pertenece un pool dado.
• reference/program-addresses — IDs canónicos por versión.