mCUBIT Vault
El futuro Vault permitirá depositar CUBIT en una posición intransferible y recibir una parte de los ingresos en WETH. Su modelo no crea CUBIT ni concede derechos de retirada sobre los fondos de los muros.
El nombre mCUBIT designa esta experiencia de depósito; el código leído no crea un token de recibo ERC-20 libremente transferible.
Lanzamiento futuro, ventana prevista desde D+3. Los comportamientos descritos a continuación constituyen el recorrido previsto; la disponibilidad se precisará en el lanzamiento.
De dónde proceden las recompensas
La financiación prevista es el 20% de las comisiones LP del ladder realmente realizadas en ETH, recogidas durante las operaciones de mantenimiento pertinentes, especialmente el rebalanceo, para los usuarios con depósitos.
Este porcentaje se aplica a comisiones realizadas, no a volúmenes de swap, tasas del hook, principal del ladder ni comisiones mostradas pero todavía no recogidas.
El Vault recibe ETH del hook y lo convierte en WETH. Las recompensas siguen una contabilidad por token depositado. La ausencia de actividad o de comisiones realizadas puede producir cero recompensas; no se promete una tasa fija.
Depositar CUBIT
- Cuando se lance el módulo, comprueba la dirección del Vault ofrecido y su conexión al protocolo.
- Autoriza al Vault a transferir el importe elegido.
- Llama a
stake(amount)y espera la confirmación. - Lee
balanceOf(account)yunlockAt(account)en el contrato de depósito.
Cada depósito adicional reinicia el bloqueo de 24 h de la posición de esa cartera en ese Vault. No bloquea solo la cantidad añadida.
Los CUBIT depositados siguen siendo tokens existentes. Un depósito no es una quema ni una reducción artificial de la oferta.
Retirar y reclamar
withdraw(amount) devuelve los CUBIT depositados cuando el timestamp de la cadena alcanza unlockAt. La retirada puede ser parcial. claim() transfiere las recompensas WETH adquiridas; el bloqueo de retirada no impide esta reclamación en la implementación leída.
Las salidas no se suspenden por la pausa del guardian del núcleo. Siguen sujetas a las reglas y al funcionamiento correcto del contrato que mantiene la posición.
Las recompensas que llegan sin ningún depositante se separan: el primer depósito no debe capturarlas retroactivamente. Los pequeños remanentes de redondeo permanecen en el Vault según su contabilidad.
Si se sustituye el Vault
La sustitución afecta al contrato ofrecido para depósitos nuevos. Los CUBIT, las recompensas y las fechas de desbloqueo ya registrados permanecen en el Vault antiguo. La sustitución no mueve los fondos del usuario.
El frontend lee la lista histórica y permite seleccionar cada Vault antiguo. Comprueba la dirección seleccionada antes de leer un saldo, reclamar o retirar. Una autorización del Vault anterior no autoriza al nuevo.
El registro rechaza la sustitución si el hook todavía tiene una liquidación Vault pendiente (vaultAccrued != 0). También exige un Vault nuevo correctamente conectado, sin depósitos ni financiación previos.
Los límites del módulo
Las comprobaciones de getters en la sustitución verifican la compatibilidad declarada de las direcciones; no prueban la seguridad de todo código sustituto. Las pruebas contables, la integración con la recogida de comisiones y la conservación de las salidas de Vaults antiguos siguen siendo puntos que deben validarse en cada lanzamiento.
Fuentes: periphery/CubitVault.sol, CubitV2.setVault, CubitHook._accrueVaultFees, _claimVaultRewards y dapp/src/chain/vault.ts.