Claves de administrador y multisig

La superficie de autoridad en los programas de Raydium: qué puede hacer cada administrador, cómo está estructurado el multisig y cómo verificar en cadena quién tiene cada rol.

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.

El 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

Los farms individuales no tienen un administrador de protocolo: el creador de cada farm controla únicamente su farm, y sus poderes están acotados (no puede apropiarse de los stakes de los usuarios ni cambiar el mint de staking).

​

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

Los lanzamientos no tienen un administrador de protocolo que pueda cambiar las curvas o apropiarse de los fondos recaudados.

​

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.

Propiedades operativas del multisig de actualización:

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

La salida incluye:

Program Id:          CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner:               BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority:           <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes

Si 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?

1. Verifica la autoridad de actualización antes de hacer grandes asignaciones. Confirma que coincide con el multisig documentado.
2. 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.
3. 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.
4. 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

• reference/program-addresses — direcciones de autoridad canónicas.
• security/attack-vectors — cómo se manifiestan los compromisos de administrador.
• ray/treasury — direcciones del treasury y cobro de comisiones.
• security/disclosure — cómo reportar posibles problemas de administración.

Fuentes:

• Squads Protocol — interfaz del multisig.
• Documentación de Solana BPF Loader — mecanismo de actualización.