Haven 3.0 Tokenomics-voorstel (licht)

Om het volledige voorstel te bekijken, klik op hier.
U kunt ook een PDF-versie van het volledige voorstel downloaden van hier.

Overzicht

De afgelopen maanden heeft de Economics Working Group (EWG) in nauwe samenwerking met de Haven-ontwikkelaars gewerkt aan een voorstel voor een specifieke implementatie voor de Vault Backed Shoring (VBS) voorstel dat op 7 juli 2022 door de gemeenschap werd goedgekeurd. 

Bovenaan deze pagina staat een link naar het volledige PDF-voorstel van 32 pagina's van de EWG aan de gemeenschap. Het verklaart de omstandigheden die ons hier hebben geleid, de theorie achter VBS, onze voorgestelde formules en simulaties ervan in actie. Het is een licht technisch document en we raden iedereen aan om het zo goed mogelijk door te lezen. Deze blogpost zal echter een samengevatte versie zijn die bedoeld is voor meer niet-technische lezers. 

Het Haven-protocol bevindt zich momenteel in een ongezonde staat omdat de bescherming die werd geboden door eerdere configuraties van de offshoring/onshoring-mechanismen van Haven onvoldoende was. Onze vorige tokenomics waren gericht op het proberen de marktprijs van xUSD richting $1 te handhaven, maar dit ging ten koste van de XHV-prijs. Dit werd door verschillende partijen naar voren gebracht, wat voor forse inflatie zorgde en uiteindelijk leidde tot een dreigende doodsspiraal van de XHV-prijs. Deze crisis werd afgewend door het besluit van de EWG om de conversies in juni 2022 stop te zetten, omdat de acties van algemene gebruikers en in het bijzonder grote walvissen op weg waren om het protocol te vernietigen.

De EWG kwam in de daaropvolgende weken en na vele uren van debat tot de conclusie dat het te gemakkelijk was om te profiteren van de onbeperkte liquiditeit die de shoring-functies boden en tegelijkertijd beschermd te worden tegen het negatieve effect op de XHV-prijs. Tijdens onze discussies realiseerden we ons dat alle andere algoritmische stablecoins zich hadden gericht op het handhaven van de stablecoin-prijs in plaats van op de prijs van het activum dat de stablecoin ondersteunt en daarom een fundamentele fout hadden gemaakt. Voer VBS in.

VBS vereist dat een potentiële off/onshore van XHV een onderpand van XHV aanhoudt om de off/onshore uit te voeren. Als een gebruiker x hoeveelheid XHV wil offshoren, moet hij afzonderlijk y hoeveelheid XHV vasthouden die voor de duur van de conversie wordt vergrendeld. Omgekeerd, als een gebruiker b-bedrag van xUSD aan land wil, moet hij afzonderlijk c-bedrag XHV vasthouden dat gedurende de conversie wordt vergrendeld. Specifieke nummers zullen verderop worden behandeld.

Het doel is om iedereen die de off/onshore-functies wil gebruiken, bloot te stellen aan de XHV-prijs en dus de gezondheid van het Haven-protocol-ecosysteem. Als een gebruiker bijvoorbeeld zijn offshored xUSD op een later tijdstip onshore wil hebben, moet hij een XHV-saldo behouden of XHV op de markt kopen voordat hij een retourvlucht kan voltooien. 

Naast VBS stellen we drie andere wijzigingen voor die bedoeld zijn om het protocol en de duurzaamheid van het project te helpen beschermen: 

  • Slottijden 
  • Conversiekosten
  • Een limiet op het bedrag dat in elk blok kan worden omgezet 

De vergrendelingstijden en conversiekosten zijn het eenvoudigst, dus we zullen ze kort behandelen voordat we verder gaan met de VBS-onderpandvereiste en de conversie-shoring-cap per blok. 

Vergrendeltijden

Vergrendelingstijden geven een vertraging aan hoe snel fondsen kunnen worden off/onshored en vervolgens beschikbaar zijn om op de markt of off/onshore te worden verkocht. Het VBS-onderpand dat nodig is voor een conversie, wordt ook vergrendeld voor dezelfde tijdsduur als waarvoor geconverteerde fondsen zijn vergrendeld.

De sluistijden die we voorstellen zijn 21 dagen voor zowel offshores als onshores.

Conversiekosten

Oorspronkelijk hebben we een model voorgesteld waarbij dynamische vergoedingen zouden worden gebruikt als maatregel om het systeem te beschermen. Dit was echter om een aantal redenen onhoudbaar. In plaats daarvan stellen we 1.5% voor offshores en 1.5% voor onshores voor. De vergoedingen lijken misschien hoog, maar nu de schatkist uitgeput raakt en de middelen beperkt zijn door een sterk verlaagd percentage in volume voor conversies zodra VBS is geïmplementeerd, moeten we ervoor zorgen dat het project voldoende middelen ontvangt om de operationele kosten te dekken.

