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 →
PlatformConfig es la superposición a nivel de plataforma que se sitúa encima de GlobalConfig. Mientras que GlobalConfig define las reglas de todo el protocolo («la comisión de intercambio es del 1%, el suministro debe ser al menos 10M, solo esta billetera puede graduarse»), PlatformConfig es lo que cada plataforma de lanzamiento — pump.fun, la propia interfaz de Raydium, launchpads de terceros — utiliza para añadir su comisión, reclamar su parte del LP posterior a la graduación, restringir qué parámetros de lanzamiento pueden elegir sus lanzamientos y mostrar su marca (nombre, sitio web, imagen) en cadena.

Qué es

Una cuenta PlatformConfig gestiona cinco aspectos transversales para una plataforma:
  1. Marca — nombre, sitio web, enlace de imagen, todo almacenado en línea para que cualquier explorador o agregador pueda mostrar la plataforma que lanzó un token.
  2. Comisión de plataforma — una comisión de intercambio adicional (fee_rate) además de la trade_fee_rate del protocolo. Se acumula en la platform_fee_wallet de la plataforma. Limitada a 500 bps (50000) tanto en la ruta de creación como de actualización, aumentada desde 100 bps (10000) el 2026-08-26 — ver Límites de tasas.
  3. División de migración de LP — tres enteros almacenados (platform_scale, creator_scale, burn_scale) que suman 1_000_000. Antes de la actualización del 2026-08-17, la escala del creador producía una Fee Key de creador separada. Las migraciones ejecutadas después de la actualización combinan los dos primeros en una participación de LP bloqueada propiedad de la plataforma; el resto se quema.
  4. Reglas de parámetros de lanzamiento — una restricción opcional (restrict_curve_param) que requiere que un lanzamiento satisfaga la cuenta PlatformCurveRule del GlobalConfig que seleccionó. Las reglas admiten bandas de valores, niveles alternativos y restricciones por tipo de token; viven en sus propias cuentas, no en PlatformConfig.
  5. Lista de permitidos de configuración global — una restricción opcional que requiere un PlatformAllowConfig creado por la plataforma para el GlobalConfig seleccionado.
Derivación de PDA:
(Ver create_platform_config en el código fuente para la lista de semillas canónica.)

Diseño

La cuenta tiene un tamaño fijo de 944 bytes. Contenía un Vec<PlatformCurveParam> al final hasta la versión del 2026-08-31 que movió los parámetros de lanzamiento a cuentas PlatformCurveRule; restrict_curve_param, curve_rule_manager y los 4 bytes que ocupaba el prefijo de longitud del vec salen del padding, por lo que el recuento de bytes y todos los desplazamientos de campos anteriores no cambian. Ver la entrada del registro de cambios para saber qué deben cambiar los decodificadores. platform_scale + creator_scale + burn_scale debe ser igual a 1_000_000. Antes de la actualización del 2026-08-17, creator_scale se bloqueaba por separado y su Fee Key iba al creador del token. Para migraciones ejecutadas después de la actualización, se suma a platform_scale y sus derechos de LP bloqueado van a la plataforma en su lugar. Ejemplos de resultados bajo la lógica actualizada:
  • (0, 100_000, 900_000) — 90% LP quemado, 10% bloqueado para la plataforma.
  • (50_000, 100_000, 850_000) — 85% quemado, 15% bloqueado para la plataforma.
  • (0, 0, 1_000_000) — quema completa, sin acuñación de NFT. Lanzamientos estrictos «sin insiders».

Campos de marca

name, web e img son matrices de bytes en línea rellenadas con ceros hasta sus constantes de tamaño. Para leerlas como cadenas, corta hasta el primer \0:
Las constantes son deliberadamente generosas (name: 64, web: 256, img: 256) para que las plataformas puedan incluir suficientes metadatos para exploradores y agregadores sin tocar almacenamiento fuera de cadena. Cualquier cosa que exceda estos tamaños revierte en CreatePlatformConfig con InvalidInput.

