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
LaunchLab: Anchor 1.0, recuperación de lamports excedentes y fin de las compuertas de transición
LaunchLab se actualiza 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. MigrateToAmm es un cambio radical 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 los tres remaining_accounts de transacción ahora son obligatorios (con la ranura system_program 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 las 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 transacción o comportamiento de tarifa cambió.Leer la entrada completa →CPMM: Anchor 1.0, recuperación de lamports excedentes y propietarios de tarifa corregidos
CPMM se actualiza 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 — incluyendo bóvedas SOL envueltas, mediante un viaje de ida y vuelta SyncNative / UnwrapLamports que deja el saldo envuelto intacto. Tres cambios de comportamiento vienen junto: 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 MINT_WHITELIST de Token-2022 de cuatro direcciones codificada se elimina para que la 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 operadores y LP mantiene sus cuentas, argumentos y matemáticas, y nada en la versión es un cambio radical: CreateConfigAccount dejó de leer su sysvar de renta final pero aún acepta la lista antigua de cinco cuentas. AmmError gana el código 60 (se numera desde 0, no desde 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 la 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: 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 de la PDA de authority de lanzamiento, para que una plataforma pueda barrer tarifas 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 la 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: límite de tasa de tarifa de plataforma elevado 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 coinciden, por lo que una plataforma creada a cualquier tasa permitida también puede actualizarse 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 permanece en 100 bps y limita solo 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 intercambio, y cada reclamación de tarifa 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 intercambio ahora se comparan contra lo que el pagador realmente paga o recibe, neto de la tarifa 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 legada 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 antiguo vinculado a AMM v4 permanece migratable. Antes de esta versión,
creator_scale producía una Clave de Tarifa propiedad del creador; las migraciones CPMM ejecutadas después de la actualización en su lugar consolidan platform_scale + creator_scale en una participación de Clave de Tarifa propiedad de la plataforma. Las plataformas también pueden restringir lanzamientos con sus propias PDAs PlatformAllowConfig, y los constructores de migración deben añadir ambas PDAs de soporte de acuñación 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 CLMM usan su grupo 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 transferirse ni cambiar de propietario pero aún puede gestionar liquidez. Su llamada ClosePosition debe añadir el grupo para que CLMM pueda descongelar, quemar y cerrar atómicamente. Las posiciones existentes permanecen sin cambios.Leer la entrada completa →CPMM: recopilación de tarifa de creador sin permisos
Una instrucción aditiva
CollectCreatorFeePermissionless permite a cualquier pagador barrer todas las tarifas de creador acumuladas, mientras limita el beneficiario y ambos destinos de token a PoolState.pool_creator y las ATAs canónicas 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: grupos con permisos múltiples y protección de cuenta congelada de orden limitado
Dos actualizaciones de programa CLMM aditivas y compatibles hacia atrás.
CreatePermissionedPool incorpora un seed_index distinto de cero suministrado por el cliente en las semillas de PDA del grupo, permitiendo a un operador en la lista blanca (uno que posea una PDA Permission) crear múltiples grupos por (config, mint0, mint1) — por lo que un ID de grupo ya no es canónico para un par. Las nuevas instrucciones de admin CreatePermissionPda / ClosePermissionPda gestionan 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, e 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 radicalmente roto (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 intercambios a los puntos de entrada V2.Leer la entrada completa →Stable AMM: eliminar código muerto de OpenBook (mercado)
Stable AMM elimina sus cuentas y código de creación de mercado 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 radicalmente roto (16 → 10, sin compatibilidad); la tarifa de referencia retirada; y una fórmula de activo de grupo simplificada solo para bóveda. La mayoría de otras instrucciones de Stable ya no son invocables.Leer la entrada completa →CLMM: órdenes limitadas, tarifa de un lado, tarifa 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), recopilación de tarifa de un lado (CollectFeeOn), y una tarifa dinámica que rastrea volatilidad. Añade CreateCustomizablePool, una reformulación de PoolState (cambio radical 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 permanece corto 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 radicales: se destacan en un cuadro de advertencia en 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-milestonesy 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 solicitud de extracción en el repositorio de documentación. Las correcciones se registran como entradas de registro de cambios.Referencias
introduction/history-and-milestones— la línea de tiempo del protocolo.security/audits— historial de auditorías.ray/protocol-fees— divisiones de tarifas de protocolo.reference/program-addresses— fuente de verdad de IDs de programa.