Skip to main content
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 — el historial de actualizaciones de estas páginas desde el lanzamiento del proyecto. Cada versión a continuación enlaza a su propia entrada; abre una para ver el resumen completo, los capítulos afectados y la fecha de verificación. Para la línea de tiempo histórica del protocolo, consulta introduction/history-and-milestones.

​
Lanzamientos

​
CLMM: CreateCustomizablePoolV2 abre la creación de múltiples pools a todos
CreatePermissionedPool se renombra a CreateCustomizablePoolV2 y pierde su puerta PDA de Permission, por lo que cualquier pagador puede crear pools adicionales para el mismo par y nivel de comisión en una dirección derivada de seed_index. Los argumentos y la derivación de dirección del pool no cambian, pero el discriminador cambia y la cuenta permission abandona la ranura 3, por lo que los clientes construidos contra la instrucción antigua deben reconstruirse. pool_creator no se autentica, por lo que el owner de un pool V2 no es prueba de quién lo creó. La cuenta Permission, CreatePermissionPda, ClosePermissionPda y la clave permission_pda_admin se eliminan; los PDAs de Permission creados anteriormente permanecen en la cadena como datos inactivos. Ningún diseño de cuenta o código de error cambió. El IDL se reduce a 37 instrucciones.Leer la entrada completa →
​
CLMM: Anchor 1.0, recuperación de lámports excedentes y propietarios de comisiones fijos
CLMM se mueve a Anchor 1.0.2 en Agave 3.1.10, el mismo movimiento que CPMM y LaunchLab hicieron el 2026-09-09. Ambos crates públicos de CPI ahora fijan =1.0.2, por lo que un único programa puede hacer CPI en CPMM y CLMM. Un nuevo admin CollectExcessLamports devuelve la renta liberada por SIMD-0437. Barre un pool por llamada: el PDA PoolState firma sus propias bóvedas y bóvedas de recompensas, las bóvedas wSOL pasan por el viaje redondo SyncNative / UnwrapLamports, y cualquier cuenta propiedad de CLMM en remaining_accounts se reduce hasta su mínimo de renta. CreateAmmConfig ahora escribe claves protocol_fee_owner y fund_fee_owner codificadas en lugar del firmante. En mainnet estas son las claves ya almacenadas en los 21 configs, y los configs existentes no se reescriben. 6052 añadido. Ninguna instrucción visible para el usuario o diseño de cuenta cambió.Leer la entrada completa →
​
CPMM: el protocolo toma una parte de la comisión del creador
CPMM ahora puede retener parte de la comisión del creador. La división se aplica cuando la comisión se cobra, no cuando se carga: un swap aún acumula la comisión completa del creador en creator_fees_token*, y CollectCreatorFee / CollectCreatorFeePermissionless luego mueven una parte a los contadores protocol_fees_token* existentes del pool y pagan al creador el resto — redondeando hacia abajo, por lo que el polvo se queda con el creador. La tasa proviene de un nuevo AmmConfig.creator_fee_share_rate (tallado del relleno; la cuenta sigue siendo 236 bytes, pero el antiguo padding[0] es ahora un campo activo) o de un PDA CreatorFeeShare por creador que lo anula, administrado por el nuevo admin CreateCreatorFeeShare / CloseCreatorFeeShare. Cambio importante para clientes de comisión de creador: ambas instrucciones de cobro toman nuevas cuentas añadidas al final de sus listas — las cuentas existentes mantienen sus posiciones, pero las nuevas son obligatorias, por lo que una transacción previa a la actualización se rechaza por cuentas faltantes. UpdateAmmConfig gana param = 8. PoolState, la matemática de swap y la verificación k no se tocan, y no se añadió ningún código de error. Viajando junto: una corrección de ordenamiento de dos pasadas en CollectExcessLamports.Leer la entrada completa →
​
LaunchLab: Anchor 1.0, recuperación de lámports excedentes y el fin de las puertas de transición
LaunchLab se mueve a Anchor 1.0.2 en Agave 3.1.10 y retira su andamiaje de transición. El Initialize deprecado ahora falla incondicionalmente con NotApproved. MigrateToCpswap es un cambio importante para la billetera de migración: los tres argumentos y nueve cuentas de OpenBook desaparecen, siguiendo la propia eliminación de OpenBook de AMM v4, y el programa ya no inicializa el mercado por CPI. La puerta de reloj get_upgrade_timestamp se elimina, por lo que las tres remaining_accounts de trade son incondicionalmente requeridas (con la ranura system_program ahora validada), MigrateToCpswap siempre toma la ruta CPMM con permisos, e InitializeWithToken2022 elimina su restricción amm_fee_on. Un nuevo admin CollectExcessLamports devuelve la renta liberada por SIMD-0437 — ten en cuenta que las cuentas de origen deben agruparse por cuál de los tres PDAs de autoridad de bóveda las posee. Tres restricciones de dirección de MigrateToCpswap se movieron al cuerpo de la instrucción, cambiando 2012 a 2502. 6031 añadido. Ningún diseño de cuenta, instrucción de trade o comportamiento de comisión cambió.Leer la entrada completa →
​
CPMM: Anchor 1.0, recuperación de lámports excedentes y propietarios de comisiones fijos
CPMM se mueve a Anchor 1.0.2 en Agave 3.1.10 y añade un admin CollectExcessLamports que devuelve la renta liberada por SIMD-0437 de bóvedas, acuñaciones de LP y PDAs — bóvedas SOL envueltas incluidas, a través de un viaje redondo SyncNative / UnwrapLamports que deja el saldo envuelto intacto. Tres cambios de comportamiento viajan junto: CreateAmmConfig ahora escribe claves protocol_fee_owner y fund_fee_owner codificadas en lugar del firmante (los configs existentes no se migran — lee los campos), la MINT_WHITELIST de Token-2022 de cuatro direcciones codificada se elimina para que el PDA del registro SupportMintAssociated sea el único bypass restante, y ClosePermissionPda ahora acepta la autoridad de concesión dedicada. 6015 añadido. Ninguna instrucción visible para el usuario o diseño de cuenta cambió.Leer la entrada completa →
​
AMM v4: dependencias de Solana 3.0 y recuperación de lámports excedentes
AMM v4 se reconstruye contra solana-program 3.0.0, spl-token 9.0.0, spl-associated-token-account 8.0.0 y el nuevo crate solana-system-interface, y añade un WithdrawExcessLamports (etiqueta 18) solo para admin que devuelve la renta liberada por SIMD-0437. Cada instrucción visible para traders y LP mantiene sus cuentas, argumentos y matemática, y nada en el lanzamiento es un cambio importante: CreateConfigAccount dejó de leer su sysvar de renta final pero aún acepta la antigua lista de cinco cuentas. AmmError gana el código 60 (se numera desde 0, no desde 6000).Leer la entrada completa →
​
LaunchLab: las reglas de curva de plataforma reemplazan la lista blanca de parámetros de curva
Las restricciones de parámetros de lanzamiento se mueven fuera de PlatformConfig a cuentas PlatformCurveRule por config. Una regla contiene hasta 10 grupos de verificación de hasta 25 restricciones (field, op, value) sobre 19 parámetros de lanzamiento, con Eq / Gte / Lte / Neq — por lo que una plataforma finalmente puede expresar una banda de valor, niveles alternativos, un tope de valuación de graduación, un piso de migración, compuerta de tipo de token, o un grupo que cambia en una fecha, ninguno de los cuales la lista blanca de solo igualdad podría. PlatformConfig mantiene su tamaño de 944 bytes: restrict_curve_param, curve_rule_manager, y el prefijo de longitud del vec eliminado salen del relleno. Los decodificadores deben soltar el Vec<PlatformCurveParam> final, y los constructores de lanzamiento deben añadir el PDA de regla a remaining_accounts mientras la bandera esté activada. Dos instrucciones eliminadas, cuatro añadidas, dos variantes de UpdatePlatformConfig añadidas, 6024–6030 añadidos. Se requiere actualización de IDL. El SDK envía dos verificaciones puras fuera de la cadena para que un creador nunca tenga que aprender una regla de una transacción revertida, y la entrada documenta un ensayo en devnet antes de habilitar la bandera en mainnet.Leer la entrada completa →
​
LaunchLab: la plataforma mantiene la autoridad de retiro de fondos retenidos desde la creación de acuñación
InitializeWithToken2022 ahora escribe PlatformConfig.transfer_fee_extension_auth en la withdraw_withheld_authority de la nueva acuñación base en lugar del PDA de authority de lanzamiento, por lo que una plataforma puede barrer comisiones de transferencia retenidas durante la fase de curva de vinculación en lugar de esperar a la graduación — el programa en sí no tiene instrucción de retiro de fondos retenidos. MigrateToCpswap reasigna esa autoridad solo cuando el PDA aún la mantiene, lo que mantiene la graduación funcionando para acuñaciones de ambas generaciones. transfer_fee_config_authority aún se mueve solo en la graduación, por lo que rotar transfer_fee_extension_auth a mitad del lanzamiento silenciosamente deja las dos autoridades en claves diferentes. Ningún diseño de cuenta, instrucción, argumento o código de error cambió.Leer la entrada completa →
​
LaunchLab: el tope de tasa de comisión de plataforma se eleva a 500 bps
El techo de fee_rate de la plataforma se mueve a 50000 (500 bps) en ambas rutas que lo validan. CreatePlatformConfig estaba limitado a 10000 (100 bps) desde el primer lanzamiento del programa; UpdatePlatformConfig estaba limitado a 25000 (250 bps) desde 2026-01-27. Las dos verificaciones ahora están de acuerdo, por lo que una plataforma creada a cualquier tasa permitida también puede actualizarse en ella — incluyendo a través de la variante AllInfo de granel, que revalida fee_rate mientras reescribe todos los demás campos. Las dos rutas aún generan errores diferentes (InvalidInput en crear, InvalidPlatformInfo en actualizar). Ningún diseño de cuenta, instrucción o código de error cambió, y ninguna plataforma o lanzamiento existente se reprecia. GlobalConfig.max_share_fee_rate se mantiene en 100 bps y solo limita el share_fee_rate de referencia por transacción.Leer la entrada completa →
​
LaunchLab: acuñaciones de cotización Token-2022
Un lanzamiento ahora puede cotizarse en una acuñación Token-2022. CreateConfig, InitializeV2, InitializeWithToken2022, las cuatro instrucciones de swap y cada reclamación de comisión aceptan cualquier programa de token en su ranura de programa de cotización; el Initialize deprecado permanece solo como legado. Los límites de deslizamiento de swap ahora se comparan contra lo que el pagador realmente paga o recibe, neto de la comisión de transferencia de la acuñación de cotización. El bit1 de PoolState.token_program_flag se vuelve significativo, por lo que los decodificadores que prueban todo el byte contra 0 malinterpretan una acuñación base heredada como Token-2022. MigrateToCpswap renombra sus dos cuentas de programa de token a token_program / token_program_2022, y 6023 se reutiliza para CalculateOverflow.Leer la entrada completa →
​
LaunchLab: lanzamientos solo CPMM y controles de configuración de plataforma
La inicialización de lanzamiento nueva ahora requiere CPMM mientras el estado heredado vinculado a AMM v4 permanece migratable. Antes de este lanzamiento, creator_scale producía una Clave de Comisión propiedad del creador; las migraciones de CPMM ejecutadas después de la actualización en su lugar consolidan platform_scale + creator_scale en una parte de Clave de Comisión propiedad de la plataforma. Las plataformas también pueden restringir lanzamientos con sus propios PDAs PlatformAllowConfig, y los constructores de migración deben añadir ambos PDAs de soporte de acuñación de CPMM.Leer la entrada completa →
​
CLMM: congelación de NFT de posición de emisor restringido
Las nuevas acuñaciones de NFT de posición de CLMM usan su pool como autoridad de congelación, pero sus cuentas de token permanecen descongeladas por defecto. La congelación ocurre solo en OpenPositionV2 u OpenPositionWithToken22Nft cuando la autoridad de congelación de cualquiera de las acuñaciones de bóveda subyacentes coincide con la lista de emisor restringido. Una posición coincidente no puede transferir o cambiar propietario pero aún puede administrar liquidez. Su llamada ClosePosition debe añadir el pool para que CLMM pueda descongelar, quemar y cerrar atómicamente. Las posiciones existentes permanecen sin cambios.Leer la entrada completa →
​
CPMM: cobro de comisión de creador sin permisos
Una instrucción aditiva CollectCreatorFeePermissionless permite que cualquier pagador barra todas las comisiones de creador acumuladas, mientras limita el beneficiario y ambos destinos de token a PoolState.pool_creator y los ATAs canónicos del creador. La ruta original firmada por el creador permanece sin cambios. CreatePermissionPda también acepta una autoridad de concesión dedicada, mientras que ClosePermissionPda permanece solo para admin.Leer la entrada completa →
​
CLMM: múltiples pools con permisos y protección de cuenta congelada de orden límite
Dos actualizaciones aditivas y compatibles hacia atrás del programa CLMM. CreatePermissionedPool incorpora un seed_index no cero suministrado por el cliente en las semillas del PDA del pool, permitiendo que un operador en la lista blanca (uno que posea un PDA Permission) cree múltiples pools por (config, mint0, mint1) — por lo que un ID de pool ya no es canónico para un par. Las nuevas instrucciones de admin CreatePermissionPda / ClosePermissionPda administran esas concesiones, y PoolState gana un campo seed_index (tallado del relleno, sin cambio de tamaño). Por separado, OpenLimitOrder ahora toma las cuentas del lado de salida y rechaza órdenes cuya cuenta de token de entrada o salida está congelada (NotApproved).Leer la entrada completa →
​
AMM v4: eliminar dependencia de OpenBook / Serum
AMM v4 elimina su dependencia de OpenBook/Serum de larga data, todos los CPIs de libro de órdenes y las instrucciones de creación de mercado muertas. SwapBaseIn / SwapBaseOut, Deposit y Withdraw mantienen sus diseños (las cuentas de mercado eliminadas ahora se ignoran, no se validan); un WithdrawPnl con cambio importante (17 → 10, sin compatibilidad) y SetParams (cuentas reducidas + param renumerado); e Initialize, PreInitialize, MonitorStep, MigrateToOpenBook, WithdrawSrm, SimulateInfo, AdminCancelOrders ya no son invocables. Los diseños de cuenta en la cadena y los códigos de error permanecen estables; migra los swaps a los puntos de entrada V2.Leer la entrada completa →
​
Stable AMM: eliminar código de OpenBook (mercado) muerto
Stable AMM elimina sus cuentas y código de creación de mercado de OpenBook de larga data. Diseños más pequeños de SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12) y Withdraw (21/22 → 12) (los diseños antiguos aún son compatibles); un cambio WithdrawPnl con cambio importante (16 → 10, sin compatibilidad); la comisión de referencia retirada; y una fórmula de activo de pool simplificada solo de bóveda. La mayoría de las otras instrucciones de Stable ya no son invocables.Leer la entrada completa →
​
CLMM: órdenes límite, comisión de un lado, comisión dinámica
Tres capacidades de CLMM opcionales y compatibles hacia atrás: órdenes límite de primera clase (con un guardián de liquidación limit_order_admin), cobro de comisión de un lado (CollectFeeOn) y una comisión dinámica que rastrea volatilidad. Añade CreateCustomizablePool, un cambio de forma de PoolState (cambio importante para indexadores), nuevos campos de TickState, once nuevos códigos de error (con un cambio numérico) y adiciones coincidentes de SDK / API.Leer la entrada completa →
​
Publicación inicial
Primer lanzamiento público del conjunto de documentación de Raydium, verificado contra implementaciones en mainnet-beta en vivo y @raydium-io/raydium-sdk-v2@0.2.42-alpha.Leer la entrada completa →

​
Convenciones de documentación

  • Versionado: esta documentación utiliza versionado basado en calendario (YYYY-MM-DD). Cada actualización añade una nueva página de entrada y una nueva fila en la línea de tiempo anterior.
  • Una página por lanzamiento: cada resumen de lanzamiento vive en su propia página bajo reference/changelog/, por lo que este índice se mantiene breve y cada entrada es independientemente enlazable.
  • Fecha verificada: cada entrada registra cuándo el contenido fue verificado por última vez contra el estado en cadena / API y el código fuente del programa. Si no se indica, asume la fecha principal de la entrada.
  • Cambios disruptivos: se destacan en un cuadro de advertencia en las páginas afectadas y se etiquetan en la entrada.
  • 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 como entradas del registro de cambios.

​
Referencias