Mecánica de comisiones

Un intercambio en una curva vinculada a un PlatformConfig cobra tres comisiones en capas:
  • trade_fee se acumula en el protocol_fee_owner del protocolo (reclamado vía CollectFee).
  • platform_fee se acumula en una bóveda por plataforma (reclamado vía ClaimPlatformFee o ClaimPlatformFeeFromVault; ver instructions).
  • creator_fee se acumula en una bóveda por creador con clave de la pubkey del creador + mint de cotización (reclamado vía ClaimCreatorFee).

Límites de tasas

Ambas tasas se denominan en 1/1_000_000, por lo que 5000 es 50 bps y 50000 es 500 bps. Los dos puntos de aplicación para fee_rate son llamadas require! separadas en archivos diferentes, por lo que llevan códigos de error diferentes, pero aplican el mismo límite. Una plataforma creada a cualquier tasa permitida puede editarse más tarde, incluso a través de la variante AllInfo en lote que reescribe cada campo a la vez. Ambos límites de fee_rate eran originalmente 100 bps (10000). El límite de actualización pasó a 25000 (250 bps) el 2026-01-27; el 2026-08-26 ambos pasaron a 50000 (500 bps) — ver la entrada del registro de cambios. GlobalConfig.max_share_fee_rate no limita ninguna de las dos tasas. Limita el argumento share_fee_rate por transacción que toman las cuatro instrucciones de intercambio — la comisión de referencia — y nada más. Ver global-config.

Autoridades de comisión de transferencia de Token-2022

transfer_fee_extension_auth nombra la clave de plataforma que termina teniendo las autoridades TransferFeeConfig del mint base cuando se crea un lanzamiento a través de InitializeWithToken2022 con una comisión de transferencia adjunta. La extensión lleva dos autoridades, y se entregan en diferentes puntos del ciclo de vida del lanzamiento: Antes del 2026-08-27 el mint se creaba con la PDA de authority en ambas autoridades, y ambas se movían a la plataforma en la graduación. El programa no expone ninguna instrucción de retiro de retención o cosecha, por lo que las comisiones retenidas durante la fase de curva de vinculación eran inaccesibles hasta que el lanzamiento se graduaba. Escribir el lado de retiro en la creación de mint las hace reclamables desde el primer intercambio — ver la entrada del registro de cambios. Dos consecuencias que vale la pena planificar:
  • Establece el campo antes de lanzar, no después. Un lanzamiento creado mientras transfer_fee_extension_auth es Pubkey::default() pone la PDA de authority en el lado de retiro. Establecer el campo más tarde aún funciona — la graduación encuentra la PDA en su lugar y entrega la autoridad — pero nada puede retirar el saldo retenido mientras tanto.
  • Rotar el campo a mitad del lanzamiento divide las dos autoridades. Cambia transfer_fee_extension_auth entre la creación y graduación de un lanzamiento y la autoridad de retiro de retención del mint se queda con la clave configurada en la creación (la PDA ya no la tiene, por lo que la migración omite esa entrega) mientras que la autoridad de configuración de comisión va a la nueva clave. Rota entre lanzamientos, o planifica reconciliar las dos claves tú mismo a través de Token-2022 directamente.
Una plataforma que deja el campo en Pubkey::default() durante toda la vida de un lanzamiento mantiene ambas autoridades en la PDA de authority permanentemente: la tasa de comisión nunca puede cambiar y el saldo retenido nunca puede retirarse. Solo adjunta una comisión de transferencia a un lanzamiento si la plataforma tiene la intención de mantener estas claves.

División de migración de NFT (solo CPMM)

