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.
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 → Cada programa de Raydium tiene al menos un rol con privilegios: una clave que puede actualizar el programa, crear nuevas configuraciones o retirar comisiones del protocolo. Minimizar lo que estos roles pueden hacer (y protegerlos detrás de multisigs con tiempos de espera) es la defensa principal contra un administrador comprometido. Esta página cataloga los roles y cómo están protegidos en la práctica.
Roles por programa
AMM v4
| Rol | Dirección de autoridad | Qué puede hacer |
|---|
| Actualización del programa | Squads multisig (3/4) | Desplegar nuevo bytecode del programa |
| Pool admin | Treasury multisig (3/5) | Alternar el estado del pool, actualizar comisiones en pools existentes |
CPMM
| Rol | Dirección de autoridad | Qué puede hacer |
|---|
| Actualización del programa | Squads multisig (3/4) | Desplegar nuevo bytecode del programa |
| AmmConfig admin | Treasury multisig (3/5) | Crear nuevos AmmConfigs (niveles de comisión); alternar los existentes |
| Destinatario de la comisión de creación de pool | Treasury multisig (3/5) | Recibir la comisión única de creación de pool |
CLMM
| Rol | Dirección de autoridad | Qué puede hacer |
|---|
| Actualización del programa | Squads multisig (3/4) | Desplegar nuevo bytecode del programa |
| AmmConfig admin | Treasury multisig (3/5) | Crear/modificar AmmConfigs |
| DynamicFeeConfig admin | Treasury multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — calibrar los niveles de comisión dinámica a los que puede optar una llamada CreateCustomizablePool |
limit_order_admin (a nivel de programa) | Hot wallet operacional off-chain, no un multisig | Liquidar y cerrar órdenes límite en nombre de sus propietarios. La clave del keeper es una constante única a nivel de programa (con un valor distinto en mainnet y devnet), verificada mediante signer == limit_order.owner || signer == limit_order_admin::ID en SettleLimitOrder / CloseLimitOrder. El resultado siempre llega al ATA del propietario original; el keeper no puede redirigir fondos, modificar órdenes ni abrir nuevas. |
limit_order_admin es un rol operacional deliberadamente limitado. Existe para que un keeper off-chain pueda procesar órdenes completadas sin que el propietario de la orden tenga que estar en línea. La clave del keeper es hot (vive en la VM del keeper) y se rota de forma independiente a los multisigs anteriores. Concretamente, la autoridad del keeper se limita a:
SettleLimitOrder — enviar el resultado completado de una orden al ATA del propietario al precio límite de la orden.CloseLimitOrder — cerrar la cuenta de una orden completamente liquidada para recuperar el rent (el rent va al propietario de la orden).
No puede llamar a OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mutar ningún campo del pool ni firmar ninguna otra instrucción; estas restricciones se aplican en cadena mediante las restricciones de seed y has_one en el struct Accounts de la instrucción. En el peor caso, un keeper comprometido puede quedar inaccesible (las órdenes permanecen pendientes hasta que el propietario las liquide él mismo) o liquidar/cerrar órdenes válidamente completables fuera de orden; no puede mover fondos de usuario a ningún lugar distinto del que el propietario ya autorizó.
Farm v6
| Rol | Dirección de autoridad | Qué puede hacer |
|---|
| Actualización del programa | Squads multisig (3/4) | Desplegar nuevo bytecode del programa |
| Creador de farm (por farm) | La wallet del creador del farm | Financiar los vaults de recompensa, extender calendarios, recuperar recompensas no utilizadas |
LaunchLab
| Rol | Dirección de autoridad | Qué puede hacer |
|---|
| Actualización del programa | Squads multisig (3/4) | Desplegar nuevo bytecode del programa |
| Creador del lanzamiento (por lanzamiento) | La wallet del creador del lanzamiento | Cobrar comisiones del creador tras la graduación; retirar el remanente de la curva no graduada |
Autoridad de actualización del programa
Los programas de Raydium utilizan el mecanismo de actualización estándar de Solana BPF Loader v3. La autoridad de actualización de todos los programas es el Squads multisig 3/4.
¿Por qué 3/4? Suficientes firmantes para que un único compromiso no sea suficiente, pero pocos como para que coordinar una actualización legítima sea viable. Las cuatro autoridades son firmantes independientes en dispositivos cold air-gapped, en manos de miembros del equipo central. La firma secuencial impide aprobaciones paralelas sobre la misma transacción; las transacciones llevan una ventana de expiración fija. Las operaciones del multisig se revisan periódicamente en colaboración con el Programa STRIDE de Solana (Asymmetric Research).
Eliminar la autoridad de actualización
Raydium no ha establecido la autoridad de actualización de ningún programa como nula. El protocolo opera bajo el principio de que los programas deben ser actualizables (para corregir errores, añadir extensiones como Token-2022 o resolver incompatibilidades de integración). La contrapartida: los usuarios confían en que el multisig 3/4 solo desplegará actualizaciones bien revisadas.
Para usuarios que prefieran una alternativa inmutable, el antiguo programa AMM v4 ha sido estable desde su última auditoría; sin ninguna actualización en 18 meses. Esa ruta de código está efectivamente congelada aunque la autoridad siga existiendo.
Autoridad de AmmConfig
La creación de cada nuevo AmmConfig requiere permiso: el treasury multisig 3/5 autoriza nuevos niveles de comisión y espaciados de tick. Los pools existentes referencian su AmmConfig por PDA; el nivel de comisión del pool es el que indica el AmmConfig.
¿Pueden los administradores cambiar un AmmConfig existente? Sí, técnicamente. updateAmmConfig puede ser llamado por el administrador. En la práctica, se evitan las modificaciones a AmmConfigs ya desplegados porque cambian silenciosamente la economía de todos los pools que usan esa configuración. La política del protocolo es crear un nuevo AmmConfig para cualquier cambio y migrar.
¿Pueden los administradores robar comisiones del protocolo mediante la configuración? No: el AmmConfig contiene parámetros de comisión, pero no el destinatario de la comisión del protocolo; esa es una dirección inmutable separada por pool.
Cobro de comisiones del protocolo
Una parte de las comisiones de swap (típicamente entre 3 y 12 bps de los 25 bps de comisión de swap, según la configuración) se acumula en un vault de comisiones del protocolo. El multisig puede retirar estas comisiones acumuladas. Los usuarios nunca ven que su saldo LP cambia por esto: es la parte preasignada del protocolo, no el dinero de los LP.
Autoridad del creador de farm
Los Farms v6 otorgan al creador la capacidad de:
- Financiar el vault de recompensas (añadir más tokens).
- Extender el calendario (retrasar la fecha de finalización).
- Llamar a
withdrawReward tras la fecha de finalización para recuperar el saldo no utilizado del vault.
Los creadores de farms no pueden:
- Retirar el LP en stake de los usuarios.
- Cambiar el mint de staking.
- Cambiar las tasas de emisión de forma retroactiva (solo hacia adelante mediante
setRewards).
- Bloquear las recompensas de los usuarios.
En el peor caso, un creador de farm malicioso puede financiar insuficientemente el vault para que el farm se quede sin fondos; el stake principal de los usuarios siempre está seguro.
Configuración del Squads multisig
Raydium opera dos Squads multisig separados para distintas superficies de riesgo. Ambos pueden inspeccionarse en cadena a través de la interfaz de Squads Protocol.
| Multisig | Umbral | Timelock | Alcance |
|---|
| Actualización de programa | 3/4 | 24 horas | Única autoridad para desplegar nuevo bytecode de programa para AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap y los programas legacy de Farm/Staking. Ver en app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | ninguno | Activos del treasury, ingresos del protocolo, gastos operativos. También tiene la autoridad de administrador de programa limitada de Raydium (creación de AmmConfigs, cobro de comisiones del protocolo, configuración de parámetros de pool) de forma provisional. Ver en v3.squads.so/dashboard/RVha…dHdtYz09. |
- Timelock de 24 horas en cualquier transacción. Una actualización aprobada hoy se ejecuta no antes de 24 horas después, dando tiempo a los usuarios para reaccionar.
- Firma en dispositivos cold air-gapped. Los dispositivos cold tienen las tarjetas de red físicamente extraídas; se conectan únicamente a un hardware wallet y leen los datos de la transacción mediante código QR desde un dispositivo hot separado.
- Firma secuencial. Solo después de que un dispositivo cold genera y firma una transacción puede el siguiente dispositivo cold comenzar su proceso de firma, evitando firmas conflictivas o paralelas sobre la misma transacción.
- Expiración de transacciones. Cada transacción lleva una ventana de expiración fija, por lo que las transacciones obsoletas se invalidan automáticamente.
- TOTP + verificación con llave física en los dispositivos hot utilizados para iniciar transacciones y difundirlas en cadena.
- Cola de transacciones pública. Cualquiera puede monitorear las actualizaciones pendientes en la interfaz de Squads.
El treasury multisig no tiene timelock: su alcance es más reducido y las operaciones rutinarias (crear AmmConfigs, cobrar comisiones) deben ejecutarse el mismo día. El treasury multisig también tiene la autoridad de administrador de programa limitada indicada en las tablas por programa; es un arreglo provisional que se revisa periódicamente con los socios de seguridad del proyecto.
Verificar la autoridad en cadena
La forma más sencilla de verificar la autoridad de actualización actual de un programa:
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority no es la dirección del Squads multisig esperada, algo está mal. Raydium publica las direcciones de autoridad esperadas en reference/program-addresses.
Para los roles de AmmConfig / pool admin, obtén la cuenta en cadena y decodifica:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Expected: 3/5 treasury multisig.
Historial de cambios de autoridad
| Fecha | Programa | Cambio |
|---|
| 2022-12 | AMM v4 | Autoridad de actualización migrada de single-sig a multisig 3/4 tras un incidente |
| 2023-02 | Todos los programas | Todos los roles operativos unificados bajo el treasury multisig 3/5 |
| 2023-11 | CLMM | Se añadió un segundo multisig para operaciones solo de recompensas para reducir la exposición |
| 2024-05 | CPMM | Despliegue inicial con autoridad multisig desde el primer día |
Consideraciones para el usuario
¿Qué deberías hacer como usuario, LP o integrador?
- Verifica la autoridad de actualización antes de hacer grandes asignaciones. Confirma que coincide con el multisig documentado.
- Monitorea la actividad del multisig. La interfaz de Squads muestra las transacciones pendientes; una actualización programada te da 24 horas para deshacer posiciones si no estás de acuerdo con el cambio.
- Estrategias de redención conscientes del timelock. Si gestionas un auto-compounder, asegúrate de que tu ruta de salida no requiera una instrucción que esté siendo modificada.
- No asumas que los programas son inmutables. Todos los programas de Raydium pueden actualizarse; tenlo en cuenta.
Errores comunes para integradores
1. Cachear direcciones de autoridad
Si hardcodeas la autoridad de actualización o la dirección del multisig administrador en tu código y esta cambia más adelante, tu verificación fallará. Obtén los datos de reference/program-addresses en tiempo de ejecución o refresca periódicamente.
2. Asumir que los AmmConfigs son estables
Se puede crear un nuevo AmmConfig en cualquier momento. Tu agregador/router debería volver a obtener la lista completa de configuraciones periódicamente (cada hora es suficiente).
3. Vectores de abuso del creador de farm
Si depositas en un farm de poca reputación, el creador podría terminar el farm anticipadamente y recuperar el vault de recompensas (siempre que ningún usuario haya hecho stake todavía). Una vez que los usuarios han hecho stake, los derechos prorrateados son aplicados por el programa; la recuperación solo obtiene el remanente tras una finalización razonable.
Referencias
Fuentes:
