Ursprünglicher Vorschlag für die Entwicklung von Haven 3.0

​

Es ist wichtig zu beachten, dass dieser Vorschlag a ist Empfehlungsentwurf.
Es wurde noch keine Entscheidung über unsere Tokenomics getroffen und nichts ist in Stein gemeißelt.

Alles, was in diesem Dokument vorgestellt wird, sind Ideen, die mit der Community weiter diskutiert werden sollen, und sobald eine Einigung erzielt wurde, werden wir eine weitere Ankündigung machen.

Seit Bekehrungen waren angehalten, haben Mitglieder der Economics Working Group (EWG) fleißig an Lösungen gearbeitet, um das Haven-Netzwerk wieder in einen voll funktionsfähigen Zustand zu versetzen, ohne die Haven-Community einem weiteren Risiko einer Hyperinflation auszusetzen, wie es den Inhabern des Terra-Ökosystems passiert ist.

Diese Arbeit wäre schwieriger gewesen und hätte länger gedauert ohne den Input der Community.
Die Ideen, die von vielen unserer Mitglieder vorgebracht und von gesammelt wurden xFreiwilligv im dieses Dokument, haben dem EWG-Team eine Arbeitsgrundlage gegeben, die uns letztendlich zu dem hier vorgestellten Vorschlag geführt hat.

Wir glauben, dass wir eine praktikable Lösung gefunden haben, und wir würden gerne Diskussionen in unserem eröffnen #avenomik Kanal, um Feedback von der Community zu erhalten.
Diese Diskussionen werden wichtig sein, um das Modell zu verfeinern und schließlich zu einer funktionalen Lösung zu kommen.

Manchen mögen die hier vorgeschlagenen Maßnahmen hart und unfair erscheinen, aber wir müssen bedenken, dass sich das Protokoll derzeit in einem schlechten Zustand befindet; Wir müssen sicherstellen, dass es nicht schlimmer wird, und dem Protokoll Zeit geben, sich zu erholen.

Es lohnt sich, jeden daran zu erinnern, dass der Tresor niemals als Handelsinstrument verwendet werden sollte; Wir ermutigen jeden, XHV und xUSD an Börsen zu handeln, was die Akzeptanz fördert und die Liquidität erhöht.

Der Entwicklungspfad von Terra gab einen Hinweis und versuchte, Bitcoin-Pools für einen algorithmischen Stablecoin mit Hybridunterstützung zu verwenden, bevor sie zu groß für ihren Stabilitätsmechanismus werden würden, um extreme exogene Schocks zu bewältigen.

Aber Haven ist anders; Der Datenschutzaspekt verhindert die Verwendung öffentlicher Blockchains, Sicherheiten und Stablecoins zu Sicherungszwecken.

Das Hauptproblem bei algorithmischen Stablecoins-Modellen ist bisher, dass das Tokenomics-Design bedeutet, dass der Stablecoin-Preis zum Nachteil des nativen Vermögenspreises unterstützt wird.
Im Fall von Haven bedeutet dies, billige xUSD zu kaufen, um sie in XHV zu prägen und dann den XHV auf dem Markt zu verkaufen. Dies führt zu einer ständigen Unterdrückung des einheimischen Vermögenspreises, und wenn der einheimische Vermögenspreis auf unbestimmte Zeit sinkt, kann dies zu einer Todesspirale und einem vollständigen Vertrauensverlust in die Stablecoin führen.

Etwas kontraintuitiv hat ein Tokenomics-Design, das den Stablecoin-Preis nicht priorisiert und stattdessen den nativen Vermögenspreis schützt, eine längere Lebensdauer als Ökosystem und daher ein größeres Vertrauen in den Wert des Stablecoins.

Also hatte das EWG-Team eine neue Idee; Haven verdoppelt sich darauf, „Ihre eigene Bank zu sein“ und wird Sicherheiten in Form von XHV verlangen, um die Shoring-Funktion nutzen zu können.

Die neue Idee lässt sich in einem Satz zusammenfassen:

Für Onshore/Offshore müssen Sie den Gegenwert von freigeschaltetem XHV in Ihrem Tresor haben.

