2026-08-31 — LaunchLab: las reglas de curva de plataforma reemplazan la lista blanca de parámetros de curva

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.

​

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<PlatformCurveParam> 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.
• 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.
• 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.

​

Lo que una regla puede expresar que la lista blanca no podía

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. 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: 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.