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, 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
Tener un PDA
Permission permite que su autoridad llame a CreatePermissionedPool — creando 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 pool: 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 keeper fuera de cadena pueda barrer órdenes completadas sin que el propietario de la orden tenga que estar en línea. La clave del keeper es activa (vive en la VM del keeper) y se rota independientemente de los multisigs anteriores. Concretamente, la autoridad del keeper se limita a:
SettleLimitOrder— empujar 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 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 seed y has_one en la estructura Accounts de la instrucción. Un keeper 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 el mint de apuesta).
LaunchLab
La lista de permitidos del administrador de plataforma se auto-restringe: 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 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 firmantes independientes 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 bugs, agregar extensiones como Token-2022, corregir desviaciones de integración). Compensación: los usuarios confían en que el multisig 3/4 solo desplegará actualizaciones bien revisadas. Para usuarios que quieren una alternativa inmutable, el programa AMM v4 más antiguo ha sido estable desde su última auditoría; cero actualizaciones en 18 meses. Esa ruta de código está efectivamente congelada aunque la autoridad aún existe.Autoridad de AmmConfig
Cada creación de nuevo AmmConfig está permisionada — el multisig de tesorería 3/5 autoriza nuevos niveles de comisión y espacios 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 swap (típicamente 3–12 bps de 25 bps de comisión de swap, 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 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 de apuesta de usuario.
- Cambiar el mint 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 inspeccionarse 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 en 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 transacción y transmisión en cadena.
- Cola de transacción 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:
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 de 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/router debe re-obtener la lista de configuración completa periódicamente (cada hora está bien).3. Vectores de dolor 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 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 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 de administrador sospechosos.
- Protocolo Squads — interfaz de usuario de multisig.
- Documentos de BPF Loader de Solana — mecanismo de actualización.