mCUBIT Vault

Le futur Vault proposera de déposer des CUBIT dans une position non transférable et de recevoir une part de revenus en WETH. Son modèle ne crée pas de CUBIT et ne donne aucun droit de retrait sur les fonds des murs.

Le nom mCUBIT désigne cette expérience de dépôt ; le code lu ne crée pas un token de reçu ERC-20 librement transférable.

Release future, fenêtre visée dès J+3. Les comportements décrits ci-dessous constituent le parcours prévu ; la disponibilité sera précisée lors de la sortie.

D’où viennent les rewards

Le financement prévu est 20 % des frais LP du ladder effectivement réalisés en ETH, collectés lors des opérations de maintenance concernées, notamment le rebalance, pour les utilisateurs ayant des dépôts.

Ce pourcentage porte sur des frais réalisés, pas sur les volumes de swap, les taxes du hook, le principal du ladder ou des fees affichées mais pas encore collectées.

Le Vault reçoit de l’ETH du hook et le convertit en WETH. Les rewards suivent une comptabilité par token déposé. L’absence d’activité ou de frais réalisés peut produire zéro récompense ; aucun taux fixe n’est promis.

Déposer des CUBIT

1. À la sortie du module, vérifiez l’adresse du Vault proposé et son raccordement au protocole.
2. Autorisez le Vault à transférer le montant choisi.
3. Appelez stake(amount) et attendez la confirmation.
4. Lisez balanceOf(account) et unlockAt(account) sur le contrat de dépôt.

Chaque dépôt supplémentaire relance le lock de 24 h pour la position de ce wallet dans ce Vault. Il ne verrouille pas seulement la quantité ajoutée.

Les CUBIT déposés demeurent des tokens existants. Un dépôt n’est ni un burn ni une diminution artificielle de l’offre.

Retirer et réclamer

withdraw(amount) rend les CUBIT déposés lorsque le timestamp de la chaîne atteint unlockAt. Le retrait peut être partiel. claim() transfère les rewards WETH acquises ; le lock de retrait ne bloque pas ce claim dans l’implémentation lue.

Les sorties ne sont pas suspendues par la pause guardian du cœur. Elles restent soumises aux règles et au bon fonctionnement du contrat qui détient la position.

Les rewards arrivant sans aucun staker sont séparées : elles ne doivent pas être capturées rétroactivement par le premier dépôt. Les petits reliquats d’arrondi restent dans le Vault selon sa comptabilité.

Si le Vault est remplacé

Le remplacement concerne le contrat proposé pour les nouveaux dépôts. Les CUBIT, les rewards et les dates de déblocage déjà inscrits restent dans l’ancien Vault. Le remplacement ne déplace pas les fonds de l’utilisateur.

Le frontend lit la liste historique et permet de sélectionner chaque ancien Vault. Vérifiez l’adresse sélectionnée avant de lire un solde, de réclamer ou de retirer. Une approval du Vault précédent n’autorise pas le nouveau.

Le registre refuse le remplacement lorsque le hook a encore un règlement Vault en cours (vaultAccrued != 0). Il exige aussi un nouveau Vault correctement raccordé, sans dépôts ni financements antérieurs.

Les limites du module

Les getter checks de remplacement vérifient la compatibilité déclarée des adresses ; ils ne prouvent pas la sécurité de tout code de remplacement. Les tests de comptabilité, l’intégration avec la collecte de fees et la conservation des sorties des anciens Vaults restent les points à valider pour chaque release.

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