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, capítulos afectados y fecha de verificación. Para la línea de tiempo histórica del protocolo, consulta introduction/history-and-milestones.

​
Versiones

​
CPMM: el protocolo retiene 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 es cobrada, no cuando se carga: un swap sigue acumulando toda la comisión del creador en creator_fees_token*, y CollectCreatorFee / CollectCreatorFeePermissionless luego mueven una parte a los contadores existentes protocol_fees_token* 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] ahora es 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 conservan sus posiciones, pero las nuevas son obligatorias, por lo que una transacción previa a la actualización es rechazada por faltar cuentas. UpdateAmmConfig gana param = 8. PoolState, la matemática de swap y la verificación k no se tocan, y no se agregó ningún código de error. Junto con esto: una corrección de ordenamiento de dos pasadas en CollectExcessLamports.Leer la entrada completa →
​
LaunchLab: Anchor 1.0, recuperación de lamports excedentes y fin de las compuertas 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 muy 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 compuerta 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 vault 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 lamports excedentes y propietarios de comisiones corregidos
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 vaults, mints de LP y PDAs — vaults de SOL envuelto incluidos, a través de una ronda SyncNative / UnwrapLamports que deja el saldo envuelto intacto. Tres cambios de comportamiento van junto con esto: CreateAmmConfig ahora escribe claves protocol_fee_owner y fund_fee_owner codificadas en lugar del firmante (las configuraciones existentes no se migran — lee los campos), la lista 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 lamports 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 la versión es un cambio importante: CreateConfigAccount dejó de leer su sysvar de renta final pero sigue aceptando la antigua lista de cinco cuentas. AmmError gana el código 60 (se numera desde 0, no 6000).Leer la entrada completa →
​
LaunchLab: reglas de curva de plataforma reemplazan la lista blanca de parámetros de curva
Las restricciones de parámetros de lanzamiento se mueven de PlatformConfig a cuentas PlatformCurveRule por configuración. 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 — así una plataforma finalmente puede expresar una banda de valor, niveles alternativos, un límite 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 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 del mint
InitializeWithToken2022 ahora escribe PlatformConfig.transfer_fee_extension_auth en la withdraw_withheld_authority del nuevo mint base en lugar del PDA de authority de lanzamiento, para que una plataforma pueda 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 mints 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: límite de tasa de comisión de plataforma aumentado 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 ser actualizada en ella — incluyendo a través de la variante masiva AllInfo, 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: mints de cotización Token-2022
Un lanzamiento ahora puede ser cotizado en un mint 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 se mantiene solo para 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 del mint 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 un mint base heredado 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 esta versión, 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 mint de CPMM.Leer la entrada completa →
​
CLMM: congelación de NFT de posición de emisor restringido
Los nuevos mints 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 los mints de vault 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 restringe 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 se mantiene solo para admin.Leer la entrada completa →
​
CLMM: múltiples pools con permisos y guardia de cuenta congelada de orden limitado
Dos actualizaciones aditivas y compatibles hacia atrás del programa CLMM. CreatePermissionedPool incorpora un seed_index distinto de 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 larga dependencia dormida de OpenBook/Serum, todos los CPIs de libro de órdenes, y las instrucciones muertas de creación de mercado. SwapBaseIn / SwapBaseOut, Deposit, y Withdraw mantienen sus diseños (las cuentas de mercado eliminadas ahora se ignoran, no se validan); un WithdrawPnl muy 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 cadena y códigos de error permanecen estables; migra swaps a los puntos de entrada V2.Leer la entrada completa →
​
AMM estable: eliminar código muerto de OpenBook (mercado)
AMM estable elimina sus cuentas y código de creación de mercado OpenBook dormidas hace mucho tiempo. 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 muy importante (16 → 10, sin compatibilidad); la comisión de referencia retirada; y una fórmula de activo de pool simplificada solo para vault. La mayoría de las otras instrucciones de AMM estable ya no son invocables.Leer la entrada completa →
​
CLMM: órdenes limitadas, comisión de un lado, comisión dinámica
Tres capacidades CLMM opcionales y compatibles hacia atrás: órdenes limitadas 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 vivo de mainnet-beta 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 versión: cada resumen de versión vive en su propia página bajo reference/changelog/, por lo que este índice se mantiene corto y cada entrada es independientemente enlazable.
  • Fecha de verificación: 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 importantes: 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 issue o pull request en el repositorio de documentación. Las correcciones se registran como entradas del registro de cambios.

​
Enlaces útiles