Permissions and replacements
CUBIT distinguishes a core with fixed identities, a guardian limited to maintenance and a team administering peripheral modules. Guardian expiry does not remove the team’s replacement power.
What remains fixed
The token, main hook, PoolManager, poolId, reward WETH and registry anchor are not replaced by peripheral setters.
The token authorizes its hook through a one-time connection. Core rates have no setter in the sources reviewed. A new policy changing the core requires a new version, validation and deployment; it does not automatically update an old pool.
The maintenance guardian
The guardian can call pause() and unpause() until its authority expires. Pausing prevents raiseFloor() and rebalance(); it does not suspend swaps.
GUARDIAN_LIFETIME is 14 days. In the code, guardianExpiry is set to the hook construction timestamp + 14 days. The launch schedule may refer to D+14, but an integration must read the contract’s actual expiry.
After this deadline, an older maintenance pause is no longer effective. burnAbsorbed() remains accessible independently of this pause.
The historical name isImmutable() describes this expiry in core views; it does not attest to the absence of all administration in the ecosystem.
The team’s role
The team is authority() in CubitV2. It retains peripheral module administration and can replace the following four addresses:
| Setter | Main connection checks | Consequence |
|---|---|---|
setVault(next) |
Code present, same hook/token/WETH, fresh Vault, no pending Vault settlement | New reference contract for future deposits |
setRouter(next) |
Code present, same hook/PoolManager/poolId | Current router replaced |
setLens(next) |
Code present, same hook/PoolManager/poolId/token | Current read contract replaced |
setForge(next) |
Code present, same hook and team curator | Reference factory replaced for future launches |
Every change emits ModuleUpdated and increments moduleRevision. Check the new address and code before an operation.
Limitations of compatibility checks
Getters declaring the correct addresses demonstrate the expected connection, not the safety of all candidate code. They do not prove the absence of a proxy or malicious behavior in a future implementation.
The team therefore chooses peripheral code used for future operations. This ability requires checking each replacement, its bytecode and interactions.
Funds already deposited
A Vault replacement does not transfer CUBIT or rewards from the old contract. Its positions, deadlines and exits remain in that old Vault. The registry keeps the Vault list and the frontend must continue exposing those positions.
First-bound links and already accrued referral claims are preserved. An old router loses the right to attribute new referrals but remains subject to hook taxes.
Replacing Forge affects future launches; children already created keep their contracts.
These setters do not retroactively repair a defective contract or move funds it may hold. The ability to call an on-chain exit and its availability in the frontend must be checked separately.
Approvals and signatures
An approval is attached to a specific spender. It does not follow the registry’s current address. The frontend must revalidate an operation when the revision or modules change, particularly between approval and swap.
A Links signature commits to the registry and chain in the EIP-712 domain. It must not be redirected to another contract without reviewing the signed data again.
Sources: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md and frontend checks in releases.ts / vault.ts.