Wir nennen diese Idee Vault Backed Shoring oder VBS. Es soll Liquiditätslimits für die Nutzung der Shoring-Funktion bereitstellen, die von jedem Nutzer selbst festgelegt werden.

Mit dieser neuen Sicherheitsanforderung, die sowohl die Sicherheit als auch die geprägten Münzen für einen längeren Zeitraum sperrt, werden Shoring-Benutzer ständig der Volatilität der Basissicherheit ausgesetzt und mit ihr verbunden sein, während sie aktiv die Protokollversorgungsnummern ändern.

Sie können die Shoring-Funktion nicht nutzen, wenn sie ihre XHV-Sicherheiten verkaufen und XHV nicht in ihren Tresoren halten, was sie daran hindert, sich vollständig aus dem volatilen System „auszuklinken“, während die Gemeinschaft die entgegengesetzte Position mit erhöhter Inflation bezahlt.

Kurz gesagt, Vault Backed Shoring soll sowohl als Geschwindigkeitsbremse als auch als Voraussetzung für Haut im Spiel für Benutzer der Shoring-Funktion dienen.

HINWEIS: VBS wird nur für Teilnehmer benötigt, die die Shoring-Funktionen (XHV <-> xUSD) nutzen, nicht die standardmäßigen XHV- oder xAsset-Transfers.

Onshoring-Beispiel:

Um 100 xUSD in XHV umzuwandeln, müssen Sie XHV im Wert von mindestens $100 entsperrt im Tresor haben.
Diese XHV im Wert von $100 (bekannt als Sicherheit) wird für die Dauer der Umwandlung zusammen mit den umgewandelten Geldern gesperrt.

Wenn der aktuelle Preis von XHV $0,50 beträgt, bedeutet dies, dass Sie mindestens 200 XHV (freigeschaltet) in Ihrem Tresor haben müssen, um 100 xUSD an Land zu ziehen.
Nach erfolgreicher Konvertierung anhand dieses Beispiels haben Sie 400 XHV für einen bestimmten Zeitraum gesperrt (siehe vorgeschlagene Sperrzeiten weiter unten).

Offshoring-Beispiel:

Um 100 XHV in xUSD umzuwandeln, müssen Sie mindestens die gleiche Menge an XHV (in diesem Fall 100) im Tresor haben, entsperrt.
Das bedeutet, dass Sie immer nur maximal 50% der im Tresor aufbewahrten XHV offshore können, vorausgesetzt, keines der XHV ist gesperrt.

Vorgeschlagene Sperrzeiten für VBS

Sowohl die Mittel als auch die Sicherheitsanforderungen werden gesperrt 21 Tage.

Wenn der Benutzer in einer einzigen Konvertierung nicht genügend Sicherheiten für Onshore hält, verlangsamt VBS den Onshoring-Prozess, indem ein Onshore-Mitarbeiter mehrere Onshoring-Zyklen durchlaufen muss, und jeder Onshore-Prozess dauert 21 Tage.

Um dies zu veranschaulichen, sind hier ein paar Szenarien, die zeigen, wie viele Zyklen und wie lange es dauern würde, den vollen xUSD-Betrag in einem Tresor an Land zu bringen.

Das erste Beispiel verwendet einen Startbetrag von 10.000 XHV und das zweite Beispiel verwendet einen Startbetrag von 100.000 XHV.
Beide Beispiele verwenden eine 1:1-Sicherheit, was bedeutet, dass Sie zu einem bestimmten Zeitpunkt höchstens die maximale Menge an freigeschaltetem XHV im Tresor haben können.
In Teil 2 des Vorschlags werden wir sehen, dass sich die Sicherheiten je nach Stand des Protokolls ändern werden.

Es ist leicht zu erkennen, dass je mehr freigeschaltete Sicherheiten Sie im Tresor haben, desto weniger Zyklen benötigen Sie, um alle Ihre xUSD vollständig zurück in XHV umzuwandeln.

Die nächsten Szenarien verwenden einen steigenden bzw. fallenden XHV-Preis.

Daraus können wir ersehen, dass mit einem steigenden Preis in XHV weniger Onshore-Zyklen erforderlich sind, aber Sie am Ende mit weniger XHV insgesamt auskommen, als Sie hätten, wenn Sie in der Lage gewesen wären, alle xUSD in einer Konvertierung an Land zu bringen.

