Aufnahme und Burn
Wenn ein Verkauf einen mit ETH finanzierten Bereich erreicht, kann er CUBIT gegen diese ETH tauschen. Die von der Wall erworbenen Token müssen aus der handelbaren Liquidität entfernt und ausschließlich für ihre Vernichtung reserviert werden.
Die abnehmende ETH-Tiefe der Wall und die Vernichtung der Token sind zwei unterschiedliche Folgen dieses Vorgangs.
Ein festes anfängliches Angebot, danach deflationär
Zu Beginn werden 21 Millionen CUBIT ausgegeben, ohne späteres Minting. Wenn der Hook von den Walls zurückgekaufte Token vernichtet, sinkt totalSupply() und totalBurned() steigt. Die Deflation entspricht diesen tatsächlichen Vernichtungen; sie hängt nicht bloß von der verstrichenen Zeit ab.
Ein Verkauf erreicht eine Wall
→ ETH dieser Position kaufen CUBIT zurück
→ die CUBIT werden isoliert und anschließend vernichtet
→ das Gesamtangebot sinkt
Von einer Wall zurückgekaufte CUBIT kehren niemals in die handelbare LP zurück, auch wenn der Preis später wieder steigt. Auch eine noch wartende Burn-Warteschlange ist dieser Liquidität bereits entzogen.
Wenn der Preis in einer Handelsspanne schwankt
Wenn die Schwankungen die Walls erreichen, können aufeinanderfolgende Verkäufe dort ETH aufbrauchen und dem Markt schrittweise CUBIT entziehen. Manche Bereiche können am Ende keine ausführbare Liquidität mehr besitzen. Ihre Ticks bleiben identifiziert, auch wenn ihre Mittel aufgebraucht sind.
Ein erneuter Preisanstieg füllt eine Wall nicht automatisch mit den von ihr zurückgekauften CUBIT auf: Diese wurden zur Vernichtung isoliert. Neue Mittel können die Position am selben Tick jedoch verstärken.
| Bereich der Schwankungen | Mögliche Wirkung |
|---|---|
| Die Handelsspanne bleibt oberhalb der Walls | Die Swaps erreichen diese Positionen nicht; daraus entsteht kein Wall-Burn |
| Die Handelsspanne durchläuft eine oder mehrere Walls | CUBIT werden aufgenommen und vernichtet; die ETH dieser Bereiche können schrittweise aufgebraucht werden |
| Der Preis durchläuft die Ladder | Ihre Positionsbestände verändern sich; ihre eigenen Token können beim Rebalance wiederverwendet oder neu platziert werden |
Es sind die Liquiditätsbereiche, die sich erschöpfen können; die Ticks als Preiseinheiten verschwinden nicht. Daher leert nicht jede Handelsspanne automatisch alle Ticks. Die Rolle der Ladder.
Drei zu unterscheidende Zustände
| Zustand | Bedeutung |
|---|---|
| ETH in einer Wall-Position | Mittel, die diese Position abhängig von Preis und Bereich noch verwenden kann |
| Aufgenommene und isolierte CUBIT | Dem Markt entzogener Bestand, der gegebenenfalls noch auf den Burn wartet |
| Vernichtete CUBIT | Durch CubitToken.burn() tatsächlich verringertes Gesamtangebot |
Der Token erlaubt nur dem Hook, den Burn auszuführen. Der öffentliche Einstiegspunkt burnAbsorbed() lässt den Aufrufer keinen Empfänger wählen, um den isolierten Bestand an sich zu nehmen.
Der Ausführungspfad des CUBIT-Routers
Im ausgelieferten Router rechnet der Verkauf zuerst die Tauschvorgänge des Pools ab, schließt die für die Erstattung erforderlichen beliebigen Übertragungen ab und ruft anschließend den Burn auf, falls eine Warteschlange vorhanden ist. Schlägt der Burn fehl, wird der gesamte Verkauf rückgängig gemacht.
Dieses Verhalten gilt für diesen Ausführungspfad. Daraus lässt sich nicht ableiten, dass ein Verkauf über jeden beliebigen Drittanbieter-Router immer alle Token in derselben Transaktion vernichtet.
Integrationen von Drittanbietern
Ein kompatibler Router kann eine Warteschlange isolierter Token hinterlassen. Diese bleiben für den Burn reserviert und dürfen nicht mehr aus der Liquidität der Walls zurückgekauft werden können. Ein späterer Aufruf von burnAbsorbed() schließt ihre Vernichtung ab.
Diese Funktion bleibt während einer Guardian-Wartungspause aufrufbar und zahlt keine Prämie. Ein Keeper mit positiver Rentabilitätsschwelle kann ihren Aufruf daher verzögern.
Was der Burn nicht garantiert
Die Vernichtung reduziert das Angebot; sie erzeugt keine ETH. Hat eine Wall ihre Mittel ausgegeben, um einen Verkauf aufzunehmen, gibt ihr historisches Niveau ihr nicht automatisch Tiefe zurück.
Bei mehreren festen Walls müssen Isolierung und Restbestände weiterhin jeder Position korrekt zugeordnet bleiben. Die Testkampagnen der früheren einzelnen Wall beweisen diese Eigenschaften für die neue Implementierung nicht allein.
Die Nachweise prüfen
Die Ereignisse TokensBurned des Hooks und Burned des Tokens sowie totalBurned() und totalSupply() erlauben es, die tatsächliche Vernichtung nachzuverfolgen. Die Warteschlange pendingBurnTokens stellt einen eigenen Zustand dar.
Die tatsächliche Aufnahme auf einer Netzwerkumgebung oder einem kanonischen Fork und die unabhängige Prüfung des Strict-Burn bleiben Validierungsbedingungen. Bekannte Grenzen ansehen.
Quellen: CubitRouter._finishSwap, CubitHook._isolateAbsorbedTokens, _burnAbsorbed, CubitToken.burn und contracts/docs/STRICT_BURN.md für die Entwicklungsgeschichte des Designs.