Initieel voorstel voor Haven 3.0-ontwikkeling

​

Het is belangrijk op te merken dat dit voorstel een conceptaanbeveling.
Er is nog geen beslissing genomen over onze tokenomics en niets staat vast.

Alles wat in dit document wordt gepresenteerd, zijn ideeën die verder met de gemeenschap moeten worden besproken, en zodra een overeenkomst is bereikt, zullen we een nieuwe aankondiging doen.

Sinds conversies waren gepauzeerd, zijn leden van de Economics Working Group (EWG) druk bezig geweest met het werken aan oplossingen om het Haven-netwerk terug te brengen naar een volledig functionele staat zonder de Haven-gemeenschap te openen voor verder risico op hyperinflatie, zoals is gebeurd met de Terra-ecosysteemhouders.

Dit werk zou moeilijker zijn geweest en langer hebben geduurd zonder inbreng van de gemeenschap.
De ideeën die door veel van onze leden naar voren zijn gebracht en zijn verzameld door xvrijwilligv in dit document, hebben het EWG-team een basis gegeven om mee te werken, wat ons uiteindelijk heeft geleid tot het voorstel dat hier wordt gepresenteerd.

We denken dat we met een werkbare oplossing zijn gekomen en we zouden graag discussies aangaan in onze #havenomics kanaal om feedback van de community te krijgen.
Deze discussies zijn belangrijk om het model te verfijnen en uiteindelijk tot een functionele oplossing te komen.

Voor sommigen lijken de hier voorgestelde maatregelen misschien hard en oneerlijk, maar we moeten niet vergeten dat het protocol momenteel in een slechte staat verkeert; we moeten ervoor zorgen dat het niet erger wordt en het protocol de tijd geven om te herstellen.

Het is de moeite waard om iedereen eraan te herinneren dat de Vault nooit bedoeld was om als handelsinstrument te worden gebruikt; we moedigen iedereen aan om XHV en xUSD op beurzen te verhandelen, wat de acceptatie zal stimuleren en de liquiditeit zal vergroten.

Terra's ontwikkelingspad gaf een hint en probeerde Bitcoin-pools te gebruiken voor een hybride ondersteunde algoritmische stablecoin voordat ze te groot zouden worden voor hun stabiliteitsmechanisme om extreme exogene schokken aan te kunnen.

Maar Haven is anders; het privacyaspect verhindert het gebruik van openbare blockchains, onderpand en stablecoins voor backing-doeleinden.

Het belangrijkste probleem met algoritmische stablecoins-modellen tot nu toe is dat het tokenomics-ontwerp betekent dat de stablecoin-prijs wordt ondersteund ten koste van de oorspronkelijke activaprijs.
In het geval van Haven betekent dit het kopen van goedkope xUSD om in XHV te slaan en vervolgens de XHV op de markt te verkopen. Dit zorgt voor een constante onderdrukking van de oorspronkelijke activaprijs en als de oorspronkelijke activaprijs voor onbepaalde tijd daalt, kan dit resulteren in een dodelijke spiraal en een volledig verlies van vertrouwen in de stablecoin.

Iets contra-intuïtief, een tokenomics-ontwerp dat geen prioriteit geeft aan de stablecoin-prijs en in plaats daarvan de oorspronkelijke activaprijs beschermt, heeft een langere levensduur als ecosysteem en daarom meer vertrouwen in de waarde van de stablecoin.

Dus het EWG-team kwam met een nieuw idee; Haven verdubbelt het "je eigen bank zijn" en zal onderpand eisen in de vorm van XHV om de shoring-functie te gebruiken.

Het nieuwe idee kan in één zin worden samengevat:

Voor Onshore/Offshore moet u de equivalente waarde van ontgrendeld XHV in uw kluis hebben.

We noemen dit idee Vault Backed Shoring, of VBS. Het is bedoeld om liquiditeitslimieten te geven voor het gebruik van de shoring-functie, die door elke gebruiker zelf worden bepaald.

Met deze nieuwe onderpandvereiste, die zowel het onderpand als de geslagen munten voor een langere periode zal vergrendelen, zullen shoringgebruikers constant worden blootgesteld aan en gekoppeld aan de volatiliteit van het basisonderpand terwijl ze actief de protocolaanvoernummers wijzigen.

Ze zullen de ondersteuningsfunctie niet kunnen gebruiken als ze hun XHV-onderpand verkopen en XHV niet in hun kluizen houden, waardoor ze zich niet volledig kunnen terugtrekken uit het volatiele systeem terwijl de gemeenschap de tegenovergestelde positie betaalt met verhoogde inflatie.