Umgekehrt, wenn der Preis von XHV sinkt, sind mehr Onshore-Zyklen erforderlich, um den gesamten xUSD umzuwandeln, aber Sie erhalten am Ende mehr XHV.
Obwohl dies so aussieht, als würde es das Protokoll aufblähen, berücksichtigen diese Szenarien nicht den Zustand des Protokolls, wodurch die oben gezeigte Art der Inflation verhindert wird.
Damit kommen wir zum nächsten Teil des Vorschlags.

Der erste Teil des Vorschlags beschrieb die neuartige Idee rund um VBS und wie sie implementiert werden würde.

VBS allein wird jedoch die Inflation nicht unbedingt stoppen, insbesondere wenn der Preis von XHV im Laufe der Zeit sinkt, es wird nur die Zeit verlängern, die zum Aufblähen des Protokolls erforderlich ist.

Daher sind andere Maßnahmen erforderlich, um einer unkontrollierten Inflation und Walmanipulation entgegenzuwirken.

Marktkapitalisierungsverhältnis

Wie viele Community-Mitglieder bereits durch Diskussionen in unserem Havenomics-Kanal festgestellt haben, ist eine der besten Möglichkeiten, den Zustand des Protokolls zu messen, die Verwendung eines Verhältnisses der kombinierten Marktkapitalisierung der gesamten Offshore-Vermögenswerte (TOAMcap) und der XHV-Marktkapitalisierung (XHVMcap ).

Dies wird einfach berechnet als:

Je niedriger die Zahl, desto gesünder das Protokoll und umgekehrt.
Obwohl es sich um einen subjektiven Datenpunkt handelt, wird ein sehr gutes Verhältnis angenommen, wenn XHVmcap das 10-fache von TOAMcap beträgt, d. h 0.1 mit obiger Formel.

Zum Zeitpunkt der Erstellung dieses Artikels (23. Juni 2022) beträgt das zirkulierende Angebot von XHV ~28,3 Millionen mit einer Marktkapitalisierung von $16 Millionen (unter Verwendung des KuCoin-Preises von $0,567).
Die Marktkapitalisierung des Gesamtvermögens liegt bei ~$16 Millionen.
Das mcap-Verhältnis, das wir gerade haben, ist also fast genau 1, was als schlechtes Verhältnis und daher als ungesunder Zustand des Protokolls angesehen wird.

Kombinieren des mcap-Verhältnisses mit VBS

Ein ungesunder Zustand des Protokolls kann auf folgende Weise erreicht werden:

• anhaltender Rückgang des XHV-Preises
• sehr große, einzelne Konvertierungen
• zu viel Offshoring
• zu viel Onshoring, was zu Verkaufsdruck auf dem freien Markt führen kann
• jede Kombination der oben genannten Punkte

Wenn wir den Zustand des Protokolls (Mcap-Verhältnis) mit unserem VBS-Modell kombinieren, können wir den Shoring-Mechanismus weiter einschränken, um sicherzustellen, dass das System nicht zu sehr in einen ungesunden Zustand übergeht.

Die Art und Weise, wie wir dies für Onshores und Offshores vorschlagen, ist unterschiedlich.

ANLAND

Für Onshores erhöhen wir die erforderlichen Sicherheiten mit steigendem Mcap-Verhältnis, was bedeutet, dass Sie für den gleichen Betrag von xUSD mehr XHV in Ihrem Tresor haben müssen, wenn das Protokoll zu einem schlechten Zustand neigt.

Nehmen wir an, das Verhältnis liegt bei 0,5, das Protokoll steuert auf einen ungesunden Zustand zu. Dies bedeutet, dass Sie keine 1:1-Sicherheiten mehr verwenden können, um Ihre xUSD anzulegen.
Eine dynamische Berechnung für dieses Verhältnis hätte zu einer Sicherheit von 1:3 führen können, was bedeutet, dass Sie dreimal so viel XHV in Ihrem Tresor haben müssten wie die Menge an XHV, die Sie an Land bringen möchten.

Um dies besser zu veranschaulichen, verwenden wir das gleiche Szenario wie zuvor: Beginnen Sie mit einem XHV-Betrag von 10.000 mit einem konstanten Preis, aber diesmal mit einer Sicherheit von 1:3.

