mCUBIT Vault
The future Vault will offer CUBIT deposits in a nontransferable position and a share of revenue in WETH. Its model does not create CUBIT and grants no withdrawal rights over wall funds.
The name mCUBIT refers to this deposit experience; the code reviewed does not create a freely transferable ERC-20 receipt token.
Future release, targeted window from D+3. The behaviors described below constitute the planned workflow; availability will be specified at release.
Where rewards come from
Planned funding is 20% of ladder LP fees actually realized in ETH, collected during the relevant maintenance operations, including rebalance, for users with deposits.
This percentage applies to realized fees, not swap volumes, hook taxes, ladder principal or fees displayed but not yet collected.
The Vault receives ETH from the hook and converts it to WETH. Rewards use accounting per deposited token. No activity or realized fees can mean zero rewards; no fixed rate is promised.
Depositing CUBIT
- When the module is released, check the offered Vault’s address and connection to the protocol.
- Authorize the Vault to transfer the chosen amount.
- Call
stake(amount)and wait for confirmation. - Read
balanceOf(account)andunlockAt(account)on the deposit contract.
Every additional deposit restarts the 24-hour lock for that wallet’s position in that Vault. It does not lock only the added amount.
Deposited CUBIT remains existing tokens. A deposit is neither a burn nor an artificial reduction in supply.
Withdrawing and claiming
withdraw(amount) returns deposited CUBIT when the chain timestamp reaches unlockAt. Withdrawals can be partial. claim() transfers accrued WETH rewards; the withdrawal lock does not block this claim in the implementation reviewed.
Exits are not suspended by the core’s guardian pause. They remain subject to the rules and correct operation of the contract holding the position.
Rewards arriving without any staker are separated: the first deposit must not capture them retroactively. Small rounding remainders stay in the Vault according to its accounting.
If the Vault is replaced
Replacement concerns the contract offered for new deposits. CUBIT, rewards and unlock dates already recorded remain in the old Vault. Replacement does not move user funds.
The frontend reads the historical list and allows each older Vault to be selected. Check the selected address before reading a balance, claiming or withdrawing. Approval for the previous Vault does not authorize the new one.
The registry rejects replacement while the hook still has a pending Vault settlement (vaultAccrued != 0). It also requires a correctly connected new Vault with no prior deposits or funding.
Module limitations
Replacement getter checks verify the addresses’ declared compatibility; they do not prove the safety of all replacement code. Accounting tests, integration with fee collection and preservation of exits from old Vaults remain points to validate for each release.
Sources: periphery/CubitVault.sol, CubitV2.setVault, CubitHook._accrueVaultFees, _claimVaultRewards and dapp/src/chain/vault.ts.