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 multisigs 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 los ATAs canónicos de ese creador. Un llamador puede financiar ATAs faltantes y activar el barrido pero no puede redirigir las comisiones.
CLMM
Poseer un PDA
Permission permite a su autoridad llamar a CreatePermissionedPool — crear pools adicionales para un par que ya tiene uno canónico, cada uno en una dirección derivada de seed_index distinta. El permiso está limitado solo a la creación de pools: no puede mover fondos, cambiar comisiones o tocar ningún pool existente. Revocarlo (ClosePermissionPda) impide que la autoridad cree más pools pero deja los pools ya creados intactos.
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 los multisigs anteriores. Concretamente, la autoridad del mantenedor está limitada a:
SettleLimitOrder— empujar la salida completada de una orden al 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).
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 puede en el peor de los casos 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 estándar de Solana BPF Loader v3. La autoridad de actualización para todos los programas es el multisig 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 multisig 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 el multisig 3/4 solo desplegará actualizaciones bien revisadas. Ningún programa de Raydium está actualmente congelado o lo suficientemente estático 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 — el multisig 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. El multisig 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 recompensa (agregar más tokens).
- Extender el cronograma (empujar el tiempo de finalización más tarde).
- Llamar a
withdrawRewarddespués del tiempo de finalización para reclamar el saldo de bóveda no utilizado.
- Retirar LP apostado por usuario.
- Cambiar la menta de apuesta.
- Cambiar tasas de emisión retroactivamente (solo hacia adelante mediante
setRewards). - Congelar cosechas de usuario.
Configuración del multisig Squads
Raydium opera dos multisigs Squads separados para superficies de riesgo distintas. Ambos pueden ser inspeccionados en cadena a través de la interfaz de usuario del Protocolo Squads.
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 a los usuarios tiempo para responder.
- Firma de dispositivo frío aislada 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 iniciación de transacción y transmisión en cadena.
- Cola de transacciones pública. Cualquiera puede monitorear actualizaciones pendientes en la interfaz de usuario de Squads.
Verificación de autoridad en cadena
La forma más simple de verificar la autoridad de actualización actual de un programa:Authority no es la dirección del multisig Squads esperada, algo está mal. 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 decodifica:
AmmConfig no tiene un campo admin — el administrador del programa es una pubkey compilada en el programa (crate::admin::ID), y las autoridades operativas por configuración son protocolOwner / fundOwner. La autoridad de actualización de BPF es una preocupación separada a nivel de cargador; léela con solana program show.
Cambios históricos de autoridad
Consideraciones del lado del usuario
¿Qué debes hacer como usuario/LP/integrador?- Verifica la autoridad de actualización antes de asignaciones grandes. Confirma que coincida con el multisig documentado.
- Monitorea la actividad del multisig. La interfaz de usuario de Squads muestra transacciones pendientes; una actualización programada te da 24 horas para deshacer si no estás de acuerdo con el cambio.
- Estrategias de redención conscientes del timelock. Si estás ejecutando un auto-compounder, asegúrate de que tu ruta de deshacer no requiera una instrucción que esté siendo cambiada.
- No asumas inmutabilidad del programa. Cada programa de Raydium puede ser actualizado; planifica para ello.
Trampas para integradores
1. Almacenamiento en caché de direcciones de autoridad
Si codificas la autoridad de actualización o la dirección del multisig de administrador en tu código y luego rota, tu verificación falla. Obtén dereference/program-addresses en tiempo de ejecución o actualiza periódicamente.
2. Asumir que AmmConfigs son estables
Un nuevo AmmConfig puede ser creado en cualquier momento. Tu agregador/enrutador debe volver a obtener la lista de configuración completa periódicamente (cada hora está bien).3. Vectores de pesar del creador de farm
Si estás depositando en un farm de baja reputación, el creador podría terminar el farm temprano y reclamar la bóveda de recompensa (asumiendo que ningún usuario ha apostado aún). Una vez que los usuarios han apostado, los derechos pro-rata se aplican por el programa; la reclamación solo obtiene lo que queda después del final racional.Punteros
reference/program-addresses— direcciones de autoridad canónicas.security/attack-vectors— cómo se manifiestan los compromisos de administrador.ray/treasury— direcciones de tesorería y recopilación de comisiones.security/disclosure— reportar problemas sospechosos de administrador.
- Protocolo Squads — interfaz de usuario de multisig.
- Documentos de programa y cargador de Solana — el mecanismo de actualización y cómo revocar la autoridad de actualización hace un programa inmutable.