Mit einer 1:1-Sicherheit aus dem vorherigen Beispiel hätten wir 7 Onshores benötigt, um alle xUSD vollständig in XHV umzuwandeln.
Mit einer 1:3-Sicherheit, wie oben, ist die Anzahl der Onshores auf 17 gestiegen, was ein ganzes Jahr benötigt, um alle xUSD in XHV umzuwandeln.

Vergleichen wir auch das gleiche Szenario, aber mit einem XHV-Startbetrag von 100.000.

Zuvor hätte es mit einer 1:1-Sicherheit 4 Onshore (84 Tage) gedauert, um alle xUSD umzuwandeln.
Mit einer Sicherheit von 1:3 hat es sich auf 9 Onshores oder 189 Tage erhöht.

Natürlich sind diese Szenarien in der realen Welt ziemlich unrealistisch; Es ist unmöglich, Markt- und Preisschwankungen, Fundamentaldaten, Stimmung, Konversionstaktiken usw. vorherzusagen.

Die Schlussfolgerung, die wir daraus ziehen können, ist, dass sich mit zunehmender Verschlechterung des Zustands des Protokolls auch die Menge an Sicherheiten verschlechtert, die für die Umwandlung von xUSD in XHV benötigt werden, was wiederum die Anzahl der Zyklen und die Zeit erhöht, die benötigt wird, um den vollen Betrag an Land zu bringen.

OFFSHORES

Für Offshores besteht das aktuelle Konzept darin, die Sicherheiten bei 1:1 zu halten, aber wir werden die Gebühren erhöhen, wenn das Mcap-Verhältnis steigt. Darüber hinaus werden wir auch Slippage-Gebühren für größere Konvertierungen hinzufügen, die den Zustand des Protokolls von gut oder schlecht zu schlechter machen würden.

HINWEIS: Der Grund, warum wir außer den Standardkonvertierungsgebühren keine Gebühren für Onshores in Betracht ziehen, liegt darin, dass davon ausgegangen wird, dass dies den xUSD depegieren würde, was zu einer Abwärtsspirale des Preises auf dem offenen Markt führen könnte.

Offshore – Umwandlungsgebühren

Wir glauben, dass es im besten Interesse des Protokolls ist, den Großteil der Gebühren zu verbrennen, um die Inflation unter Kontrolle zu halten, aber auch genügend Gebühren für die Betriebskosten des Projekts zuzüglich der Löhne zu lassen.
Für die Zwecke dieses Vorschlags gehen wir von einem Minimum von 0,51 TP1T an Gebühren für die Staatskasse aus, wobei jeder Überschuss verbrannt wird.
Genaue Zahlen werden zu einem späteren Zeitpunkt vereinbart.

Um die Umrechnungsgebühren zu berechnen, verwenden wir eine einfache Potenzierungsoperation zwischen dem mcap-Verhältnis und einer Zahl, die 2 oder sehr nahe daran liegt, +/- ein paar Dezimalstellen.
Wenn die Zahl zu hoch ist, wird die Berechnung zu schnell exponentiell, was dies unbrauchbar machen würde.

Betrachten Sie zur Veranschaulichung das folgende Beispiel, in dem wir verschiedene Ebenen von mcap-Verhältnissen mit 4 verschiedenen Exponentenebenen simulieren: [1.6], [1.8], [2] und [2.2]
Wir legen auch ein Minimum (0,51 TP1T) und ein Maximum (801 TP1T) an Gebühren fest, wobei 0,51 TP1T an die Staatskasse gehen und der Rest verbrannt wird.

Wenn das Verhältnis zunimmt und sich der Zustand des Protokolls verschlechtert, werden die Gebühren für Offshores entsprechend erhöht.
Die Idee hinter den hohen Gebühren ist nicht, Benutzer zu bestrafen, sondern sie davon abzuhalten, das Protokoll in einen schlechten Zustand zu versetzen, und sich vor unkontrollierter Inflation zu schützen, indem ein großer Teil der Gebühr verbrannt wird.
 

Offshore – Slippage-Gebühren

Slippage-Gebühren sind eine zusätzliche Maßnahme, um große Konvertierungen abzufangen, die den Zustand des Protokolls mit einer einzigen Konvertierung verschlechtern würden.

