Permissions et remplacements
CUBIT distingue un cœur aux identités fixes, un guardian limité à la maintenance et une équipe qui administre les modules périphériques. L’expiration du guardian ne supprime pas le pouvoir de remplacement de l’équipe.
Ce qui reste fixé
Le token, le hook principal, le PoolManager, le poolId, le WETH de récompense et l’ancre du registre ne sont pas remplacés par les setters périphériques.
Le token autorise son hook via un raccordement unique. Les taux du cœur n’ont pas de setter dans les sources lues. Une nouvelle politique modifiant le cœur demande une nouvelle version, sa validation et son déploiement ; elle ne met pas automatiquement à jour un ancien pool.
Le guardian de maintenance
Le guardian peut appeler pause() et unpause() tant que son pouvoir n’a pas expiré. La pause empêche raiseFloor() et rebalance() ; elle ne suspend pas les swaps.
GUARDIAN_LIFETIME vaut 14 jours. Dans le code, guardianExpiry est fixé au timestamp de construction du hook + 14 jours. Le programme de lancement peut parler de J+14, mais l’intégration doit lire l’échéance réelle du contrat.
Après cette échéance, une ancienne pause de maintenance n’est plus effective. burnAbsorbed() reste accessible indépendamment de cette pause.
Le nom historique isImmutable() décrit cette expiration dans les vues du cœur ; il n’atteste pas l’absence de toute administration dans l’écosystème.
Le rôle de l’équipe
L’équipe est authority() dans CubitV2. Elle conserve l’administration des modules périphériques et peut remplacer les quatre adresses suivantes :
| Setter | Contrôles de raccordement principaux | Conséquence |
|---|---|---|
setVault(next) |
Code présent, même hook/token/WETH, Vault neuf, aucun règlement Vault en attente | Nouveau contrat de référence pour les futurs dépôts |
setRouter(next) |
Code présent, même hook/PoolManager/poolId | Routeur courant remplacé |
setLens(next) |
Code présent, même hook/PoolManager/poolId/token | Contrat de lecture courant remplacé |
setForge(next) |
Code présent, même hook et curator équipe | Factory de référence remplacée pour les futurs lancements |
Chaque changement émet ModuleUpdated et incrémente moduleRevision. Vérifiez la nouvelle adresse et son code avant une opération.
Les limites des contrôles de compatibilité
Des getters déclarant les bonnes adresses démontrent un raccordement attendu, pas la sûreté de tout le code candidat. Ils ne prouvent pas l’absence de proxy ou de comportement malveillant dans une future implémentation.
L’équipe choisit donc le code périphérique utilisé pour les opérations futures. Cette capacité impose de vérifier chaque remplacement, son bytecode et ses interactions.
Les fonds déjà déposés
Un remplacement de Vault ne transfère pas les CUBIT ni les rewards de l’ancien contrat. Ses positions, ses échéances et ses sorties demeurent dans cet ancien Vault. Le registre conserve la liste des Vaults et le frontend doit continuer à exposer ces positions.
Les liens first-bound et les claims referral déjà accumulés sont conservés. Un ancien routeur perd le droit d’attribution de nouveaux referrals mais reste soumis aux taxes du hook.
Remplacer Forge concerne les lancements futurs ; les enfants déjà créés gardent leurs contrats.
Ces setters ne réparent pas rétroactivement un contrat défectueux et ne déplacent pas des fonds qu’il détiendrait. La possibilité d’appeler une sortie on-chain et sa disponibilité dans le frontend doivent être vérifiées séparément.
Approvals et signatures
Une approval est attachée à un spender précis. Elle ne suit pas l’adresse courante du registre. Le frontend doit revalider l’opération lorsque la révision ou les modules changent, notamment entre une approval et un swap.
Une signature Links engage le registre et la chaîne du domaine EIP-712. Elle ne doit pas être redirigée vers un autre contrat sans nouvelle revue des données signées.
Sources : CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md et les contrôles frontend releases.ts / vault.ts.