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, limita el propietario del destinatario a PoolState.pool_creator y limita ambos destinos a los ATA canónicos de ese creador. Un llamador puede financiar ATA faltantes y activar el barrido pero no puede redirigir las comisiones.
CLMM
Poseer un PDA
Permission permite que su autoridad llame 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 se limita 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 las multifirmas anteriores. Concretamente, la autoridad del mantenedor se limita 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 recuperar la 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 se auto-restringe: limita qué cuentas
GlobalConfig pueden usar los lanzamientos bajo esa plataforma. 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 desviaciones 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 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. La ranura desplegada por última vez para cada programa es pública; léela antes de asumir que alguno de ellos está inactivo:
(De la cuenta
ProgramData de cada programa; solana program show <PROGRAM_ID> reporta la misma ranura.)
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 espaciamientos 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
withdrawRewarddespués de la hora de finalización para recuperar el saldo de bóveda no utilizado.
- Retirar LP apostado por el usuario.
- Cambiar la menta de apuesta.
- Cambiar tasas de emisión retroactivamente (solo hacia adelante mediante
setRewards). - Congelar cosechas de usuario.
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 operativas 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 auto-invalidan.
- Cumplimiento 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.
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 de multifirma 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 la multifirma documentada.
- Monitorea la actividad de multifirma. 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 bloqueo de tiempo. 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 de multifirma 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 pena del creador de farm
Si estás depositando en un farm de baja reputación, el creador podría terminar el farm temprano y recuperar la bóveda de recompensas (asumiendo que ningún usuario haya apostado aún). Una vez que los usuarios han apostado, los derechos pro-rata se aplican por el programa; la recuperación solo obtiene lo que queda después del final racional.Referencias
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 multifirma.
- 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.