Wir würden Slippage-Gebühren zu den oben berechneten Standardumrechnungsgebühren hinzufügen. Grundsätzlich sind Slippage-Gebühren die Gebühren nach einer möglichen Erhöhung des Verhältnisses, die zu den Standardumtauschgebühren hinzukommen.

Hier ist ein Beispiel, bei dem das Verhältnis vor einer Offshore-Phase in einem guten Zustand ist, aber nach einer einzigen Umwandlung durch einen Wal in einen schlechten Zustand versetzt wird.

Andere Überlegungen

Reicht das Marktkapitalisierungsverhältnis aus, um den Zustand des Protokolls zu berechnen?
Die Antwort ist nein.

Es gibt noch etwas zu beachten, das wir noch nicht erwähnt haben; das Verbreitung Verhältnis zwischen TOAMcap und XHVMcap.

Der Zustand des Protokolls, in dem wir uns jetzt befinden, dh ungesund, bedeutet, dass wir nicht viele Konvertierungen durch das System laufen lassen, weil es entweder zu teuer ist oder zu viele Sicherheiten erfordern würde.
Dies könnte sich jedoch ändern, sobald der Preis von XHV auf ein Niveau steigt, bei dem das Marktkapitalisierungsverhältnis für Onshores günstig wird.

Wenn die Leute anfangen, an Land zu gehen und der Preis von XHV steigt, weitet sich die Spanne zwischen TOAMcap und XHVMcap schneller aus, was mehr Anreize für Onshore gibt und das Angebot aufbläht.
Dies könnte so lange andauern, bis der gesamte xUSD in XHV umgewandelt wurde und das zirkulierende Angebot an XHV stark aufgeblasen wäre.

Um dem entgegenzuwirken, könnten wir das Spread-Verhältnis zwischen den beiden Caps gegenüber dem XHV-Preis berechnen, und wenn der Spread zu groß wird, könnten wir ähnliche Beschränkungen auf Konvertierungen anwenden, selbst wenn das Marktkapitalisierungsverhältnis in einem guten Zustand ist.

Das Simulationsdiagramm unten zeigt, wie dies berechnet werden könnte.
Wenn das Marktkapitalisierungsverhältnis niedrig ist (gesunder Zustand – blaue Linie), aber das Spread-Verhältnis hoch ist (grüne Linie), könnten wir die Sicherheiten für Onshores erhöhen und die Gebühren für Offshores erhöhen.

Zusammenfassend schlagen wir folgende Maßnahmen vor

OFFSHORING

1. VBS mit 1:1 Sicherheit, plus Sperrzeit (21 Tage vorgeschlagen).
2. Mcap-Verhältnis, um Gebühren basierend auf dem Zustand des Protokolls zu bestimmen.
3. Slippage-Gebühren hängen von der Größe des Offshore und dem Stand des Protokolls nach einem potenziellen Offshore ab.
4. Spread-Ratio-Gebühren.
5. Gilt für XHV -> xUSD-Konvertierungen.

ANLANDUNG

1. VBS mit Sperrzeit (21 Tage vorgeschlagen).
2. Mindestbesicherung 1:1, maximal 1:3 oder 1:4 (in Absprache).
3. Sicherheiten, die vom Status des Protokolls bestimmt werden.
4. Durch das Spread-Verhältnis zu bestimmende Sicherheiten.
5. Grundlegende Konvertierungsgebühren.
6. Gilt für Konvertierungen von xUSD -> XHV.

Die wichtigste Erkenntnis aus diesem Vorschlag ist, dass sich Diskussionen und Feedback aus der Community auf die neue Idee VBS konzentrieren sollten.
Wir würden wirklich gerne wissen, was Sie denken und ob Sie irgendwelche eklatanten Probleme in diesem Modell sehen.
 

Es gibt erhebliche Entwicklungsarbeit mit dem, was wir vorschlagen, und während das Entwicklerteam dies prüft, möchten wir uns die Zeit nehmen, das Community-Feedback zu diesem Vorschlag zu hören, insbesondere zum neuartigen Ansatz von VBS.

Die Mitglieder können dies am effektivsten in der diskutieren #avenomik Kanal.​