Haven 3.0 Tokenomics-Vorschlag (leicht)

Um den vollständigen Vorschlag anzuzeigen, klicken Sie auf Hier.
Sie können auch eine PDF-Version des vollständigen Vorschlags herunterladen Hier.

Überblick

In den letzten Monaten hat die Economics Working Group (EWG) in enger Abstimmung mit den Haven-Entwicklern an einem Vorschlag für eine spezifische Implementierung für das Vault Backed Shoring (VBS) gearbeitet. Vorschlag das wurde am 7. Juli 2022 durch Community-Abstimmung genehmigt. 

Oben auf dieser Seite befindet sich ein Link zum vollständigen 32-seitigen PDF-Vorschlag der EWG an die Community. Es erklärt die Umstände, die uns hierher geführt haben, die Theorie hinter VBS, unsere vorgeschlagenen Formeln und Simulationen davon in Aktion. Es handelt sich um ein leicht technisches Dokument, und wir empfehlen jedem, es nach bestem Wissen und Gewissen durchzulesen. Dieser Blogbeitrag wird jedoch eine zusammengefasste Version sein, die für eher technisch nicht versierte Leser gedacht ist. 

Das Haven-Protokoll befindet sich derzeit in einem fehlerhaften Zustand, da der Schutz durch frühere Konfigurationen der Offshoring/Onshoring-Mechanismen von Haven unzureichend war. Unsere bisherigen Tokenomics konzentrierten sich darauf, den Marktpreis von xUSD in Richtung $1 zu halten, aber dies auf Kosten des XHV-Preises. Dies wurde von verschiedenen Parteien ausgenutzt, was zu einer erheblichen Inflation führte und schließlich zu einer drohenden Todesspirale des XHV-Preises führte. Diese Krise wurde durch die Entscheidung der EWG abgewendet, die Konvertierungen im Juni 2022 einzustellen, da die Aktionen der allgemeinen Benutzer und insbesondere der großen Wale auf dem Weg waren, das Protokoll zu zerstören.

In den folgenden Wochen kam die EWG in vielen Stunden der Debatte zu dem Schluss, dass es zu einfach sei, von der unbegrenzten Liquidität der Shoring-Funktionen zu profitieren und sich gleichzeitig vor den negativen Auswirkungen auf den XHV-Preis zu schützen. In unseren Diskussionen stellten wir fest, dass sich alle anderen algorithmischen Stablecoins auf die Aufrechterhaltung des Stablecoin-Preises konzentriert hatten und nicht auf den Preis des Vermögenswerts, der den Stablecoin unterstützt, und daher einen grundlegenden Fehler gemacht hatten. Geben Sie VBS ein.

VBS verlangt von einem potenziellen Off-/Onshore-Anleger von XHV, dass er eine Sicherheit in Höhe von XHV hält, um den Off-/Onshore-Auftrag auszuführen. Wenn ein Benutzer eine x-Menge an XHV auslagern möchte, muss er separat eine y-Menge an XHV halten, die für die Dauer der Umwandlung gesperrt wird. Umgekehrt, wenn ein Benutzer einen Betrag von xUSD onshore möchte, muss er separat einen Betrag von c XHV halten, der für die Dauer der Umwandlung gesperrt wird. Konkrete Nummern werden weiter unten behandelt.

Der Zweck besteht darin, jeden, der die Off-/Onshore-Funktionen nutzen möchte, dem XHV-Preis und damit der Gesundheit des Ökosystems des Haven-Protokolls auszusetzen. Wenn ein Benutzer beispielsweise seine Offshore-xUSD zu einem späteren Zeitpunkt an Land ziehen möchte, muss er ein XHV-Guthaben behalten oder XHV auf dem Markt kaufen, bevor er einen Roundtrip abschließen kann. 

Neben VBS schlagen wir drei weitere Änderungen vor, die dazu beitragen sollen, das Protokoll und die Nachhaltigkeit des Projekts zu schützen: 

