Proposition de Tokenomics Haven 3.0 (léger)

Pour voir la proposition complète, cliquez sur ici.
Vous pouvez également télécharger une version PDF de la proposition complète à partir de ici.

Aperçu

Au cours des derniers mois, le groupe de travail sur l'économie (EWG) a travaillé en étroite coordination avec les développeurs de Haven pour produire une proposition d'implémentation spécifique pour l'étaiement soutenu par la voûte (VBS). proposition qui a été approuvé par vote communautaire le 7 juillet 2022. 

En haut de cette page se trouve un lien vers la proposition PDF complète de 32 pages de l'EWG à la communauté. Il explique les circonstances qui nous ont amenés ici, la théorie derrière VBS, nos formules proposées et les simulations de celui-ci en action. Il s'agit d'un document légèrement technique et nous encourageons chacun à le lire au mieux de ses capacités. Cependant, ce billet de blog sera une version résumée destinée à des lecteurs plus non techniques. 

Le protocole Haven est actuellement dans un état défectueux car la protection fournie par les configurations précédentes des mécanismes d'offshoring/onshoring de Haven était insuffisante. Nos tokenomics précédentes se concentraient sur la tentative de maintenir le prix du marché de xUSD vers $1, mais cela se faisait au détriment du prix XHV. Cela a été exposé par diverses parties, ce qui a provoqué une inflation importante et a finalement conduit à une spirale mortelle imminente du prix XHV. Cette crise a été évitée par la décision de l'EWG d'arrêter les conversions en juin 2022 car les actions des utilisateurs généraux et, en particulier, des grandes baleines étaient en passe de détruire le protocole.

Dans les semaines qui ont suivi et après de nombreuses heures de débat, l'EWG est arrivé à la conclusion qu'il était trop facile de bénéficier de la liquidité illimitée qu'offraient les fonctions de shoring tout en étant protégé de l'effet négatif sur le prix du XHV. Au cours de nos discussions, nous avons réalisé que tous les autres stablecoins algorithmiques s'étaient concentrés sur le maintien du prix du stablecoin plutôt que sur le prix de l'actif supportant le stablecoin et avaient donc commis une erreur fondamentale. Entrez VBS.

VBS exige qu'un éventuel off/onshore de XHV détienne un montant de garantie de XHV pour effectuer l'off/onshore. Si un utilisateur souhaite délocaliser x quantité de XHV, il doit détenir séparément y quantité de XHV qui sera verrouillée pendant la durée de la conversion. Inversement, si un utilisateur souhaite onshore un montant b de xUSD, il doit détenir séparément un montant c de XHV qui sera verrouillé pendant la durée de la conversion. Les numéros spécifiques seront couverts plus bas.

Le but est de faire en sorte que tous ceux qui souhaitent utiliser les fonctions off/onshore soient exposés au prix XHV et donc à la santé de l'écosystème du protocole Haven. Par exemple, si un utilisateur souhaite débarquer son xUSD délocalisé à une date ultérieure, il doit conserver un solde XHV ou acheter du XHV sur le marché avant de pouvoir effectuer un aller-retour. 

Aux côtés de VBS, nous proposons trois autres modifications conçues pour aider à protéger le protocole et la pérennité du projet : 

• Heures de verrouillage 
• Frais de conversion
• Un plafond sur le montant qui peut être converti dans chaque bloc 

Les temps de verrouillage et les frais de conversion sont les plus simples, nous les couvrirons donc brièvement avant de passer à l'exigence de garantie VBS et au plafond de conversion par bloc. 

Temps de verrouillage

Les temps de blocage retardent la rapidité avec laquelle les fonds peuvent être délocalisés/délocalisés, puis disponibles pour être vendus sur le marché ou délocalisés/délocalisés. La garantie VBS requise pour une conversion sera également verrouillée pendant la même durée que celle pendant laquelle les fonds convertis sont verrouillés.

Les durées d'écluse que nous proposons sont de 21 jours pour l'offshore et l'onshore.

Frais de conversion

À l'origine, nous avons proposé un modèle où les frais dynamiques seraient utilisés comme mesure de protection du système. Cependant, cela était intenable pour un certain nombre de raisons. Au lieu de cela, nous suggérons 1.5% pour les Offshores et 1.5% pour les Onshores. Les frais peuvent sembler élevés, mais avec la trésorerie épuisée et les fonds limités grâce à un pourcentage de volume considérablement réduit pour les conversions une fois VBS mis en œuvre, nous devons nous assurer que le projet reçoit suffisamment de fonds pour soutenir ses coûts opérationnels.