Cuando un lanzamiento se gradúa a CPMM, la instrucción de migración divide los tokens LP acuñados por CPMM::InitializeWithPermission de dos maneras:
Si lp_to_platform es distinto de cero, el programa LP-Lock lo envuelve en un NFT de Fee Key propiedad de platform_nft_wallet. Esto reemplaza el comportamiento anterior a la actualización que creaba Fee Keys de plataforma y creador separadas. Las Fee Keys creadas por migraciones completadas antes de la actualización permanecen sin cambios. Este derecho de comisión de LP es separado de las comisiones de creador de CPMM controladas por platform_cp_creator. La porción de quema se quema directamente, por lo que ninguna cuenta puede retirarla o reclamar las comisiones de LP representadas por esa participación. Los lanzamientos existentes con migrate_type = 0 almacenado aún pueden usar la ruta heredada de AMM v4. La nueva inicialización rechaza ese tipo de migración.

Reglas de parámetros de lanzamiento

restrict_curve_param es el interruptor. En 0 el programa no lee reglas en absoluto. En 1, cada lanzamiento enrutado a través de esta plataforma debe satisfacer la cuenta PlatformCurveRule del GlobalConfig que seleccionó, y el constructor de lanzamiento debe añadir esa cuenta a remaining_accounts.
Una regla es un menú de formas de lanzamiento permitidas: las restricciones dentro de un grupo de verificación se AND, los grupos se OR, y cada restricción es un triple (field, op, value) que admite Eq, Gte, Lte y Neq. Eso cubre bandas de valores, niveles alternativos, límites de valuación de graduación, pisos de migración, restricciones por tipo de token y grupos limitados en tiempo — el modelo completo, la tabla de campos y nueve guías de trabajo se encuentran en products/launchlab/curve-rules. Dos cosas pertenecen aquí en lugar de en esa página:
  • curve_rule_manager es una delegación, no una transferencia. Establécelo a través de UpdatePlatformConfig::CurveRuleManager y esa billetera puede crear, actualizar, eliminar y cerrar las cuentas de regla de esta plataforma sin la clave de administrador. El administrador de la plataforma mantiene el mismo poder en paralelo, por lo que rotar o limpiar el campo recupera el control. Pubkey::default() significa que solo el administrador puede gestionar reglas. No puede cambiar restrict_curve_param, que permanece como una llamada solo de administrador.
  • Las reglas se aplican además de GlobalConfig, nunca en lugar de él. La verificación de regla se ejecuta antes de los propios límites de la configuración y solo puede reducirlos.
Esto reemplaza la antigua lista de permitidos curve_params: Vec<PlatformCurveParam>, que solo podía probar igualdad exacta, contenía como máximo 10 entradas en todas las configuraciones y hacía crecer la propia cuenta PlatformConfig. Las plataformas que la usaban fueron migradas por el protocolo en un pase único; el campo heredado, sus dos instrucciones y MAX_CURVE_PARAMS se han ido.

PlatformAllowConfig — restricción de una plataforma

Cada plataforma decide si restringir qué cuentas GlobalConfig pueden usar sus lanzamientos. Establece restrict_global_config con UpdatePlatformConfig::RestrictGlobalConfig(0 | 1).
Semillas de PDA: [b"platform_allow_config", platform_config, global_config]. El administrador de la plataforma crea o cierra una cuenta por par permitido vía CreatePlatformAllowConfig y ClosePlatformAllowConfig. Cuando la restricción es 1, la inicialización busca en remaining_accounts la PDA esperada y rechaza una cuenta faltante con NotEnoughRemainingAccounts. Cuando la restricción es 0, no se requiere cuenta de permitidos. La antigua cuenta PlatformGlobalAccess gestionada por el administrador del protocolo y sus instrucciones de crear/cerrar se retiran. Los tamaños existentes de PlatformConfig y GlobalConfig no cambian, pero los decodificadores deben reemplazar la antigua bandera global con la nueva bandera de plataforma. Las antiguas PDAs de acceso no se consumen por la nueva verificación.

Ruta de lectura

Para una interfaz que muestre «dónde se lanzó este token», PoolState.platform_config apunta directamente a la PlatformConfig originaria — obtén la información una vez y almacena en caché la marca.

Ruta de actualización