• Sperrzeiten 
• Umrechnungsgebühren
• Eine Obergrenze für den Betrag, der in jedem Block umgewandelt werden kann 

Die Sperrzeiten und Konvertierungsgebühren sind am einfachsten, daher werden wir sie kurz behandeln, bevor wir auf die VBS-Sicherheitenanforderung und die Konvertierungsobergrenze pro Block eingehen. 

Sperrzeiten

Sperrzeiten bieten eine Verzögerung dafür, wie schnell Gelder aus-/eingelagert werden können und dann für den Verkauf auf dem Markt oder aus-/eingelagert verfügbar sind. Die für eine Umwandlung erforderlichen VBS-Sicherheiten werden ebenfalls für denselben Zeitraum gesperrt, für den umgewandelte Gelder gesperrt sind.

Die von uns vorgeschlagenen Schleusenzeiten betragen 21 Tage für Offshore und Onshore.

Umwandlungsgebühren

Ursprünglich haben wir ein Modell vorgeschlagen, bei dem dynamische Gebühren als Maßnahme zum Schutz des Systems verwendet würden. Dies war jedoch aus mehreren Gründen unhaltbar. Stattdessen schlagen wir 1.5% für Offshores und 1.5% für Onshores vor. Die Gebühren mögen hoch erscheinen, aber da die Staatskasse erschöpft ist und die Mittel durch einen stark reduzierten Prozentsatz des Volumens für Konvertierungen nach der Implementierung von VBS begrenzt sind, müssen wir sicherstellen, dass das Projekt genügend Mittel erhält, um seine Betriebskosten zu decken.

Die aktuellen xUSD < > xAssets Konvertierungsgebühren sind 0,51 TP1T pro Konvertierung, von denen 0,41 TP1 T verbrannt werden und 0,11 TP1 T gleichmäßig zwischen Minern und der Governance-Wallet aufgeteilt werden.

Um sicherzustellen, dass das Protokoll genügend Einnahmen durch Konvertierungen erhält, möchten wir die folgenden Änderungen vornehmen:

• xUSD < > xAssets Konvertierungsgebühren werden auf 1,5% erhöht
• 1.2% würde an die Governance-Wallet gesendet
• 0,31 TP1T würden an Miner gehen (Anstieg von 0,051 TP1T)

Die Gebühren werden regelmäßig angepasst.

VBS

Die Hauptfrage ist, welche Sicherheiten genau erforderlich sein sollten, um eine Shoring-Funktion zu erfüllen. Es sind drei Schlüsselfaktoren zu berücksichtigen:

• Der Betrag, den ein Benutzer off-/onshore möchte
• Der aktuelle Zustand des XHV-Ökosystems vor dem Off-/Onshore-Einsatz
• Die potenzielle Inflation/zukünftige Gesundheit des XHV-Ökosystems nach Offshore/Onshore

Durch die Analyse historischer Daten und die Modellierung potenzieller Zukunftsszenarien haben wir schnell erkannt, dass die Sicherheitenanforderungsquoten im ursprünglichen Vorschlag keinen angemessenen Schutz bieten würden. Das Endziel ist ein System, das einfach zu bedienen ist, wenig Sicherheiten erfordert, wenn das System in Ordnung ist, aber vor einer starken Inflation schützt, wenn das Protokoll in Gefahr ist. 

In Anbetracht unseres derzeitigen ungesunden Zustands ist dies eine Herausforderung, und da wir Neuland betreten, ist unser derzeitiger Vorschlag zum Schutz des Protokolls konservativ. Wir können die Formeln in Zukunft benutzerfreundlicher verfeinern, sobald wir eine gewisse Stabilität erreicht haben. 

In unseren VBS-Sicherheitenberechnungen werden drei Schlüsselkomponenten verwendet:

• Marktkapitalisierungsverhältnis – Das Verhältnis zwischen dem Wert von XHV und xAssets im Umlauf
• Spread Ratio – Ein Maß für den „Abstand“ zwischen der XHV-Marktkapitalisierung und der xAssets-Marktkapitalisierung
• Slippage – Die Auswirkung, die eine Transaktion auf den Zustand des Ökosystems haben wird