De huidige xUSD < > xAssets conversiekosten zijn 0,5% per conversie, waarvan 0,4% wordt verbrand en 0,1% gelijkelijk wordt verdeeld tussen miners en de governance-portemonnee.

Om ervoor te zorgen dat het protocol voldoende inkomsten krijgt via conversies, willen we de volgende wijzigingen doorvoeren:

  • xUSD < > xAssets Conversiekosten worden verhoogd naar 1,5%
  • 1.2% zou naar de governance-portemonnee worden verzonden
  • 0,3% zou naar mijnwerkers gaan (verhoging van 0,05%)

De tarieven zullen regelmatig worden herzien.

VBS

De hamvraag is precies hoeveel onderpand er nodig is om een stutfunctie te kunnen uitoefenen. Er zijn drie belangrijke factoren om te overwegen:

  • Het bedrag dat een gebruiker wil off/onshore
  • De huidige gezondheid van het XHV-ecosysteem voorafgaand aan de off/onshore
  • De potentiële inflatie/toekomstige gezondheid van het XHV-ecosysteem na de off/onshore

Door historische gegevensanalyse en het modelleren van mogelijke toekomstscenario's realiseerden we ons al snel dat de onderpandvereisten in het oorspronkelijke voorstel onvoldoende bescherming zouden bieden. Het einddoel is om een systeem te hebben dat gemakkelijk te gebruiken is, weinig onderpand vereist als het systeem gezond is, maar beschermt tegen ernstige inflatie wanneer het protocol in gevaar is. 

Gezien onze huidige ongezonde toestand is dit een uitdaging en omdat we nieuwe wegen inslaan, is ons huidige voorstel conservatief om het protocol te beschermen. Zodra we enige stabiliteit hebben bereikt, kunnen we de formules verfijnen om ze in de toekomst gebruiksvriendelijker te maken. 

Er zijn drie belangrijke componenten die worden gebruikt in onze VBS-onderpandberekeningen:

  • Market Cap Ratio – De verhouding tussen de waarde van XHV en xAssets in omloop
  • Spread Ratio - Een maatstaf voor de "afstand" tussen XHV-marktkapitalisatie en xAssets-marktkapitalisatie
  • Slippage - De impact die een transactie zal hebben op de toestand van het ecosysteem

De specifieke formules staan ter discussie in de gemeenschap en zijn terug te vinden in het voorsteldocument. Hieronder zullen we deze zo niet-technisch mogelijk samenvatten en voorbeelden geven.

De totale VBS-onderpandvereiste is:

Marktkapitalisatie of spreidingsratio VBS + Slippage VBS

De eerste deelberekening hangt er in eerste instantie van af of het een off/onshore is:

  • Offshores – Marktkapitalisatieratio 
  • Onshores – De grootste van de marktkapitalisatieratio en de spreadratio 

De marktkapitalisatieratio zal twee afzonderlijke functies gebruiken die afzonderlijke bereiken van de marktkapitalisatieratio dekken. We stellen voor om onder de 0,9 mcap ratio een minder agressieve formule te gebruiken om het systeem gemakkelijker te kunnen gebruiken en boven de 0,9 gebruiken we een meer exponentiële formule waardoor de onderpandbehoefte sterk stijgt. 

De Spread Ratio is alleen nodig als extra bescherming voor onhoring, omdat naarmate mensen aan land zijn, het aanbod van XHV stijgt, de mcap-ratio afneemt, de onderpandvereiste afneemt en er meer kans op inflatie ontstaat.

Voor onshore gebruiken we de slechtste van twee VBS-waarden tussen mcap en spread-ratio, wat betekent dat we bescherming krijgen over het hele bereik van de market cap-ratio.

De onderstaande tabel toont VBS-waarden voor een reeks mcap- en spreadratio's, en de bijbehorende, berekende VBS-waarden. De laatste kolom toont de werkelijke VBS-waarde die wordt gebruikt voor Onshores, de hoogste VBS van de twee, Mcap en Spread VBS.

slippen

Om te voorkomen dat de marktkapitalisatieverhouding te snel stijgt (verslechtert) door enkele, grote conversies, moeten we slippage in de vorm van VBS toevoegen aan de Initiële VBS, die is afgeleid van de initiële status van het protocol. Dit zal walvissen beperken die zeer grote bedragen omzetten met oneindige liquiditeit.

