mCUBIT Vault
O futuro Vault permitirá depositar CUBIT em uma posição intransferível e receber uma parcela das receitas em WETH. Seu modelo não cria CUBIT e não dá direito de retirada sobre os fundos dos muros.
O nome mCUBIT designa essa experiência de depósito; o código lido não cria um token de recibo ERC-20 livremente transferível.
Lançamento futuro, janela prevista a partir de D+3. Os comportamentos descritos abaixo constituem o percurso planejado; a disponibilidade será informada no lançamento.
De onde vêm as recompensas
O financiamento previsto é de 20% das taxas LP do ladder efetivamente realizadas em ETH, coletadas durante as operações de manutenção pertinentes, especialmente o rebalanceamento, para os usuários com depósitos.
Esse percentual incide sobre taxas realizadas, não sobre volumes de swap, taxas do hook, principal do ladder ou taxas exibidas mas ainda não coletadas.
O Vault recebe ETH do hook e o converte em WETH. As recompensas seguem uma contabilidade por token depositado. A ausência de atividade ou de taxas realizadas pode resultar em recompensa zero; nenhuma taxa fixa é prometida.
Depositar CUBIT
- No lançamento do módulo, verifique o endereço do Vault oferecido e sua conexão ao protocolo.
- Autorize o Vault a transferir o valor escolhido.
- Chame
stake(amount)e aguarde a confirmação. - Leia
balanceOf(account)eunlockAt(account)no contrato de depósito.
Cada depósito adicional reinicia o bloqueio de 24 h da posição dessa carteira nesse Vault. Ele não bloqueia apenas a quantidade acrescentada.
Os CUBIT depositados continuam sendo tokens existentes. Um depósito não é uma queima nem uma redução artificial da oferta.
Retirar e resgatar
withdraw(amount) devolve os CUBIT depositados quando o timestamp da cadeia alcança unlockAt. A retirada pode ser parcial. claim() transfere as recompensas WETH adquiridas; o bloqueio de retirada não impede esse resgate na implementação lida.
As saídas não são suspensas pela pausa do guardian do núcleo. Elas continuam sujeitas às regras e ao funcionamento correto do contrato que mantém a posição.
As recompensas que chegam sem nenhum depositante são separadas: o primeiro depósito não deve capturá-las retroativamente. Pequenos resíduos de arredondamento permanecem no Vault conforme sua contabilidade.
Se o Vault for substituído
A substituição afeta o contrato oferecido para novos depósitos. Os CUBIT, as recompensas e as datas de desbloqueio já registrados permanecem no Vault antigo. A substituição não move os fundos do usuário.
O frontend lê a lista histórica e permite selecionar cada Vault antigo. Verifique o endereço selecionado antes de ler um saldo, resgatar ou retirar. A aprovação do Vault anterior não autoriza o novo.
O registro recusa a substituição quando o hook ainda tem uma liquidação Vault pendente (vaultAccrued != 0). Ele também exige um novo Vault corretamente conectado, sem depósitos nem financiamentos anteriores.
Os limites do módulo
As verificações de getters na substituição conferem a compatibilidade declarada dos endereços; não provam a segurança de todo código substituto. Os testes de contabilidade, a integração com a coleta de taxas e a preservação das saídas dos Vaults antigos continuam sendo pontos a validar em cada lançamento.
Fontes: periphery/CubitVault.sol, CubitV2.setVault, CubitHook._accrueVaultFees, _claimVaultRewards e dapp/src/chain/vault.ts.