Die spezifischen Formeln stehen zur Diskussion in der Community und sind im Vorschlagsdokument zu finden. Im Folgenden werden wir diese möglichst nicht-technisch zusammenfassen und Beispiele liefern.

Die gesamte VBS-Sicherheitsanforderung beträgt:

Marktkapitalisierung oder Spread Ratio VBS + Slippage VBS

Die erste Teilrechnung hängt zunächst davon ab, ob es sich um ein Off-/Onshore handelt:

• Offshores – Marktkapitalisierungsverhältnis 
• Onshores – Der größere Wert aus dem Marktkapitalisierungsverhältnis und dem Spread-Verhältnis 

Das Marktkapitalisierungsverhältnis verwendet zwei separate Funktionen, die separate Bereiche des Marktkapitalisierungsverhältnisses abdecken. Wir schlagen vor, dass unter 0,9 mcap Ratio eine weniger aggressive Formel verwendet wird, um eine einfachere Nutzung des Systems zu ermöglichen, und über 0,9 verwenden wir eine exponentiellere Formel, die dazu führt, dass die Sicherheitenanforderung stark ansteigt. 

Das Spread Ratio ist nur als zusätzlicher Schutz für das Onshoring erforderlich, da das Angebot an XHV steigt, wenn die Menschen an Land sind, wodurch das Mcap-Verhältnis sinkt, die Sicherheitsanforderungen sinken und eine größere Wahrscheinlichkeit für eine Inflation geschaffen wird.

Für Onshore-Anlagen verwenden wir den schlechtesten von zwei VBS-Werten zwischen mcap und Spread-Verhältnis, was bedeutet, dass wir Schutz über die gesamte Bandbreite des Marktkapitalisierungsverhältnisses erhalten.

Die folgende Tabelle zeigt VBS-Werte für eine Reihe von Mcap- und Spread-Verhältnissen sowie die entsprechenden berechneten VBS-Werte. Die letzte Spalte zeigt den tatsächlichen VBS-Wert, der für Onshores verwendet wird, das ist der höhere VBS der beiden, Mcap und Spread VBS.

Schlupf

Um zu vermeiden, dass die Marktkapitalisierungsrate durch einzelne, große Konvertierungen zu schnell ansteigt (sich verschlechtert), müssen wir der Slippage in Form von VBS hinzufügen Anfängliche VBS, die aus dem Anfangszustand des Protokolls abgeleitet wird. Dies wird Wale einschränken, die sehr große Beträge mit unendlicher Liquidität konvertieren.

Der Schlupf wird für Offshore und Onshore unterschiedlich berechnet.

Zum Offshores, nehmen wir die prozentuale Erhöhung der Marktkapitalisierungsverhältnis basierend darauf, wie viel umgewandelt wird.
Zum An Land, nehmen wir die prozentuale Erhöhung der Spread-Verhältnis.

Die spezifischen Formeln sind im Vorschlagsdokument aufgeführt. Da Onshore im Vergleich zu Offshore bereits eine zusätzliche VBS-Anforderung erfordert, wird die Offshore-Slippage-VBS signifikanter sein. Um zu zeigen, wie diese Zahlen aussehen könnten, haben wir unten eine Tabelle mit unserem Vorschlag beigefügt. Wie beim Market Cap Ratio verwenden wir einen anderen Multiplikator, wenn sich das System in einem gesunden Zustand befindet (3x bei einem mcap-Verhältnis < 0,1) im Vergleich zu einem ungesunden Zustand (10x bei einem mcap-Verhältnis > 0,1). 

Umbau-Verbaukappe pro Block