Kortom, Vault Backed Shoring is bedoeld om te werken als zowel een snelheidsrem als een vereiste voor skin in het spel voor gebruikers van de shoring-functie.

NOTITIE: VBS is alleen vereist voor deelnemers die de shoring-functies gebruiken (XHV <-> xUSD), niet voor standaard XHV- of xAsset-overdrachten.

Onhoring voorbeeld:

Om 100 xUSD om te zetten in XHV, moet je ten minste $100 aan XHV in de kluis hebben, ontgrendeld.
Deze XHV ter waarde van $100 (bekend als onderpand) wordt vergrendeld voor de duur van de conversie, samen met het geld dat wordt geconverteerd.

Als de huidige prijs van XHV $0,50 is, betekent dit dat u minimaal 200 XHV (unlocked) in uw kluis moet hebben om 100 xUSD aan land te komen.
Na een succesvolle conversie met behulp van dit voorbeeld, heeft u 400 XHV voor een bepaalde periode vergrendeld (zie voorgestelde vergrendelingstijden verderop).

Offshoring voorbeeld:

Om 100 XHV om te zetten in xUSD, moet u minimaal dezelfde hoeveelheid XHV (100 in dit geval) in de kluis hebben, ontgrendeld.
Dit betekent dat u maximaal 50% van de XHV in de kluis kunt offshoren, op voorwaarde dat geen van de XHV is vergrendeld.

Voorgestelde sluistijden voor VBS

Zowel het geld als de onderpandvereiste worden geblokkeerd voor 21 dagen.

Als de gebruiker niet genoeg onderpand voor onshore heeft in een enkele conversie, vertraagt VBS het onhoring-proces door van een onhorer te eisen dat hij meerdere cycli van onshore doorloopt, en elke onshore duurt 21 dagen om te voltooien.

Om dit te illustreren, zijn hier een paar scenario's die laten zien hoeveel cycli en hoe lang het zou duren om het volledige bedrag aan xUSD in een kluis aan land te brengen.

Het eerste voorbeeld gebruikt een startbedrag van 10k XHV en het tweede voorbeeld gebruikt een startbedrag van 100k XHV.
Beide voorbeelden gebruiken een 1:1-onderpand, wat betekent dat het maximale dat u op een bepaald moment aan land kunt hebben, het maximale aantal ontgrendelde XHV is dat u in de kluis heeft.
In deel 2 van het voorstel zullen we zien dat het onderpand zal veranderen op basis van de stand van het protocol.

Het is gemakkelijk in te zien dat hoe meer ontgrendeld onderpand u in de kluis heeft, hoe minder cycli u nodig heeft om al uw xUSD volledig terug naar XHV te converteren.

De volgende paar scenario's gebruiken respectievelijk een stijgende en dalende XHV-prijs.

Hieruit kunnen we zien dat met een stijgende prijs in XHV, er minder onshore-cycli nodig zijn, maar dat u uiteindelijk minder XHV overhoudt dan u zou hebben gehad als u alle xUSD in één conversie had kunnen onshore maken.

Omgekeerd, als de prijs van XHV daalt, zijn er meer Onshore-cycli nodig om alle xUSD om te zetten, maar u krijgt uiteindelijk meer XHV.
Hoewel dit lijkt alsof het protocol wordt opgeblazen, houden deze scenario's geen rekening met de status van het protocol, waardoor het type inflatie zoals hierboven wordt voorkomen.
Dit brengt ons bij het volgende deel van het voorstel.

Het eerste deel van het voorstel was het beschrijven van het nieuwe idee rond VBS en hoe het zou worden geïmplementeerd.

Op zichzelf zal VBS echter niet noodzakelijk de inflatie stoppen, vooral omdat de prijs van XHV in de loop van de tijd daalt, zal het alleen de tijd verlengen die nodig is om het protocol op te blazen.

Daarom zijn andere maatregelen nodig om ongecontroleerde inflatie en walvismanipulatie tegen te gaan.

Marktkapitalisatieratio

Zoals veel leden van de gemeenschap al hebben opgemerkt door middel van discussies in ons havenomics-kanaal, is een van de beste manieren om de gezondheid van het protocol te meten door een verhouding te gebruiken van de gecombineerde Total Offshore Assets-marktkapitalisatie (TOAMcap) en de XHV-marktkapitalisatie (XHVMcap ).

Dit wordt eenvoudig berekend als:

Hoe lager het getal, hoe gezonder het protocol en omgekeerd.
Hoewel het een subjectief gegevenspunt is, wordt een zeer goede verhouding beschouwd als XHVmcap 10 keer die van TOAMcap is, dwz 0.1 met behulp van de bovenstaande formule.

