Die Wartung auslösen
Die Wartungsfunktionen sind permissionless: Ein Nutzer oder Bot kann sie ohne administrative Rolle aufrufen. Die Regeln des Vertrags entscheiden, ob der Vorgang zulässig ist.
| Aufruf | Beabsichtigte Wirkung | Vergütung |
|---|---|---|
raiseFloor() |
Zulässige Mittel nach den Regeln der jeweiligen Version in einer Wall platzieren | Begrenzte Prämie aus der Ladder |
rebalance() |
Die Ladder neu ordnen und die vorgesehenen Zuweisungen vornehmen | Begrenzte Prämie aus der Ladder |
burnAbsorbed() |
Den isolierten Bestand vernichten | Keine Prämie |
Der Name raiseFloor bleibt in der historischen API erhalten. Mit der neuen Formel kann das Niveau einer neuen Wall unter dem einer zuvor finanzierten Wall liegen.
Manueller Ablauf
- Prüfen Sie das Deployment und die Aktualität der Daten auf der Keepers-Seite.
- Lesen Sie die vom Lens angezeigte Zulässigkeit: Wartezeit, Bewegung, Reserve und Pausenstatus.
- Simulieren Sie den Aufruf mit dem Konto, das ihn senden wird, und vergleichen Sie die geschätzten Kosten mit der möglichen Prämie.
- Senden Sie die Transaktion und prüfen Sie anschließend ihren Beleg und die Ereignisse.
Eine zwischen Abfrage und Ausführung unzulässig gewordene Aktion kann abgelehnt werden. Ein RPC-Fehler ist keine Auskunft über die Zulässigkeit.
Die Bedingungen des Rebalance
Die Quellen sehen eine Bewegung von mindestens 1 250 Ticks seit der Referenz des letzten Rebalance und eine Wartezeit von 25 Blöcken vor. Der Pool muss initialisiert und die Wartung erlaubt sein.
Die Funktion erlaubt es nicht, Bänder, Sweep-Anteil oder Begünstigten der Walls beliebig zu wählen.
Die Bedingungen der Platzierung
Eine unzureichende Reserve, ein im aktuellen Zustand nicht platzierbares Ziel, Poolbeschränkungen oder eine Pause können raiseFloor() verhindern.
Ist keine Platzierung möglich, bleiben neue Gebühren in der Warteschlange und bestehende Walls an ihren Ticks. Die genauen Ablehnungsnamen und neuen Vorschauen müssen in der validierten ABI der neuen Version nachgelesen werden.
Die Prämie ist keine garantierte Rendite
Die Parameter des gelesenen Codes betragen 50 bps der bewegten ETH, also 0,50 %, mit einer Obergrenze von 0,01 ETH. Bei einer Wall-Platzierung wird der Betrag zusätzlich durch die verfügbaren ungenutzten ETH der Ladder begrenzt.
Die tatsächlichen Kosten hängen vom Gasverbrauch, Gaspreis und Endzustand ab. Die Prämie stammt nicht aus den den Walls zugewiesenen Mitteln. Ein Keeper kann freiwillig einen verlustbringenden Vorgang ausführen, um den Betrieb aufrechtzuerhalten.
Pause und Burn
Der Guardian kann raiseFloor() und rebalance() während seiner Befugnisdauer aussetzen. Swaps bleiben über eine kompatible Integration zugänglich, und burnAbsorbed() wird durch diese Wartungspause nicht ausgesetzt.
Der Ablauf des Guardians und die Administration der V2-Module sind zwei getrennte Themen. Berechtigungen und Austausch.
Diesen Ablauf automatisieren
Der Dienst services/keeper liest den Lens, simuliert und verfolgt Belege. Ein Dry-Run-Modus ermöglicht eine Prüfung ohne Senden von Transaktionen. Dauerbetrieb, Finanzierung des Gases und Wiederanlaufprotokolle müssen noch organisiert werden. Betriebsleitfaden.
Quellen: Einstiegspunkte und Konstanten von CubitHook.sol, CubitLens.canRebalance, services/keeper/src/index.ts und dessen README.