Der durch die oben genannten VBS-Maßnahmen bereitgestellte Schutz hinterlässt einen Angriffsvektor, bei dem ein erfahrener Benutzer eine große Konvertierung in viele kleinere Konvertierungen aufteilen könnte, die innerhalb desselben Blocks verarbeitet werden. Dies würde Slippage und Änderungen der Marktkapitalisierung oder der Spread-Verhältnisse vermeiden und ihnen eine günstigere VBS bieten, als das System dafür konzipiert ist. 

Unsere vorgeschlagene Lösung hierfür ist eine Obergrenze pro Block für die Menge an XHV, die off/onshore verlagert werden kann. Diese Obergrenze ist dynamisch und hängt von der Marktkapitalisierung von XHV ab. Die im Vorschlagsdokument beschriebene spezifische Formel wurde gewählt, um die Auswirkungen auf normale Benutzer zu begrenzen. Nachfolgend finden Sie eine Tabelle, wie hoch die Obergrenze bei verschiedenen XHV-Marktkapitalisierungen wäre.

Simulation

Um dies in einen Kontext zu stellen, haben wir im Vorschlagsdokument drei Simulationen erstellt. Wir haben unten eines eingefügt und freuen uns über Vorschläge für Szenarien, die wir modellieren können. Einzelheiten zum Vorschlag der Simulation finden Sie im Vorschlagsdokument. 

Was wäre, wenn VBS bereits vorhanden wäre, als XHV im Juni 2022 ein Tief von $0,42 erreichte, und unser xUSD-Wal damit begann, so viel Onshoring durchzuführen, wie es das System zuließ?

Die größte Annahme hier ist eine Startsicherheit von 500.000 XHV.

Wie Sie sehen können, konnte der Wal in den letzten 126 Tagen aufgrund des schlechten Zustands, in dem wir uns befinden, und einer entsprechend hohen VBS nur 76.000 XHV an Land gebracht haben.

Dies setzt voraus, dass der Wal während dieser Zeit kein XHV gekauft oder verkauft hätte und dass der Preis innerhalb dieser Spanne blieb.

Zusammenfassend

Zusammenfassend schlagen wir die folgenden Maßnahmen für die Haven 3.0-Tokenomik vor:

Allgemeine Verbaumaßnahmen

• 21 Tage Sperrzeit für alle XHV < > xUSD-Konvertierungen
• Mindest-VBS = 1
• Keine maximale VBS
• Verbaukappe pro Block
• 1,51 TP1T-Gebühren für alle XHV < > xUSD-Konvertierungen
• 1,51 TP1T-Gebühren für xUSD < > xAssets-Konvertierungen, wobei 1,21 TP1T an die staatliche Brieftasche und 0,31 TP1T für Miner gehen
• xAssets-Konvertierungsentsperrzeiten bleiben bei 48 Stunden
• VBS gilt nur für XHV < > xUSD-Konvertierungen

Offshore-spezifische Maßnahmen

• Variable VBS basierend auf dem Marktkapitalisierungsverhältnis von XHV und xAssets
• Variable Slippage VBS basierend auf der Erhöhung des Marktkapitalisierungsverhältnisses
• Maximale Offshore-Funktionalität

Onshore-spezifische Maßnahmen

• Variable VBS basierend auf der schlechtesten (höheren) VBS zwischen der Market Cap Ratio VBS und der Spread Ratio VBS
• Variable Slippage VBS basierend auf der Erhöhung des Spread Ratios
• Maximale Onshore-Funktionalität

Dies ist bei weitem der komplexeste Vorschlag, den wir bisher veröffentlicht haben, und auch die komplexeste Tokenomik, die wir umzusetzen versuchen.

Mitglieder der Economics Working Group stehen Ihnen zur Verfügung, um Ihre Fragen zu beantworten, aber nehmen Sie sich bitte die Zeit, den Vorschlag zu lesen und erneut zu lesen, um ein gutes Verständnis zu erlangen. Viele Fragen werden in diesem Vorschlag bereits beantwortet.

Ich danke Ihnen allen für Ihre unglaubliche Geduld und Unterstützung in diesen herausfordernden Zeiten.​