mCUBIT Vault
Der zukünftige Vault wird ermöglichen, CUBIT in einer nicht übertragbaren Position zu hinterlegen und einen Anteil der Einnahmen in WETH zu erhalten. Sein Modell erzeugt keine CUBIT und gewährt kein Entnahmerecht an den Mitteln der Walls.
Der Name mCUBIT bezeichnet dieses Einlageangebot; der gelesene Code erzeugt keinen frei übertragbaren ERC-20-Belegtoken.
Zukünftige Veröffentlichung, angestrebtes Fenster ab Tag +3. Die folgenden Verhaltensweisen bilden den vorgesehenen Ablauf; die Verfügbarkeit wird bei Veröffentlichung bekannt gegeben.
Woher die Prämien stammen
Die vorgesehene Finanzierung beträgt 20 % der tatsächlich in ETH realisierten LP-Gebühren der Ladder, die bei den betreffenden Wartungsoperationen, insbesondere beim Rebalance, für Nutzer mit Einlagen eingesammelt werden.
Dieser Prozentsatz bezieht sich auf realisierte Gebühren, nicht auf Swap-Volumen, Hook-Steuern, das Kapital der Ladder oder angezeigte, aber noch nicht eingesammelte Gebühren.
Der Vault erhält ETH vom Hook und wandelt sie in WETH um. Die Prämien werden je hinterlegtem Token verbucht. Fehlende Aktivität oder fehlende realisierte Gebühren können zu null Prämien führen; es wird kein fester Satz versprochen.
CUBIT hinterlegen
- Prüfen Sie bei Veröffentlichung des Moduls die Adresse des angebotenen Vaults und seine Anbindung an das Protokoll.
- Erlauben Sie dem Vault, den gewählten Betrag zu übertragen.
- Rufen Sie
stake(amount)auf und warten Sie auf die Bestätigung. - Lesen Sie
balanceOf(account)undunlockAt(account)im Einlagevertrag aus.
Jede zusätzliche Einlage startet die Sperre von 24 Stunden für die Position dieses Wallets in diesem Vault neu. Sie sperrt nicht nur die hinzugefügte Menge.
Die hinterlegten CUBIT bleiben bestehende Token. Eine Einlage ist weder ein Burn noch eine künstliche Verringerung des Angebots.
Auszahlen und Prämien abrufen
withdraw(amount) gibt die hinterlegten CUBIT zurück, sobald der Zeitstempel der Blockchain unlockAt erreicht. Eine Teilauszahlung ist möglich. claim() überträgt die erworbenen WETH-Prämien; die Auszahlungssperre blockiert diesen Abruf in der gelesenen Implementierung nicht.
Auszahlungen werden durch die Guardian-Pause des Kerns nicht ausgesetzt. Sie unterliegen weiterhin den Regeln und der korrekten Funktionsweise des Vertrags, der die Position hält.
Prämien, die ohne Staker eintreffen, werden getrennt: Sie dürfen nicht rückwirkend von der ersten Einlage vereinnahmt werden. Kleine Rundungsreste verbleiben gemäß seiner Buchhaltung im Vault.
Wenn der Vault ausgetauscht wird
Der Austausch betrifft den für neue Einlagen angebotenen Vertrag. Bereits verbuchte CUBIT, Prämien und Freigabezeitpunkte verbleiben im alten Vault. Der Austausch verschiebt keine Nutzermittel.
Das Frontend liest die historische Liste und ermöglicht die Auswahl jedes früheren Vaults. Prüfen Sie die gewählte Adresse, bevor Sie ein Guthaben abfragen, Prämien abrufen oder Mittel auszahlen. Eine Freigabe des vorherigen Vaults berechtigt den neuen nicht.
Die Registry lehnt den Austausch ab, solange der Hook noch eine laufende Vault-Abrechnung hat (vaultAccrued != 0). Sie verlangt außerdem einen korrekt angebundenen neuen Vault ohne frühere Einlagen oder Finanzierungen.
Die Grenzen des Moduls
Die Getter-Prüfungen beim Austausch kontrollieren die erklärte Kompatibilität der Adressen; sie beweisen nicht die Sicherheit jedes Ersatzcodes. Buchhaltungstests, die Integration mit dem Einsammeln von Gebühren und der Erhalt der Auszahlungswege früherer Vaults bleiben für jede Veröffentlichung zu validierende Punkte.
Quellen: periphery/CubitVault.sol, CubitV2.setVault, CubitHook._accrueVaultFees, _claimVaultRewards und dapp/src/chain/vault.ts.