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 →
Cada programa de Raydium tiene al menos un rol privilegiado — una clave que puede actualizar el programa, crear nuevas configuraciones o retirar comisiones de protocolo. Minimizar lo que estos roles pueden hacer (y protegerlos con multifirmas con retrasos) es la defensa principal contra un administrador comprometido. Esta página cataloga los roles y cómo están asegurados en la práctica.

Roles por programa

AMM v4

CPMM

La recopilación de comisiones del creador no introduce un rol privilegiado. CollectCreatorFeePermissionless acepta cualquier pagador, restringe el propietario del destinatario a PoolState.pool_creator y restringe ambos destinos a las ATAs canónicas de ese creador. Un llamador puede financiar ATAs faltantes y activar el barrido pero no puede redirigir las comisiones.

CLMM

Crear pools adicionales para un par en una dirección derivada de seed_index (CreateCustomizablePoolV2) no requiere ningún rol. Antes de la actualización 2026-10-22 requería un PDA de Permission emitido por una clave dedicada permission_pda_admin; ese rol, la cuenta Permission y sus dos instrucciones de administrador fueron eliminados. El limit_order_admin es un rol operativo deliberadamente estrecho. Existe para que un mantenedor fuera de cadena pueda barrer órdenes completadas sin que el propietario de la orden tenga que estar en línea. La clave del mantenedor es activa (vive en la VM del mantenedor) y se rota independientemente de las multifirmas anteriores. Concretamente, la autoridad del mantenedor está limitada a:
  • SettleLimitOrder — empujar el resultado completado de una orden a la ATA del propietario al precio límite de la orden.
  • CloseLimitOrder — cerrar la cuenta de una orden completamente liquidada para reclamar renta (la renta va al propietario de la orden).
No puede llamar a OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mutar ningún campo de pool o firmar para ninguna otra instrucción — esas verificaciones se aplican en cadena mediante las restricciones de semilla y has_one en la estructura Accounts de la instrucción. Un mantenedor comprometido en el peor de los casos puede no estar disponible (las órdenes permanecen estacionadas hasta que el propietario las liquide él mismo) o liquidar/cerrar órdenes legítimamente completables fuera de orden; no puede mover fondos de usuario a ningún lugar que no sea donde el propietario ya los autorizó.

Farm v6

Los farms individuales no tienen administrador de protocolo — cada creador de farm controla solo su farm, y los poderes del creador están limitados (no puede confiscar apuestas de usuario, no puede cambiar la menta de apuesta).

LaunchLab

La lista de permitidos del administrador de plataforma es autolimitante: limita qué cuentas GlobalConfig los lanzamientos bajo esa plataforma pueden usar. No otorga autoridad sobre otras plataformas o fondos de lanzamiento existentes. Las direcciones de autoridad delegada canónicas viven en reference/program-addresses.

Autoridad de actualización de programa

Los programas de Raydium utilizan el mecanismo de actualización estándar de Solana BPF Loader v3. La autoridad de actualización para todos los programas es la multifirma Squads 3/4. Por qué 3/4: suficientes firmantes para que un único compromiso sea insuficiente; pocos suficientes para que coordinar una actualización legítima sea manejable. Las cuatro autoridades son independientes, firmantes de dispositivos fríos aislados de la red mantenidos por miembros del equipo principal. La firma secuencial previene aprobaciones paralelas en la misma transacción; las transacciones llevan una ventana de expiración fija. Las operaciones de multifirma se revisan periódicamente en asociación con el Programa STRIDE de Solana (Asymmetric Research).

Eliminación de 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 necesitan ser actualizables (para parchar errores, agregar extensiones como Token-2022, corregir desviación de integración). Compensación: los usuarios confían en que la multifirma 3/4 solo desplegará actualizaciones bien revisadas. Ningún programa de Raydium está actualmente congelado o moviéndose lo suficientemente lentamente como para ser tratado como una alternativa inmutable — AMM v4, históricamente el más estático de ellos, fue él mismo redesplegado el 2026-07-22. El slot desplegado por última vez para cada programa es público; léelo antes de asumir que alguno de ellos está inactivo: (De la cuenta ProgramData de cada programa; solana program show <PROGRAM_ID> reporta el mismo slot.)

Autoridad de AmmConfig

Cada nueva creación de AmmConfig está permisionada — la multifirma de tesorería 3/5 autoriza nuevos niveles de comisión y espaciados de tick. Los pools existentes hacen referencia a su AmmConfig por PDA; el nivel de comisión del pool es lo que dice el AmmConfig. ¿Pueden los administradores cambiar un AmmConfig existente? Sí, técnicamente. updateAmmConfig es llamable por el administrador. En la práctica, se evitan las modificaciones a AmmConfigs desplegados porque cambia 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 de protocolo a través de la configuración? No — el AmmConfig contiene parámetros de comisión pero no el destinatario de comisión de protocolo; esa es una dirección inmutable separada por pool.

Reclamación de comisión de protocolo

