mCUBIT Vault

Il futuro Vault permetterà di depositare CUBIT in una posizione non trasferibile e ricevere una quota delle entrate in WETH. Il suo modello non crea CUBIT e non concede diritti di prelievo sui fondi dei muri.

Il nome mCUBIT indica questa esperienza di deposito; il codice letto non crea un token di ricevuta ERC-20 liberamente trasferibile.

Rilascio futuro, finestra prevista da G+3. I comportamenti descritti di seguito costituiscono il percorso previsto; la disponibilità sarà precisata al rilascio.

Da dove provengono le ricompense

Il finanziamento previsto è il 20% delle commissioni LP del ladder effettivamente realizzate in ETH, raccolte durante le operazioni di manutenzione interessate, in particolare il ribilanciamento, per gli utenti con depositi.

Questa percentuale riguarda commissioni realizzate, non volumi di swap, tasse dell’hook, capitale del ladder o commissioni mostrate ma non ancora raccolte.

Il Vault riceve ETH dall’hook e li converte in WETH. Le ricompense seguono una contabilità per token depositato. L’assenza di attività o di commissioni realizzate può produrre zero ricompense; non viene promesso un tasso fisso.

Depositare CUBIT

1. Al rilascio del modulo, verifica l’indirizzo del Vault proposto e il suo collegamento al protocollo.
2. Autorizza il Vault a trasferire l’importo scelto.
3. Chiama stake(amount) e attendi la conferma.
4. Leggi balanceOf(account) e unlockAt(account) sul contratto di deposito.

Ogni deposito aggiuntivo riavvia il blocco di 24 ore dell’intera posizione di quel wallet in quel Vault. Non blocca soltanto la quantità aggiunta.

I CUBIT depositati restano token esistenti. Un deposito non è un burn né una riduzione artificiale dell’offerta.

Prelevare e riscuotere

withdraw(amount) restituisce i CUBIT depositati quando il timestamp della catena raggiunge unlockAt. Il prelievo può essere parziale. claim() trasferisce le ricompense WETH maturate; il blocco del prelievo non impedisce questa riscossione nell’implementazione letta.

Le uscite non vengono sospese dalla pausa del guardian del nucleo. Restano soggette alle regole e al corretto funzionamento del contratto che detiene la posizione.

Le ricompense che arrivano senza alcun depositante vengono separate: il primo deposito non deve acquisirle retroattivamente. I piccoli residui di arrotondamento restano nel Vault secondo la sua contabilità.

Se il Vault viene sostituito

La sostituzione riguarda il contratto proposto per i nuovi depositi. I CUBIT, le ricompense e le date di sblocco già registrati restano nel vecchio Vault. La sostituzione non sposta i fondi dell’utente.

Il frontend legge l’elenco storico e permette di selezionare ogni vecchio Vault. Verifica l’indirizzo selezionato prima di leggere un saldo, riscuotere o prelevare. Un’approvazione del Vault precedente non autorizza quello nuovo.

Il registro rifiuta la sostituzione quando l’hook ha ancora un regolamento Vault in sospeso (vaultAccrued != 0). Richiede inoltre un nuovo Vault correttamente collegato, senza depositi né finanziamenti precedenti.

I limiti del modulo

I controlli dei getter per la sostituzione verificano la compatibilità dichiarata degli indirizzi; non dimostrano la sicurezza di tutto il codice sostitutivo. I test contabili, l’integrazione con la raccolta delle commissioni e la conservazione delle uscite dai vecchi Vault restano punti da validare per ogni rilascio.

Fonti: periphery/CubitVault.sol, CubitV2.setVault, CubitHook._accrueVaultFees, _claimVaultRewards e dapp/src/chain/vault.ts.