Permessi e sostituzioni
CUBIT distingue un nucleo con identità fisse, un guardian limitato alla manutenzione e un team che amministra i moduli periferici. La scadenza del guardian non elimina il potere di sostituzione del team.
Cosa resta fisso
Token, hook principale, PoolManager, poolId, WETH delle ricompense e ancoraggio del registro non vengono sostituiti dai setter periferici.
Il token autorizza il proprio hook tramite un collegamento unico. Le aliquote del nucleo non hanno setter nelle fonti lette. Una nuova politica che modifica il nucleo richiede una nuova versione, la sua validazione e il deployment; non aggiorna automaticamente un vecchio pool.
Il guardian di manutenzione
Il guardian può chiamare pause() e unpause() finché il suo potere non è scaduto. La pausa impedisce raiseFloor() e rebalance(); non sospende gli swap.
GUARDIAN_LIFETIME vale 14 giorni. Nel codice, guardianExpiry è fissato al timestamp di costruzione dell’hook + 14 giorni. Il programma di lancio può parlare di G+14, ma l’integrazione deve leggere la scadenza reale del contratto.
Dopo questa scadenza, una vecchia pausa di manutenzione non è più efficace. burnAbsorbed() resta accessibile indipendentemente dalla pausa.
Il nome storico isImmutable() descrive questa scadenza nelle viste del nucleo; non attesta l’assenza di ogni amministrazione nell’ecosistema.
Il ruolo del team
Il team è authority() in CubitV2. Conserva l’amministrazione dei moduli periferici e può sostituire questi quattro indirizzi:
| Setter | Principali controlli di collegamento | Conseguenza |
|---|---|---|
setVault(next) |
Codice presente, stesso hook/token/WETH, Vault nuovo, nessun regolamento Vault in attesa | Nuovo contratto di riferimento per i depositi futuri |
setRouter(next) |
Codice presente, stesso hook/PoolManager/poolId | Router corrente sostituito |
setLens(next) |
Codice presente, stesso hook/PoolManager/poolId/token | Contratto di lettura corrente sostituito |
setForge(next) |
Codice presente, stesso hook e curator del team | Factory di riferimento sostituita per i lanci futuri |
Ogni modifica emette ModuleUpdated e incrementa moduleRevision. Verifica il nuovo indirizzo e il suo codice prima di un’operazione.
I limiti dei controlli di compatibilità
Getter che dichiarano gli indirizzi corretti dimostrano il collegamento previsto, non la sicurezza di tutto il codice candidato. Non provano l’assenza di proxy o comportamenti malevoli in un’implementazione futura.
Il team sceglie quindi il codice periferico usato per le operazioni future. Questa capacità impone di verificare ogni sostituzione, il bytecode e le interazioni.
I fondi già depositati
Una sostituzione del Vault non trasferisce CUBIT né ricompense dal vecchio contratto. Posizioni, scadenze e uscite restano in quel vecchio Vault. Il registro conserva l’elenco dei Vault e il frontend deve continuare a esporre quelle posizioni.
I legami first-bound e le somme referral già accumulate vengono conservati. Un vecchio router perde il diritto di attribuire nuovi referral ma resta soggetto alle tasse dell’hook.
Sostituire Forge riguarda i lanci futuri; i figli già creati mantengono i propri contratti.
Questi setter non riparano retroattivamente un contratto difettoso e non spostano i fondi che detiene. La possibilità di chiamare un’uscita on-chain e la sua disponibilità nel frontend vanno verificate separatamente.
Approvazioni e firme
Un’approvazione è legata a uno spender preciso. Non segue l’indirizzo corrente del registro. Il frontend deve rivalidare l’operazione quando revisione o moduli cambiano, in particolare tra un’approvazione e uno swap.
Una firma Links vincola il registro e la catena del dominio EIP-712. Non va reindirizzata a un altro contratto senza una nuova revisione dei dati firmati.
Fonti: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md e i controlli frontend releases.ts / vault.ts.