Op het moment van schrijven (23 juni 2022) is het circulerende aanbod van XHV ~ 28,3 miljoen met een marktkapitalisatie van $16 miljoen (met behulp van de KuCoin-prijs van $0,567).
De marktkapitalisatie van de totale activa bedraagt ~$16 miljoen.
Dus de mcap-ratio die we nu hebben is bijna precies 1, wat wordt beschouwd als een slechte verhouding en daarom een ongezonde status van het protocol.

Mcap-ratio combineren met VBS

Een ongezonde status van het protocol kan op de volgende manieren worden bereikt:

• aanhoudende daling van de XHV-prijs
• zeer grote, enkele conversies
• te veel offshoring
• te veel onhoring, wat kan leiden tot verkoopdruk op de open markt
• elke combinatie van de bovenstaande punten

Als we de status van het protocol (mcap-ratio) combineren met ons VBS-model, kunnen we het ondersteuningsmechanisme verder beperken om ervoor te zorgen dat het systeem niet te veel naar een ongezonde toestand slingert.

De manier waarop we dit voorstellen voor Onshores en Offshores is verschillend.

ONSHORE

Voor Onshores zullen we het benodigde onderpand verhogen naarmate de mcap-ratio toeneemt, wat betekent dat u meer XHV in uw kluis moet hebben voor hetzelfde bedrag van xUSD wanneer het protocol neigt naar een slechte staat.

Laten we aannemen dat de verhouding 0,5 is, het protocol gaat richting een ongezonde toestand. Dit betekent dat u niet langer een 1:1-onderpand kunt gebruiken om uw xUSD onshore te maken.
Een dynamische berekening voor deze verhouding had kunnen komen tot een onderpand van 1:3, wat betekent dat u 3 keer zoveel XHV in uw kluis zou moeten hebben als de hoeveelheid XHV die u aan land probeert te brengen.

Laten we, om dit beter te visualiseren, hetzelfde scenario van vroeger gebruiken: een XHV-bedrag van 10k starten met een constante prijs, maar deze keer met een onderpand van 1:3.

Met een 1:1-onderpand van het vorige voorbeeld, zouden we 7 onshores nodig hebben gehad om alle xUSD volledig om te zetten in XHV.
Met een 1:3 onderpand, zoals hierboven, is het aantal onshores toegenomen tot 17, waardoor een heel jaar nodig is om alle xUSD om te zetten in XHV.

Laten we ook hetzelfde scenario vergelijken, maar met een startend XHV-bedrag van 100k.

Voorheen, met een 1:1-onderpand, zou het 4 onshores (84 dagen) hebben gekost om alle xUSD om te zetten.
Met een onderpand van 1:3 is dit gestegen tot 9 onshores, ofwel 189 dagen.

Natuurlijk zijn deze scenario's vrij onrealistisch in de echte wereld; het is onmogelijk om markt- en prijsschommelingen, fundamentals, sentiment, conversietactieken, enz. te voorspellen.

De conclusie die we hieruit kunnen trekken is dat naarmate de status van het protocol steeds slechter wordt, ook de hoeveelheid onderpand die nodig is om xUSD naar XHV om te zetten, toeneemt, wat op zijn beurt het aantal cycli en de tijd die nodig is om het volledige bedrag aan land te brengen toeneemt.

OFFSHORE

Voor Offshores is het huidige concept om het onderpand op 1:1 te houden, maar we zullen de vergoedingen verhogen naarmate de mcap-ratio toeneemt. Verder zullen we ook slippage-vergoedingen toevoegen voor grotere conversies die de status van het protocol van goed of slecht naar slechter zouden maken.

NOTITIE: De reden dat we geen andere vergoedingen voor Onshores overwegen dan de standaard conversievergoedingen, is omdat men denkt dat dit xUSD zou verlagen, wat een neerwaartse spiraal van de prijs op de open markt zou kunnen veroorzaken.

Offshore – Conversiekosten

Wij zijn van mening dat het in het beste belang van het protocol is om het grootste deel van de vergoedingen te verbranden om de inflatie onder controle te houden, maar ook om voldoende vergoedingen over te laten voor de operationele kosten van het project, plus lonen.
Voor de toepassing van dit voorstel gaan we uit van een minimum van 0,5% aan vergoedingen voor de schatkist, waarbij een eventueel overschot wordt verbrand.
Exacte cijfers worden in een later stadium afgesproken.

Om de conversiekosten te berekenen, gebruiken we een eenvoudige machtsverheffing tussen de mcap-ratio en een getal dat 2 is of er dichtbij ligt, +/- enkele decimalen.
Als het aantal te hoog is, wordt de berekening te snel exponentieel, wat dit onbruikbaar zou maken.