Una porción de las comisiones de intercambio (típicamente 3–12 bps de 25 bps de comisión de intercambio, dependiendo de la configuración) se acumula en una bóveda de comisión de protocolo. La multifirma puede retirar estas comisiones acumuladas. Los usuarios nunca ven su saldo de LP cambiar por esto — es la parte preasignada del protocolo, no dinero de LP.

Autoridad del creador de farm

Los Farms v6 dan al creador el poder de:
  • Financiar la bóveda de recompensas (agregar más tokens).
  • Extender el cronograma (empujar la hora de finalización más tarde).
  • Llamar a withdrawReward después de la hora de finalización para reclamar el saldo de bóveda no utilizado.
Los creadores de farm no pueden:
  • Retirar LP de usuario apostado.
  • Cambiar la menta de apuesta.
  • Cambiar tasas de emisión retroactivamente (solo hacia adelante mediante setRewards).
  • Congelar cosechas de usuario.
Un creador de farm malicioso en el peor de los casos puede financiar insuficientemente la bóveda para que el farm se agote; la apuesta principal del usuario siempre está segura.

Configuración de multifirma Squads

Raydium opera dos multifirmas Squads separadas para superficies de riesgo distintas. Ambas pueden inspeccionarse en cadena a través de la interfaz de usuario del Protocolo Squads. Propiedades operacionales de la multifirma de actualización:
  • Bloqueo de tiempo de 24 horas en cualquier transacción. Una actualización aprobada hoy se ejecuta no antes de 24 horas después, dando a los usuarios tiempo para responder.
  • Firma de dispositivo frío aislado de la red. Los dispositivos fríos tienen tarjetas de red removidas físicamente; se conectan solo a una billetera de hardware y leen datos de transacción a través de código QR desde un dispositivo caliente separado.
  • Firma secuencial. Solo después de que un dispositivo frío genere y firme una transacción puede el siguiente dispositivo frío comenzar su proceso de firma — previniendo firmas conflictivas o paralelas en la misma transacción.
  • Expiración de transacción. Cada transacción lleva una ventana de expiración fija, por lo que las transacciones antiguas se invalidan automáticamente.
  • Aplicación de TOTP + clave física en los dispositivos calientes utilizados para la iniciación de transacciones y transmisión en cadena.
  • Cola de transacciones pública. Cualquiera puede monitorear actualizaciones pendientes en la interfaz de usuario de Squads.
La multifirma de tesorería no tiene bloqueo de tiempo — su alcance es más estrecho y las operaciones rutinarias (crear AmmConfigs, barrer comisiones) necesitan aterrizar el mismo día. La multifirma de tesorería también mantiene la autoridad limitada de administrador de programa listada en las tablas por programa anteriores; esto es un arreglo provisional y se revisa periódicamente con los socios de seguridad del proyecto.

Verificación de autoridad en cadena

La forma más simple de verificar la autoridad de actualización actual de un programa:
La salida incluye:
Si Authority no es la dirección multisig de Squads esperada, algo no está bien. Raydium publica las direcciones de autoridad esperadas en reference/program-addresses. Para roles de administrador de AmmConfig / pool, obtén la cuenta en cadena y decodifícala:
AmmConfig no tiene un campo admin — el administrador del programa es una clave pública compilada en el programa (crate::admin::ID), y las autoridades operacionales por configuración son protocolOwner / fundOwner. La autoridad de actualización BPF es una preocupación separada a nivel del cargador; léela con solana program show.

Cambios históricos de autoridad

Consideraciones del lado del usuario

¿Qué debes hacer como usuario/LP/integrador?
  1. Verifica la autoridad de actualización antes de asignaciones grandes. Confirma que coincida con el multisig documentado.
  2. Monitorea la actividad multisig. Squads UI muestra transacciones pendientes; una actualización programada te da 24 horas para deshacer si no estás de acuerdo con el cambio.
  3. Estrategias de redención conscientes del bloqueo de tiempo. Si ejecutas un auto-compounder, asegúrate de que tu ruta de deshacer no requiera una instrucción que esté siendo modificada.
  4. No asumas inmutabilidad del programa. Cada programa de Raydium puede ser actualizado; planifica para ello.

Trampas para integradores

1. Cachear direcciones de autoridad

Si codificas la autoridad de actualización o la dirección multisig de administrador en tu código y luego rota, tu verificación falla. Obtén de reference/program-addresses en tiempo de ejecución o actualiza periódicamente.

2. Asumir que AmmConfigs son estables

Se puede crear una nueva AmmConfig en cualquier momento. Tu agregador/enrutador debe volver a obtener la lista completa de configuración periódicamente (cada hora está bien).

3. Vectores de molestia del creador de granjas

Si depositas en una granja de baja reputación, el creador podría terminar la granja temprano y reclamar el almacén de recompensas (asumiendo que ningún usuario haya apostado aún). Una vez que los usuarios han apostado, los derechos prorrateados se aplican por el programa; el reclamo solo obtiene lo que queda después del final racional.

Referencias

Fuentes: