> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 2026-08-31 — 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.curve_params a cuentas PlatformCurveRule por configuración con restricciones (campo, operador, valor), bandas de valor, grupos de verificación con OR, y una cartera de gestor delegado. PlatformConfig mantiene su tamaño de 944 bytes; el campo heredado y sus dos instrucciones se eliminan, y se añaden siete códigos de error.
**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 →](/reference/changelog/2026-08-31-launchlab-platform-curve-rules)
Esta entrada cubre una actualización próxima del programa LaunchLab. Se verificó contra la rama de lanzamiento local antes del despliegue. Confirma el programa desplegado antes de depender de las nuevas cuentas o instrucciones.
Una plataforma ya podía restringir qué formas de lanzamiento pueden elegir sus creadores, a través de `PlatformConfig.curve_params`. Ese mecanismo probaba **solo igualdad exacta**: una entrada fijaba un campo a un valor o lo comodín con un centinela. También contenía como máximo 10 entradas en cada `GlobalConfig` que una plataforma soportaba, y vivía en la propia cuenta `PlatformConfig`, aumentándola en 491 bytes por entrada.
Esas tres propiedades colisionaron cuando el protocolo añadió configuraciones. Expresar "un objetivo de recaudación entre 50 y 200 SOL" requería una entrada por cada valor permitido y era por lo tanto imposible. Los propios pisos de `GlobalConfig` habían sido abiertos de par en par —tasas de 1 bps, límites de suministro de 99999— precisamente para que cada plataforma quepa bajo ellos, lo que dejaba a las plataformas sin forma de reducirlos.
Este lanzamiento reemplaza la lista blanca con **reglas de curva**: una cuenta `PlatformCurveRule` por par (plataforma, configuración), conteniendo hasta 10 grupos de verificación, cada uno conteniendo hasta 25 restricciones `(campo, operador, valor)` sobre 19 parámetros de lanzamiento, con `Eq`, `Gte`, `Lte`, y `Neq`. Las restricciones dentro de un grupo se combinan con AND, los grupos con OR. Un rango es un `Gte` más un `Lte` en el mismo campo.
El modelo completo y nueve guías prácticas están en la nueva página: [`products/launchlab/curve-rules`](/es/products/launchlab/curve-rules).
## Resumen ejecutivo para integradores
* **`PlatformConfig` mantiene su tamaño y cada desplazamiento de campo existente.** Es de 944 bytes fijos. `curve_params` se ha ido; `restrict_curve_param` (`u8`), `curve_rule_manager` (`Pubkey`), y los 4 bytes que ocupaba el prefijo de longitud del vec salen del relleno, que se reduce de 107 a 78.
* **Los decodificadores deben descartar el vec final.** Un decodificador que aún espera `Vec` después del relleno leerá los dos nuevos campos como bytes de vec. Todo antes del relleno no se ve afectado, así que un decodificador que solo lee carteras de comisiones y tasas sigue funcionando sin cambios.
* **Los constructores de lanzamiento necesitan una cuenta más cuando la bandera está activada.** Mientras `restrict_curve_param` sea `1`, `InitializeV2` e `InitializeWithToken2022` requieren el PDA de regla en `remaining_accounts` — *incluso cuando la cuenta no existe*, para que omitirla no pueda saltarse la verificación. Derivación: `[b"platform_curve_rule", platform_config, global_config]`.
* **Ninguna plataforma está restringida por defecto.** `restrict_curve_param` es `0` en cada cuenta existente, y `0` significa que el programa no lee reglas en absoluto.
* **Dos instrucciones se eliminan:** `UpdatePlatformCurveParam` y `RemovePlatformCurveParam`. Se añaden cuatro: `CreatePlatformCurveRule`, `UpdatePlatformCurveRule`, `RemovePlatformCurveRule`, `ClosePlatformCurveRule`.
* **`UpdatePlatformConfig` gana dos variantes:** `RestrictCurveParam(u64)` en índice de envío 13 y `CurveRuleManager(Pubkey)` en 14. Los índices existentes 0–12 no cambian.
* **Se añaden siete códigos de error,** `6024`–`6030`. `6020` `CurveParamIsNotExist` se retiene como marcador de posición aunque su último llamador se haya ido, así que nada después se desplaza. Ver [`reference/error-codes`](/es/reference/error-codes).
* **Se requiere una actualización de IDL.** Nuevo tipo de cuenta, cuatro nuevas instrucciones, dos eliminadas, dos nuevas variantes de envío, siete nuevos códigos de error.
* **Verifica las reglas fuera de cadena antes de enviar nada.** El SDK expone `checkLaunchAgainstCurveRule` (refleja la verificación en tiempo de lanzamiento, comportamiento de fallo cerrado incluido) y `checkCurveRuleGroupWritable` (refleja la validación en tiempo de escritura). Ambas son funciones puras. Ver [Verifica antes de enviar](/es/products/launchlab/curve-rules#check-before-you-send).
* **Ensaya en devnet antes de habilitar en mainnet.** Activar `restrict_curve_param` cambia lo que tus creadores pueden hacer inmediatamente. La secuencia recomendada — incluyendo lanzar un token que debería ser rechazado, para probar que tu constructor realmente pasa la cuenta de regla — está en [Prueba en devnet primero](/es/products/launchlab/curve-rules#test-on-devnet-first).
## Lo que una regla puede expresar que la lista blanca no podía
| Intención | Lista blanca | Regla de curva |
| ----------------------------------------------------------------- | --------------------------- | --------------------------------------------------- |
| Una forma de lanzamiento exacta | Una entrada | Un grupo con restricciones `Eq` |
| Un objetivo de recaudación en un rango | No expresable | Dos restricciones: `Gte` + `Lte` |
| Tres niveles de lanzamiento | Tres entradas, solo exactas | Tres grupos |
| Una banda de valuación de graduación independiente del suministro | No expresable | Dos restricciones en el `FundRaisingRateB` derivado |
| Un piso en lo que llega al pool graduado | No expresable | Una restricción en el `MigrateRateA` derivado |
| Solo SPL Token, o solo Token-2022 | No expresable | Una restricción en `BaseTokenProgram` |
| "Si se establece una comisión de transferencia, límitala al 1%" | No expresable | Dos grupos, controlados por `TransferFeeEnabled` |
| Una regla que se activa en una fecha, sin supervisión | No expresable | Dos grupos, controlados por `UnixTimestamp` |
Los 19 campos incluyen las cuatro tasas derivadas — `SellRateA`, `LockRate`, `MigrateRateA`, `FundRaisingRateB` — lo que hace que una regla sea portátil entre suministros en lugar de fijada a uno.
## Gestión delegada
`PlatformConfig.curve_rule_manager` es una cartera activa que puede crear, actualizar, eliminar y cerrar las cuentas de regla de esta plataforma. Editar reglas es rutinario y una clave de administrador de plataforma suele ser un multifirma; este es el campo que mantiene el multifirma fuera del bucle. Establécelo una vez a través de `UpdatePlatformConfig::CurveRuleManager`.
El administrador de la plataforma retiene el mismo poder en paralelo — el programa lo acepta re-derivando el PDA `PlatformConfig` del firmante — así que una clave de gestor perdida es recuperable rotando el campo. `Pubkey::default()` significa solo administrador.
Una clave de gestor comprometida puede aflojar o eliminar reglas de parámetros y reclamar la renta de una cuenta de regla. No puede cambiar `restrict_curve_param`, tocar ninguna cartera de comisiones, campo de vesting, o configuración CPMM, o romper un límite de `GlobalConfig`.
## Renta y tamaño
Una cuenta de regla se crea sin grupo y se redimensiona en cada cambio, así que una plataforma paga por las reglas que realmente escribió, y eliminar un grupo reembolsa la diferencia al firmante.
| Contenido de regla | Tamaño | Renta |
| ------------------------------------ | ----------- | ------------ |
| Vacío | 150 bytes | \~0.0019 SOL |
| 1 grupo, 2 restricciones | 200 bytes | \~0.0023 SOL |
| 3 grupos, 4 restricciones cada uno | 408 bytes | \~0.0037 SOL |
| 10 grupos, 25 restricciones cada uno | 4 790 bytes | \~0.034 SOL |
Porque el tamaño es dinámico, los decodificadores deben leer la longitud real de la cuenta en lugar de asumir una constante.
## Costo de cómputo en el lanzamiento
La verificación se ejecuta en cada lanzamiento mientras está habilitada. Medida de extremo a extremo — derivación de PDA, escaneo de `remaining_accounts`, deserialización, evaluación:
| Contenido de regla | Campos directos | Campos derivados |
| ------------------------------------ | --------------- | ---------------- |
| Habilitado, sin cuenta de regla | 1 936 | — |
| 1 grupo, 2 restricciones | 2 576 | 2 926 |
| 3 grupos, 4 restricciones cada uno | 3 624 | 5 724 |
| 10 grupos, 25 restricciones cada uno | 24 344 | 68 094 |
Una restricción derivada cuesta aproximadamente 223 CU contra aproximadamente 48 para una lectura de campo directo. Incluso una regla completamente cargada se mantiene dentro de un tercio del presupuesto predeterminado de 200 000 CU por instrucción. Los grupos se evalúan hasta que uno coincida, así que el nivel más utilizado debe ir primero.
## La migración única
Las plataformas que usaban la lista blanca fueron migradas por el protocolo en un único paso, antes de que la bandera estuviera disponible para activarse. Una autoridad dedicada ejecutó una transacción por plataforma que tradujo cada entrada heredada en los grupos de verificación de la cuenta de regla de la configuración que nombró, limpió las entradas de `PlatformConfig`, y redujo esa cuenta de vuelta a 944 bytes.
La traducción preservó la semántica antigua exactamente: cada entrada se convirtió en un grupo, cada campo no centinela se convirtió en una restricción `Eq`, y una entrada todo-centinela — que coincidía con cada lanzamiento — se convirtió en un grupo sin restricciones, que también coincide con cada lanzamiento.
La migración escribió reglas pero no las habilitó. Una plataforma migrada permaneció sin restricciones hasta que estableció `restrict_curve_param` a `1` ella misma. La instrucción de migración ha sido eliminada del programa ahora que el paso está completo, junto con el campo heredado que leía.
## Lo que no cambió
* **`GlobalConfig`.** Mismo diseño, mismos límites, mismas instrucciones. Las reglas reducen esos límites y se verifican junto con ellos; nunca pueden ampliar uno.
* **Las listas de cuentas y argumentos de las instrucciones de lanzamiento.** `InitializeV2` e `InitializeWithToken2022` toman las mismas cuentas fijas y los mismos argumentos. Solo `remaining_accounts` gana una entrada, y solo mientras la bandera está activada.
* **Rutas de comercio, graduación, comisión y vesting.** Sin cambios.
* **`PlatformAllowConfig`.** Sin cambios y no relacionado: decide *qué configuraciones* pueden usar los lanzamientos de una plataforma, mientras que una regla decide *qué parámetros* dentro de una configuración. Las dos banderas son independientes.
* **Códigos de error `6000`–`6023`.** Sin cambios, `6020` incluido.
* **Tamaño de `PlatformConfig` y desplazamientos previos al relleno.** Sin cambios, así que las cuentas existentes no necesitan migración propia.
## Páginas actualizadas
* `products/launchlab/curve-rules` — **página nueva.** El modelo de tres niveles, las tablas de 19 campos y 4 operadores, nueve guías prácticas, la restricción de tipo de curva, los dos ayudantes de verificación fuera de cadena, la secuencia de ensayo en devnet, gestión delegada, renta, orden de despliegue, y costo de cómputo.
* `products/launchlab/platform-config` — "Lista blanca de parámetros de curva" reemplazada por "Reglas de parámetros de lanzamiento"; diseño actualizado para `restrict_curve_param`, `curve_rule_manager`, y el relleno de 78 bytes; tabla de ruta de actualización, fragmento de ruta de lectura, y trampas reescritas.
* `products/launchlab/instructions` — nueva sección "Reglas de parámetros de lanzamiento de plataforma" cubriendo las cuatro instrucciones, sus cuentas, argumentos, y errores; fila de inventario reemplazada.
* `products/launchlab/accounts` — `PlatformCurveRule` añadido al inventario y dado su propia sección con el diseño completo y la advertencia de tamaño variable.
* `reference/error-codes` — `6024`–`6030` documentados; `6018` y `6020` anotados.