> ## 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-26 — LaunchLab: límite de tarifa de comisión de plataforma elevado a 500 bps

> El techo de fee_rate de la plataforma se eleva a 500 bps tanto en la ruta de creación como en la de actualización. CreatePlatformConfig estaba limitado a 100 bps y UpdatePlatformConfig a 250 bps; ambos ahora son 50000. Sin cambios en el diseño de cuentas, instrucciones o códigos de error.

<Info>
  **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-26-launchlab-platform-fee-rate-cap)
</Info>

<Info>
  Esta entrada cubre una próxima actualización del programa LaunchLab. Fue verificada contra la rama de lanzamiento local antes del despliegue. Confirma el programa desplegado antes de crear o actualizar una plataforma por encima de los límites anteriores.
</Info>

Este lanzamiento eleva el techo de comisión de plataforma a 500 bps. `PlatformConfig.fee_rate` se valida en dos lugares — una vez cuando `CreatePlatformConfig` construye la cuenta, y una vez en cada variante `UpdatePlatformConfig` que escribe el campo — y ambas ahora aceptan hasta `50000`. En el denominador de tarifa `1/1_000_000` del programa, eso es el 5% del volumen de operaciones en cada compra y venta previa a la graduación.

Antes de este lanzamiento, los dos controles diferían: la creación permitía 100 bps y la actualización permitía 250 bps. Ahora mantienen el mismo valor, por lo que la tarifa a la que se puede crear una plataforma es exactamente la tarifa a la que se puede actualizar.

Nada más cambió. Ninguna cuenta creció o se redujo, ninguna instrucción ganó o perdió una cuenta, y ningún código de error se movió.

## TL;DR para integradores

* **El techo de comisión de plataforma es 500 bps en ambas rutas.** `CreatePlatformConfig` y `UpdatePlatformConfig` ambas aceptan `fee_rate` hasta `50000`.
* **La creación se movió desde 100 bps.** `PlatformParams::check()` había sido `<= 10000` desde el primer lanzamiento del programa.
* **La actualización se movió desde 250 bps.** `update_platform_fee_rate` era `<= 25000`, elevado a su vez desde 100 bps el 2026-01-27.
* **La discrepancia creación/actualización desapareció.** Una configuración creada por encima de 250 bps no podría haber sobrevivido previamente a una llamada `UpdatePlatformConfig`, porque `AllInfo` revalida `fee_rate` mientras reescribe todos los demás campos. Ambos controles ahora están de acuerdo, por lo que esa ruta de edición funciona en cualquier tarifa permitida.
* **`creator_fee_rate` no cambió** en `MAX_CREATOR_FEE_RATE = 5000` (50 bps) en ambas rutas.
* **`GlobalConfig.max_share_fee_rate` no cambió** en `10_000` (100 bps), y nunca limitó la comisión de plataforma. Limita el argumento `share_fee_rate` de referencia por transacción. Las versiones anteriores de esta documentación decían lo contrario; este lanzamiento corrige eso.
* **Nada existente fue repreciado.** Estas constantes cierran escrituras a `fee_rate`, no lecturas. Cada `PlatformConfig` ya en cadena mantiene su tarifa actual, y cada lanzamiento vinculado a uno mantiene su comisión actual.
* **No se requiere actualización de IDL.** No cambiaron diseños, cuentas, argumentos o códigos de error.

## Qué cambió

```rust theme={null}
// states/platform_config.rs — PlatformParams::check(), ejecutado por CreatePlatformConfig
- require!(self.fee_rate <= 10000, ErrorCode::InvalidInput);
+ require!(self.fee_rate <= 50000, ErrorCode::InvalidInput);

// instructions/platform/update_platform_config.rs — update_platform_fee_rate
- require!(fee_rate <= 25000, ErrorCode::InvalidPlatformInfo);
+ require!(fee_rate <= 50000, ErrorCode::InvalidPlatformInfo);
```

