Permisos y sustituciones
CUBIT distingue un núcleo de identidades fijas, un guardian limitado al mantenimiento y un equipo que administra los módulos periféricos. La expiración del guardian no elimina el poder de sustitución del equipo.
Qué permanece fijo
El token, el hook principal, el PoolManager, el poolId, el WETH de recompensa y el anclaje del registro no se sustituyen mediante los setters periféricos.
El token autoriza a su hook mediante una conexión única. Las tasas del núcleo no tienen setter en las fuentes leídas. Una política nueva que modifique el núcleo exige una versión nueva, su validación y despliegue; no actualiza automáticamente un pool antiguo.
El guardian de mantenimiento
El guardian puede llamar a pause() y unpause() mientras su poder no haya expirado. La pausa impide raiseFloor() y rebalance(); no suspende los swaps.
GUARDIAN_LIFETIME equivale a 14 días. En el código, guardianExpiry se fija en el timestamp de construcción del hook + 14 días. El calendario de lanzamiento puede hablar de D+14, pero la integración debe leer el vencimiento real del contrato.
Después de ese plazo, una pausa de mantenimiento antigua deja de ser efectiva. burnAbsorbed() sigue accesible independientemente de esta pausa.
El nombre histórico isImmutable() describe esta expiración en las vistas del núcleo; no acredita la ausencia de toda administración en el ecosistema.
El papel del equipo
El equipo es authority() en CubitV2. Conserva la administración de los módulos periféricos y puede sustituir estas cuatro direcciones:
| Setter | Principales controles de conexión | Consecuencia |
|---|---|---|
setVault(next) |
Código presente, mismo hook/token/WETH, Vault nuevo, ninguna liquidación Vault pendiente | Nuevo contrato de referencia para futuros depósitos |
setRouter(next) |
Código presente, mismo hook/PoolManager/poolId | Router actual sustituido |
setLens(next) |
Código presente, mismo hook/PoolManager/poolId/token | Contrato de lectura actual sustituido |
setForge(next) |
Código presente, mismo hook y curator del equipo | Factory de referencia sustituida para futuros lanzamientos |
Cada cambio emite ModuleUpdated e incrementa moduleRevision. Comprueba la nueva dirección y su código antes de una operación.
Los límites de los controles de compatibilidad
Los getters que declaran las direcciones correctas demuestran la conexión esperada, no la seguridad de todo el código candidato. No prueban la ausencia de proxy ni de comportamiento malicioso en una implementación futura.
Por tanto, el equipo elige el código periférico utilizado para las operaciones futuras. Esta capacidad exige verificar cada sustitución, su bytecode y sus interacciones.
Los fondos ya depositados
Sustituir un Vault no transfiere los CUBIT ni las recompensas del contrato antiguo. Sus posiciones, plazos y salidas permanecen en ese Vault antiguo. El registro conserva la lista de Vaults y el frontend debe seguir exponiendo esas posiciones.
Se conservan los vínculos first-bound y las reclamaciones de referidos ya acumuladas. Un router antiguo pierde el derecho a atribuir nuevos referidos, pero sigue sujeto a las tasas del hook.
Sustituir Forge afecta a los lanzamientos futuros; los hijos ya creados conservan sus contratos.
Estos setters no reparan retroactivamente un contrato defectuoso ni mueven fondos que pueda mantener. La posibilidad de llamar a una salida on-chain y su disponibilidad en el frontend deben comprobarse por separado.
Autorizaciones y firmas
Una autorización está vinculada a un spender concreto. No sigue la dirección actual del registro. El frontend debe revalidar la operación cuando cambian la revisión o los módulos, especialmente entre una autorización y un swap.
Una firma Links compromete al registro y la cadena del dominio EIP-712. No debe redirigirse a otro contrato sin revisar de nuevo los datos firmados.
Fuentes: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md y los controles del frontend releases.ts / vault.ts.