Las rotaciones de billetera (platform_fee_wallet, platform_nft_wallet, platform_vesting_wallet, platform_cp_creator, transfer_fee_extension_auth, cpswap_config) todas van a través de UpdatePlatformConfig. Lee la tabla de despacho update_platform_config del código fuente para los códigos exactos de param.

Trampas comunes

  • restrict_curve_param habilitado antes de que se actualizara el constructor. Mientras sea 1 la PDA de regla debe estar en remaining_accounts en cada lanzamiento, incluso para una configuración sin cuenta de regla — una cuenta ausente es NotEnoughRemainingAccounts, no un pase. Envía el cambio del constructor primero, luego cambia la bandera.
  • restrict_curve_param habilitado con una regla vacía. Una regla que contiene cero grupos, o un grupo que contiene cero restricciones, permite todo. Habilitar la bandera no es por sí mismo una restricción; escribe los grupos primero, verifica con la verificación del SDK y ensaya toda la secuencia en devnet.
  • Redondeo de división de NFT. Las tres escalas deben sumar exactamente 1_000_000. Los errores de uno en CreatePlatformConfig revierten; los errores de uno en tiempo de ejecución acuñarían o quemarían una unidad de LP adicional, que es lo que la verificación de igualdad estricta está ahí para prevenir.
  • Doble asignación de vesting de plataforma. Si platform_vesting_scale > 0, la plataforma debe llamar a CreatePlatformVestingAccount una vez después de que termine la recaudación de fondos del lanzamiento; si lo olvida, esa participación permanece sin asignar e inactiva para siempre (el presupuesto total_locked_amount del lanzamiento se consume pero la plataforma nunca reclama).
  • Ambigüedad de platform_cp_creator. Cuando se establece en Pubkey::default(), el creador del lanzamiento se registra como el pool_creator del pool CPMM posterior a la graduación; cuando se establece en una clave real, esa clave se registra en su lugar. Esto determina el beneficiario de las comisiones de creador de CPMM posteriores a la graduación y quién puede firmar la ruta original de CPMM::CollectCreatorFee. La ruta de recopilación sin permisos aún paga las ATAs canónicas de la clave registrada. Decide en el momento de la creación de la configuración de plataforma qué modelo quieres.
  • transfer_fee_extension_auth establecido tarde o rotado. El campo se lee dos veces por lanzamiento de Token-2022 — una vez en la creación de mint para withdraw_withheld_authority, una vez en la graduación para transfer_fee_config_authority — por lo que un valor que cambia entre esos dos momentos deja las dos autoridades en claves diferentes. Ver Autoridades de comisión de transferencia de Token-2022.
  • Restricción sin una cuenta de permitidos. Habilitar restrict_global_config antes de crear el PlatformAllowConfig requerido bloquea nuevos lanzamientos que seleccionen esa configuración.

Punteros

Fuentes:
  • raydium-launch/programs/launchpad/src/states/platform_config.rsPlatformConfig, PlatformParams, MigrateNftInfo, is_curve_rule_manager, is_platform_admin.
  • raydium-launch/programs/launchpad/src/states/platform_curve_rule.rsPlatformCurveRule, CurveRuleGroup, ParamConstraint.
  • raydium-launch/programs/launchpad/src/states/platform_allow_config.rsPlatformAllowConfig.
  • raydium-launch/programs/launchpad/src/instructions/platform/update_platform_config.rs — despacho PlatformConfigParam y los setters por campo que aplican los límites de tasa en tiempo de actualización.
  • raydium-launch/programs/launchpad/src/lib.rs — puntos de entrada de configuración de plataforma y configuración de permitidos.
  • raydium-launch/programs/launchpad/src/instructions/initialize_with_token_2022.rs — donde transfer_fee_extension_auth se escribe en el TransferFeeConfig del nuevo mint.
  • raydium-launch/programs/launchpad/src/instructions/admin/migrate_to_cpswap.rs — la entrega de autoridad en tiempo de graduación y su guardia get_withdraw_withheld_authority.