Las tarifas en LaunchLab se denominan en `1/1_000_000` (`RATE_DENOMINATOR_VALUE`), por lo que:

| Valor   | Tarifa | Puntos base | Dónde aparece                                                                                                                                                 |
| ------- | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `10000` | 1%     | 100 bps     | Ambos techos de comisión en el primer lanzamiento del programa. También el `GlobalConfig.max_share_fee_rate` actual, que es un límite diferente e inalterado. |
| `25000` | 2.5%   | 250 bps     | El techo de actualización entre 2026-01-27 y este lanzamiento. Ya no se usa.                                                                                  |
| `50000` | 5%     | 500 bps     | Ambos techos después de este lanzamiento.                                                                                                                     |

## Dónde viven los dos controles

El techo se aplica mediante dos llamadas `require!` separadas en dos archivos. Ahora mantienen el mismo valor, pero aún generan errores diferentes, por lo que el manejo de errores necesita reconocer ambos:

| Ruta                            | Función                    | Error en violación             |
| ------------------------------- | -------------------------- | ------------------------------ |
| `CreatePlatformConfig`          | `PlatformParams::check()`  | `InvalidInput` (`6002`)        |
| `UpdatePlatformConfig::FeeRate` | `update_platform_fee_rate` | `InvalidPlatformInfo` (`6014`) |
| `UpdatePlatformConfig::AllInfo` | `update_platform_fee_rate` | `InvalidPlatformInfo` (`6014`) |

`AllInfo` es la variante de actualización masiva: reescribe las billeteras, las cadenas de marca, la escala de adquisición de derechos, la división de NFT, la autoridad de tarifa de transferencia, la tarifa del creador y `fee_rate` en una llamada, ejecutando el mismo control en `fee_rate` que la variante de campo único. Bajo las constantes antiguas, eso hacía `AllInfo` inutilizable para una plataforma creada en la banda de 250–500 bps, incluso para una edición que solo tocara una URL de imagen. Alinear las dos constantes elimina esa trampa.

## Qué no cambió

* **Contabilidad y distribución de comisiones.** `platform_fee = amount_in × platform_config.fee_rate / 1_000_000` es la misma fórmula, acumulándose en la misma bóveda por plataforma, barrida por las mismas instrucciones `ClaimPlatformFee` y `ClaimPlatformFeeFromVault`.
* **Plataformas y lanzamientos existentes.** Las constantes cierran escrituras, no lecturas. Ninguna tarifa almacenada cambió, por lo que ningún lanzamiento activo se reprecía.
* **`creator_fee_rate`.** Aún limitado a `MAX_CREATOR_FEE_RATE = 5000` (50 bps) en ambas rutas.
* **`GlobalConfig.max_share_fee_rate`.** Aún `10_000`, aún limitando solo el argumento `share_fee_rate` en las cuatro instrucciones de intercambio.
* **Códigos de error.** `6000`–`6023` no cambiaron; este lanzamiento no agrega ninguno.
* **Diseños de cuentas e IDL.** Sin cambios.

## Corrección de documentación

Dos páginas atribuyeron el techo de comisión de plataforma a `GlobalConfig.max_share_fee_rate`. El programa nunca hizo eso — compara `max_share_fee_rate` contra el argumento de instrucción `share_fee_rate`, y valida `PlatformConfig.fee_rate` solo en las dos funciones listadas arriba. Este lanzamiento corrige esas oraciones. El techo de comisión de referencia en sí no cambió en 100 bps, por lo que si leíste la redacción antigua como "la comisión de plataforma está limitada a 100 bps", el número era correcto para la ruta de creación hasta este lanzamiento aunque la razón no lo fuera.

## Páginas actualizadas

* `products/launchlab/platform-config` — nueva sección "Límites de tarifa" que cubre ambas tarifas, ambos puntos de aplicación e historial de tarifas.
* `products/launchlab/global-config` — `max_share_fee_rate` corregido para describir la comisión de referencia compartida que realmente limita.