Le courant xUSD < > xAssets frais de conversion sont de 0,5% par conversion, dont 0,4% sont brûlés et 0,1% sont répartis équitablement entre les mineurs et le portefeuille de gouvernance.

Afin de garantir que le protocole reçoive suffisamment de revenus grâce aux conversions, nous souhaitons apporter les modifications suivantes :

• xUSD < > xAssets Frais de conversion portés à 1,5%
• 1.2% serait envoyé au portefeuille de gouvernance
• 0,3% irait aux mineurs (au lieu de 0,05%)

Les tarifs seront révisés régulièrement.

VBS

La principale question est de savoir exactement quel montant de garantie devrait être requis pour effectuer une fonction d'étayage ? Il y a trois facteurs clés à considérer :

• Le montant qu'un utilisateur souhaite off/onshore
• La santé actuelle de l'écosystème XHV avant l'off/onshore
• L'inflation potentielle/la santé future de l'écosystème XHV après l'off/onshore

Grâce à l'analyse des données historiques et à la modélisation de scénarios futurs potentiels, nous avons rapidement réalisé que les ratios d'exigence de garantie dans la proposition initiale ne fourniraient pas une protection adéquate. L'objectif final est d'avoir un système facile à utiliser, nécessitant peu de garanties lorsque le système est sain mais protégeant contre une inflation sévère lorsque le protocole est en danger. 

Compte tenu de notre état malsain actuel, cela représente un défi et comme nous innovons, notre proposition actuelle est conservatrice pour protéger le protocole. Nous pourrons affiner les formules pour qu'elles soient plus conviviales à l'avenir une fois que nous aurons atteint une certaine stabilité. 

Trois composants clés sont utilisés dans nos calculs de garantie VBS :

• Ratio de capitalisation boursière - Le rapport entre la valeur de XHV et xAssets en circulation
• Spread Ratio - Une mesure de la "distance" entre la capitalisation boursière XHV et la capitalisation boursière xAssets
• Slippage - L'impact qu'une transaction aura sur l'état de l'écosystème

Les formules spécifiques sont en discussion au sein de la communauté et peuvent être trouvées dans le document de proposition. Ci-dessous, nous les résumerons de la manière la plus non technique possible et fournirons des exemples.

L'exigence totale de garantie VBS est :

Capitalisation boursière ou ratio de spread VBS + Slippage VBS

Le calcul de la première partie dépend dans un premier temps s'il s'agit d'un off/onshore :

• Offshores – Ratio capitalisation boursière 
• Onshores - Le plus élevé du ratio de capitalisation boursière et du ratio de propagation 

Le ratio de capitalisation boursière utilisera deux fonctions distinctes qui couvrent des plages distinctes du ratio de capitalisation boursière. Nous proposons qu'en dessous de 0,9 ratio mcap, une formule moins agressive soit utilisée pour permettre une utilisation plus facile du système et au-dessus de 0,9, nous utilisons une formule plus exponentielle qui fait augmenter fortement l'exigence de garantie. 

Le ratio de propagation est requis comme protection supplémentaire pour la délocalisation uniquement parce que, à mesure que les personnes sont à terre, l'offre de XHV augmente, ce qui diminue le ratio mcap, réduit l'exigence de garantie et crée une plus grande possibilité d'inflation.

Pour les marchés onshore, nous utilisons la pire des deux valeurs VBS entre mcap et ratio de spread, ce qui signifie que nous obtenons une protection sur toute la plage du ratio de capitalisation boursière.

Le tableau ci-dessous montre les valeurs VBS pour une gamme de ratios mcap et d'étalement, et leurs valeurs VBS calculées correspondantes. La dernière colonne indique la valeur VBS réelle utilisée pour Onshores, qui est la valeur VBS la plus élevée des deux, Mcap et Spread VBS.

Glissement

