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

​
LaunchLab: las reglas de curva de plataforma reemplazan la lista blanca de parámetros de curva
Las restricciones de parámetros de lanzamiento se trasladan de PlatformConfig a cuentas PlatformCurveRule por configuración. Una regla contiene hasta 10 grupos de verificación con hasta 25 restricciones (field, op, value) sobre 19 parámetros de lanzamiento, con Eq / Gte / Lte / Neq — permitiendo que una plataforma exprese una banda de valores, niveles alternativos, un límite de valuación de graduación, un piso de migración, restricción por tipo de token, o un grupo que cambia en una fecha, ninguno de los cuales la lista blanca de solo igualdad podía hacer. PlatformConfig mantiene su tamaño de 944 bytes: restrict_curve_param, curve_rule_manager, y el prefijo de longitud del vec removido salen del relleno. Los decodificadores deben eliminar el Vec<PlatformCurveParam> final, y los constructores de lanzamiento deben agregar el PDA de regla a remaining_accounts mientras la bandera esté activa. Se removieron dos instrucciones, se agregaron cuatro, se agregaron dos variantes de UpdatePlatformConfig, se agregaron 6024–6030. Se requiere actualización de IDL. El SDK incluye 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 de 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, permitiendo que una plataforma recaude 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 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 deja silenciosamente las dos autoridades en claves diferentes. No cambió ningún diseño de cuenta, instrucción, argumento, o código de error.Leer la entrada completa →
​
LaunchLab: límite de tasa de tarifa 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 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 creación, InvalidPlatformInfo en actualización). No cambió ningún diseño de cuenta, instrucción, o código de error, y ninguna plataforma o lanzamiento existente cambia de precio. 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 cotizarse en un mint Token-2022. CreateConfig, InitializeV2, InitializeWithToken2022, las cuatro instrucciones de swap, y cada reclamación de tarifa aceptan cualquiera de los dos programas 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 tarifa 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 legado 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 vinculado a AMM v4 legado 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 propios PDAs PlatformAllowConfig, y los constructores de migración deben agregar ambos PDAs de mint de soporte CPMM.Leer la entrada completa →
​
CLMM: congelación de NFT de posición de emisor restringido
Los nuevos mints de NFT de posición 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 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 agregar el pool 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 que cualquier pagador recaude todas las tarifas 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 creador permanece sin cambios. CreatePermissionPda también acepta una autoridad de concesión dedicada, mientras que ClosePermissionPda permanece solo para administrador.Leer la entrada completa →
​
CLMM: múltiples pools con permisos y protección de cuenta congelada de orden limitada
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 administrador 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 removidas ahora se ignoran, no se validan); un WithdrawPnl que rompe la compatibilidad (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 →
​
Stable AMM: eliminar código OpenBook (mercado) muerto
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 que rompe la compatibilidad (16 → 10, sin compatibilidad); la tarifa de referencia retirada; y una fórmula de activo de pool 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 liquidador limit_order_admin), recopilación de tarifa de un lado (CollectFeeOn), y una tarifa dinámica que rastrea volatilidad. Agrega CreateCustomizablePool, un remodelar de PoolState (cambio que rompe 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 agrega 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 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 que rompen compatibilidad: se destacan en una advertencia recuadrada 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-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 solicitud de extracción en el repositorio de documentación. Las correcciones se registran como entradas de registro de cambios.

​
Enlaces útiles