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 registro de actualizaciones de estas páginas desde el lanzamiento del proyecto en adelante. 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: lanzamientos solo CPMM y controles de configuración de plataforma
La nueva inicialización de lanzamiento ahora requiere CPMM mientras el estado heredado vinculado a AMM v4 sigue siendo migratable. Antes de esta versión,
creator_scale producía una Fee Key propiedad del creador; las migraciones CPMM ejecutadas después de la actualización consolidan platform_scale + creator_scale en una única Fee Key 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 soporte-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 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 emisores restringidos. 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 a cualquier pagador barrer 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 el creador permanece sin cambios. CreatePermissionPda también acepta una autoridad de concesión dedicada, mientras que ClosePermissionPda sigue siendo solo para administrador.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 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 eliminadas 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 cuentas en cadena y códigos de error permanecen estables; migra los swaps a los puntos de entrada V2.Leer la entrada completa →Stable AMM: eliminar código OpenBook (mercado) muerto
Stable AMM elimina sus cuentas de creación de mercado OpenBook de larga data y código. Diseños más pequeños de
SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12), y Withdraw (21/22 → 12) (los diseños antiguos siguen siendo compatibles); un cambio que rompe la compatibilidad de WithdrawPnl (16 → 10, sin compatibilidad); la tarifa de referencia retirada; y una fórmula de activos 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 de liquidación
limit_order_admin), recopilación de tarifa de un lado (CollectFeeOn), y una tarifa dinámica que rastrea volatilidad. Agrega CreateCustomizablePool, un cambio de forma 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 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 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 se mantiene corto y cada entrada es independientemente enlazable. - Fecha de verificación: cada entrada registra cuándo se verificó por última vez el contenido 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 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-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.Enlaces útiles
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.