Afin d'éviter que le ratio de capitalisation boursière n'augmente trop rapidement (s'aggrave) par le biais de conversions uniques et importantes, nous devons ajouter un glissement sous la forme de VBS au VBS initial, qui est dérivé de l'état initial du protocole. Cela limitera les baleines convertissant de très grandes quantités avec une liquidité infinie.

Le glissement est calculé différemment pour l'offshore et l'onshore.

Pour Offshore, nous prenons le pourcentage d'augmentation de la Ratio de capitalisation boursière en fonction du montant converti.
Pour À terre, nous prenons le pourcentage d'augmentation de la Rapport de propagation.

Les formules spécifiques sont détaillées dans le document de proposition. En raison de l'onshore nécessitant déjà des exigences VBS supplémentaires par rapport à l'offshore, le glissement VBS offshore sera plus important. Pour montrer à quoi ces chiffres pourraient ressembler, nous avons inclus un tableau ci-dessous avec notre suggestion. Comme avec le ratio de capitalisation boursière, nous utilisons un multiplicateur différent lorsque le système est dans un état sain (3x lorsque le ratio mcap < 0,1) par rapport à un état malsain (10x lorsque le ratio mcap > 0,1). 

Bouchon d'étaiement de conversion par bloc

La protection fournie par les mesures VBS ci-dessus laisse un vecteur d'attaque où un utilisateur sophistiqué pourrait diviser une conversion importante en plusieurs conversions plus petites qui sont traitées dans le même bloc. Cela éviterait le glissement et toute modification de la capitalisation boursière ou des ratios d'écart et leur présenterait un VBS plus favorable que celui pour lequel le système est conçu. 

Notre solution proposée à cela est un plafond par bloc sur la quantité de XHV qui peut être délocalisée/onshore. Cette capitalisation sera dynamique et dépendra de la capitalisation boursière du XHV. La formule spécifique décrite dans le document de proposition a été choisie pour limiter l'impact sur les utilisateurs réguliers. Vous trouverez ci-dessous un tableau de ce que serait le plafond à diverses capitalisations boursières XHV.

Simulation

Pour aider à mettre cela en contexte, nous avons créé trois simulations dans le document de proposition. Nous en avons inclus un ci-dessous et accueillons les suggestions de scénarios que nous pouvons modéliser. Vous trouverez des détails sur la façon de proposer la simulation dans le document de proposition. 

Et si VBS était déjà en place lorsque XHV a atteint un creux de $0,42 en juin 2022, et que notre baleine xUSD a commencé à se délocaliser autant que le système le lui permettait ?

La plus grande hypothèse ici est une garantie de départ de 500k XHV.

Comme vous pouvez le voir, au cours des 126 derniers jours, la baleine n'a pu débarquer que 76k XHV, en raison du mauvais état dans lequel nous nous trouvons, et d'un VBS élevé correspondant.

Cela suppose que la baleine n'aurait pas acheté ou vendu de XHV pendant cette période, et que le prix est resté dans cette fourchette.

En résumé

Pour récapituler, nous proposons les mesures suivantes pour la tokenomics Haven 3.0 :

Mesures d'étaiement génériques

• 21 jours de temps de verrouillage pour toutes les conversions XHV < > xUSD
• VBS minimal = 1
• Pas de VBS maximum
• Capuchon d'étayage par bloc
• Frais de 1.5% pour toutes les conversions XHV < > xUSD
• Frais de 1,5% pour les conversions xUSD < > xAssets, avec 1,2% allant au portefeuille gouvernemental et 0,3% pour les mineurs
• Les délais de déverrouillage de la conversion xAssets doivent rester à 48 heures
• VBS applicable aux conversions XHV < > xUSD uniquement

Mesures spécifiques à l'offshore

• VBS variable basé sur le ratio de capitalisation boursière de XHV et xAssets
• Slippage variable VBS basé sur l'augmentation du ratio de capitalisation boursière
• Fonctionnalité Max Offshore

Mesures spécifiques à terre

• VBS variable basé sur le pire VBS (le plus élevé) entre le Market Cap Ratio VBS et le Spread Ratio VBS
• Slippage variable VBS basé sur l'augmentation du ratio de propagation
• Fonctionnalité Max Onshore

C'est de loin la proposition la plus complexe que nous ayons publiée à ce jour, et aussi la tokenomics la plus complexe que nous essayons de mettre en œuvre.

Les membres du groupe de travail sur l'économie seront disponibles pour répondre à toutes vos questions, mais veuillez prendre le temps de lire et de relire la proposition afin de bien comprendre. De nombreuses questions auront déjà trouvé une réponse dans cette proposition.

Merci à tous pour votre incroyable patience et votre soutien en ces temps difficiles.​