Permissões e substituições
CUBIT distingue um núcleo de identidades fixas, um guardian limitado à manutenção e uma equipe que administra os módulos periféricos. O vencimento do guardian não elimina o poder de substituição da equipe.
O que permanece fixo
O token, o hook principal, o PoolManager, o poolId, o WETH de recompensa e a âncora do registro não são substituídos pelos setters periféricos.
O token autoriza seu hook por uma conexão única. As taxas do núcleo não têm setter nas fontes lidas. Uma nova política que modifica o núcleo exige nova versão, validação e implantação; não atualiza automaticamente um pool antigo.
O guardian de manutenção
O guardian pode chamar pause() e unpause() enquanto seu poder não tiver vencido. A pausa impede raiseFloor() e rebalance(); ela não suspende os swaps.
GUARDIAN_LIFETIME vale 14 dias. No código, guardianExpiry é definido como timestamp de construção do hook + 14 dias. O programa de lançamento pode falar em D+14, mas a integração deve ler o vencimento real do contrato.
Após esse prazo, uma pausa antiga de manutenção deixa de ser efetiva. burnAbsorbed() permanece acessível independentemente dessa pausa.
O nome histórico isImmutable() descreve esse vencimento nas visualizações do núcleo; não atesta a ausência de toda administração no ecossistema.
O papel da equipe
A equipe é authority() em CubitV2. Ela mantém a administração dos módulos periféricos e pode substituir estes quatro endereços:
| Setter | Principais verificações de conexão | Consequência |
|---|---|---|
setVault(next) |
Código presente, mesmo hook/token/WETH, Vault novo, nenhuma liquidação Vault pendente | Novo contrato de referência para depósitos futuros |
setRouter(next) |
Código presente, mesmo hook/PoolManager/poolId | Roteador atual substituído |
setLens(next) |
Código presente, mesmo hook/PoolManager/poolId/token | Contrato de leitura atual substituído |
setForge(next) |
Código presente, mesmo hook e curator da equipe | Factory de referência substituída para lançamentos futuros |
Cada alteração emite ModuleUpdated e incrementa moduleRevision. Verifique o novo endereço e seu código antes de uma operação.
Os limites das verificações de compatibilidade
Getters que declaram os endereços corretos demonstram uma conexão esperada, não a segurança de todo código candidato. Eles não provam a ausência de proxy ou comportamento malicioso em uma implementação futura.
A equipe, portanto, escolhe o código periférico usado para operações futuras. Essa capacidade exige verificar cada substituição, seu bytecode e suas interações.
Os fundos já depositados
Uma substituição de Vault não transfere os CUBIT nem as recompensas do contrato antigo. Suas posições, seus prazos e suas saídas continuam nesse Vault antigo. O registro mantém a lista de Vaults e o frontend deve continuar expondo essas posições.
Os vínculos first-bound e os resgates de indicação já acumulados são preservados. Um roteador antigo perde o direito de atribuir novas indicações, mas continua sujeito às taxas do hook.
Substituir Forge afeta os lançamentos futuros; os filhos já criados mantêm seus contratos.
Esses setters não corrigem retroativamente um contrato defeituoso nem movem os fundos que ele possa manter. A possibilidade de chamar uma saída on-chain e sua disponibilidade no frontend devem ser verificadas separadamente.
Aprovações e assinaturas
Uma aprovação está vinculada a um spender específico. Ela não acompanha o endereço atual do registro. O frontend deve revalidar a operação quando a revisão ou os módulos mudarem, especialmente entre uma aprovação e um swap.
Uma assinatura Links se compromete com o registro e a cadeia do domínio EIP-712. Ela não deve ser redirecionada a outro contrato sem nova revisão dos dados assinados.
Fontes: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md e as verificações de frontend releases.ts / vault.ts.