Beschouw om dit te illustreren het volgende voorbeeld, waarin we verschillende niveaus van mcap-ratio's simuleren met 4 verschillende niveaus van exponenten: [1.6], [1.8], [2] en [2.2]
We stellen ook een minimum (0.5%) en maximum (80%) in voor vergoedingen, waarbij 0,5% naar de schatkist gaat en de rest wordt verbrand.

Naarmate de verhouding toeneemt en de status van het protocol verslechtert, zullen de vergoedingen voor eventuele offshores dienovereenkomstig worden verhoogd.
Het idee achter de hoge vergoedingen is niet om gebruikers te straffen, maar om hen te ontmoedigen het protocol in een slechte staat te brengen, en om te beschermen tegen ongecontroleerde inflatie door een groot deel van de vergoeding te verbranden.
 

Offshore – Slippagekosten

Slippage-vergoedingen zijn een extra maatregel om grote conversies op te vangen die de status van het protocol met een enkele conversie zouden verslechteren.

We zouden slippage-vergoedingen toevoegen aan de standaard conversiekosten zoals hierboven berekend. Kort gezegd zijn slippage fees de vergoedingen na een mogelijke verhoging van de ratio die wordt toegevoegd aan de standaard conversiekosten.

Hier is een voorbeeld waarbij de verhouding in een goede staat is voor een offshore, maar na een enkele conversie door een walvis, gaat deze in een slechte staat.

Andere Overwegingen

Is de Market Cap-ratio voldoende om de status van het protocol te berekenen?
Het antwoord is nee.

Er is nog iets om rekening mee te houden dat we nog niet hebben genoemd; de verspreiding verhouding tussen TOAMcap en XHVMcap.

De staat van het protocol waarin we ons nu bevinden, dat wil zeggen ongezond, betekent dat we niet veel conversies door het systeem zullen hebben omdat het ofwel te duur is, ofwel te veel zekerheden zou vergen.
Dit kan echter veranderen zodra de prijs van XHV stijgt tot een niveau waarop de marktkapitalisatieverhouding gunstig wordt voor onshores.

Naarmate mensen aan land gaan en de prijs van XHV stijgt, wordt de spreiding tussen TOAMcap en XHVMcap sneller groter, wat meer onshore stimuleert en het aanbod opdrijft.
Dit zou kunnen doorgaan totdat alle xUSD is omgezet in XHV en het circulerende aanbod van XHV enorm zou zijn opgeblazen.

Om dit tegen te gaan, zouden we de spreadratio tussen de twee caps kunnen berekenen tegen de XHV-prijs, en als de spread te groot wordt, zouden we soortgelijke beperkingen kunnen toepassen op conversies, zelfs als de marketcapratio in een goede staat is.

Onderstaande simulatiegrafiek laat zien hoe dit berekend kan worden.
Wanneer de marktkapitalisatieratio laag is (gezonde toestand – blauwe lijn), maar de spreadratio hoog is (groene lijn), kunnen we het onderpand voor Onshores verhogen en de vergoedingen voor Offshores verhogen.

Samenvattend stellen we de volgende maatregelen voor:

OFFSHORING

1. VBS met 1:1 onderpand, plus vergrendelingstijd (21 dagen voorgesteld).
2. Mcap-ratio om vergoedingen te bepalen op basis van de status van het protocol.
3. Slippage-vergoedingen zijn afhankelijk van de grootte van de offshore en de status van het protocol na een mogelijke offshore.
4. Spread ratio vergoedingen.
5. Geldt voor XHV -> xUSD-conversies.

ONSHORING

1. VBS met slottijd (21 dagen voorgesteld).
2. Minimaal onderpand van 1:1 en maximaal 1:3 of 1:4 (te bespreken).
3. Onderpand te bepalen naar de stand van het protocol.
4. Onderpand te bepalen door de spread ratio.
5. Basis conversiekosten.
6. Geldt voor xUSD -> XHV-conversies.

De belangrijkste conclusie in dit voorstel is dat discussies en feedback van de gemeenschap zich moeten concentreren rond het nieuwe idee, VBS.
We willen graag weten wat u ervan vindt en of u in het oog springende problemen in dit model ziet.
 

Er is veel ontwikkelingswerk aan de gang met wat we voorstellen en hoewel het ontwikkelteam dit uitwerkt, willen we de tijd nemen om de feedback van de gemeenschap over dit voorstel te horen, in het bijzonder de nieuwe benadering van VBS.

Leden kunnen dit het meest effectief bespreken in de #havenomics kanaal.​