De slippage wordt voor offshores en onshores anders berekend.

Voor Offshores, nemen we de procentuele stijging van de Marktkapitalisatieratio op basis van hoeveel wordt omgezet.
Voor aan land, nemen we de procentuele stijging van de Verspreidingsratio.

De specifieke formules worden gedetailleerd beschreven in het voorsteldocument. Omdat onshores al aanvullende VBS-vereisten vereisen in vergelijking met offshores, zal de offshore slip VBS significanter zijn. Om te laten zien hoe deze cijfers eruit kunnen zien, hebben we hieronder een tabel met onze suggestie toegevoegd. Net als bij de Market Cap Ratio, gebruiken we een andere multipler wanneer het systeem in een gezonde toestand is (3x wanneer mcap ratio < 0,1) in vergelijking met een ongezonde toestand (10x wanneer mcap ratio > 0,1). 

Ombouw stutkap per blok

De bescherming die door de bovenstaande VBS-maatregelen wordt geboden, laat een aanvalsvector achter waar een geavanceerde gebruiker een grote conversie kan opsplitsen in vele kleinere conversies die binnen hetzelfde blok worden verwerkt. Dit zou slippage en eventuele wijzigingen in de marktkapitalisatie of spreadratio's voorkomen en ze een gunstiger VBS bieden dan waarvoor het systeem is ontworpen. 

Onze voorgestelde oplossing hiervoor is een limiet per blok op de hoeveelheid XHV die off/onshore kan zijn. Deze cap is dynamisch en hangt af van de marktkapitalisatie van XHV. De specifieke formule die in het voorsteldocument wordt beschreven, is gekozen om de impact op de reguliere gebruikers te beperken. Hieronder vindt u een tabel van wat de cap zou zijn bij verschillende XHV-marktcaps.

Simulatie

Om dit in de juiste context te plaatsen, hebben we drie simulaties in het voorsteldocument gemaakt. We hebben er hieronder een opgenomen en verwelkomen suggesties voor scenario's die we kunnen modelleren. Details over hoe u de simulatie kunt voorstellen, vindt u in het voorsteldocument. 

Wat als VBS al aanwezig was toen XHV in juni 2022 een dieptepunt van $0,42 bereikte, en onze xUSD-walvis begon zoveel mogelijk aan te walsen als het systeem hem zou toestaan?

De grootste aanname hier is een startonderpand van 500k XHV.

Zoals je kunt zien, kon de walvis de afgelopen 126 dagen slechts 76k XHV aan land hebben gebracht, vanwege de slechte staat waarin we ons bevinden, en een overeenkomstige hoge VBS.

Dit veronderstelt dat de walvis in die tijd geen XHV zou hebben gekocht of verkocht, en dat die prijs binnen dit bereik bleef.

Samengevat

Samenvattend stellen we de volgende maatregelen voor de Haven 3.0-tokenomics voor:

Generieke stutmaatregelen

  • 21 dagen vergrendelingstijd voor alle XHV < > xUSD-conversies
  • Minimale VBS = 1
  • Geen maximale VBS
  • Schoorkap per blok
  • 1.5%-kosten voor alle XHV < > xUSD-conversies
  • 1.5%-kosten voor xUSD <> xAssets-conversies, waarbij 1.2% naar de gov-portemonnee gaat en 0.3% voor miners
  • xAssets conversie ontgrendelingstijden blijven op 48 uur
  • VBS alleen van toepassing op XHV < > xUSD-conversies

Offshore specifieke maatregelen

  • Variabele VBS gebaseerd op de Market Cap Ratio van XHV en xAssets
  • Variabele Slippage VBS gebaseerd op de verhoging van de Market Cap Ratio
  • Max Offshore-functionaliteit

Specifieke maatregelen aan land

  • Variabele VBS gebaseerd op de slechtste (hogere) VBS tussen de Market Cap Ratio VBS en Spread Ratio VBS
  • Variabele Slippage VBS gebaseerd op de toename van de Spread Ratio
  • Max. Onshore-functionaliteit


Dit is verreweg het meest complexe voorstel dat we tot nu toe hebben gepubliceerd, en ook de meest complexe tokenomics die we proberen te implementeren.

Leden van de Economische Werkgroep zullen beschikbaar zijn om al uw vragen te beantwoorden, maar neem alstublieft de tijd om het voorstel te lezen en opnieuw te lezen om een goed begrip te krijgen. In dit voorstel zullen al veel vragen beantwoord zijn.

Bedankt allemaal voor jullie ongelooflijke geduld en steun in deze uitdagende tijden.​

nl_NL_formalNederlands (Formeel)