Proposition initiale pour le développement Haven 3.0

​

Il est important de noter que cette proposition est un projet de recommandation.
Aucune décision concernant nos tokenomics n'a encore été prise et rien n'est figé.

Tout ce qui est présenté dans ce document sont des idées à discuter ultérieurement avec la communauté, et une fois qu'un accord aura été trouvé, nous ferons une autre annonce.

Depuis que les conversions ont été en pause, les membres du groupe de travail sur l'économie (EWG) ont travaillé sur des solutions pour remettre le réseau Haven dans un état pleinement fonctionnel sans exposer la communauté Haven à un risque supplémentaire d'hyperinflation, comme cela s'est produit pour les détenteurs de l'écosystème Terra.

Ce travail aurait été plus difficile et aurait pris plus de temps sans l'apport de la communauté.
Les idées avancées par nombre de nos membres et rassemblées par xVolontairev dans ce document, ont donné à l'équipe EWG une base à partir de laquelle travailler, ce qui nous a finalement conduit à la proposition présentée ici.

Nous pensons avoir trouvé une solution viable et nous aimerions ouvrir des discussions dans notre #havenomics canal pour obtenir des commentaires de la communauté.
Ces discussions seront importantes pour affiner le modèle et éventuellement proposer une solution fonctionnelle.

Pour certains, les mesures proposées ici peuvent sembler dures et injustes, mais il faut se rappeler que le protocole est actuellement en mauvais état ; nous devons veiller à ce que cela ne s'aggrave pas et laisser au protocole le temps de se rétablir.

Il convient de rappeler à tous que le coffre-fort n'a jamais été destiné à être utilisé comme outil de trading ; nous encourageons tout le monde à échanger XHV et xUSD sur les bourses, ce qui stimulera l'adoption et augmentera la liquidité.

Le chemin de développement de Terra a donné un indice, en essayant d'utiliser des pools de Bitcoin pour un stablecoin algorithmique hybride avant qu'ils ne deviennent trop gros pour que leur mécanisme de stabilité puisse gérer des chocs exogènes extrêmes.

Mais Haven est différent ; l'aspect de la confidentialité empêche l'utilisation de chaînes de blocs publiques, de garanties et de pièces stables à des fins de sauvegarde.

Jusqu'à présent, le problème clé avec les modèles algorithmiques de pièces stables est que la conception de la tokenomics signifie que le prix des pièces stables est pris en charge au détriment du prix de l'actif natif.
Dans le cas de Haven, cela signifie acheter du xUSD bon marché pour le monnayer en XHV, puis vendre le XHV sur le marché. Cela crée une suppression constante du prix de l'actif natif et si le prix de l'actif natif diminue indéfiniment, cela peut entraîner une spirale de la mort et une perte totale de confiance dans le stablecoin.

De manière légèrement contre-intuitive, une conception de tokenomics qui ne donne pas la priorité au prix du stablecoin et protège à la place le prix de l'actif natif a une plus grande longévité en tant qu'écosystème et donc une plus grande confiance dans la valeur du stablecoin.

L'équipe EWG a donc proposé une nouvelle idée; Haven redouble d'efforts pour "être sa propre banque" et exigera une garantie sous forme de XHV pour utiliser la fonction de shoring.

La nouvelle idée peut se résumer en une phrase :

Pour Onshore/Offshore, vous devez avoir la valeur équivalente de XHV déverrouillé dans votre coffre-fort.

Nous appelons cette idée Vault Backed Shoring, ou VBS. Il vise à fournir des limites de liquidité pour l'utilisation de la fonction de shoring, déterminées par chaque utilisateur lui-même.

Avec cette nouvelle exigence de garantie, qui verrouillera à la fois la garantie et les pièces frappées pendant une période prolongée, les utilisateurs de shoring seront constamment exposés et liés à la volatilité de la garantie de base pendant qu'ils modifient activement les numéros d'approvisionnement du protocole.

Ils ne pourront pas utiliser la fonction de shoring s'ils vendent leur collatéral XHV et ne détiennent pas de XHV dans leurs coffres, ce qui les empêche de "se retirer" complètement du système volatil tandis que la communauté paie la position opposée avec une inflation accrue.

En bref, Vault Backed Shoring est destiné à fonctionner à la fois comme un frein de vitesse et comme une exigence de peau dans le jeu pour les utilisateurs de la fonction d'étayage.

REMARQUE: VBS ne sera requis que pour les participants qui utilisent les fonctions de shoring (XHV <-> xUSD), et non les transferts XHV ou xAsset standard.

Exemple de délocalisation :

Pour convertir 100 xUSD en XHV, vous devez avoir au moins $100 de XHV dans le coffre-fort, déverrouillé.
Cette valeur de $100 XHV (appelée garantie) sera verrouillée pendant la durée de la conversion avec les fonds convertis.

Si le prix actuel du XHV est de $0,50, cela signifie que vous devez avoir au moins 200 XHV (débloqués) dans votre coffre-fort pour pouvoir débarquer 100 xUSD.
Après une conversion réussie à l'aide de cet exemple, vous aurez 400 XHV verrouillés pendant un certain temps (voir les durées de verrouillage proposées ci-dessous).

Exemple de délocalisation :

Pour convertir 100 XHV en xUSD, vous devez avoir au moins la même quantité de XHV (100 dans ce cas) dans le coffre-fort, déverrouillé.
Cela signifie que vous ne pouvez jamais délocaliser qu'un maximum de 50% du XHV détenu dans le coffre-fort, à condition qu'aucun des XHV ne soit verrouillé.

Temps de verrouillage proposés pour VBS

Les fonds et l'exigence de garantie seront bloqués pour 21 jours.

Si l'utilisateur ne détient pas suffisamment de garanties pour être onshore en une seule conversion, VBS ralentit le processus d'onshore en exigeant qu'un onshore passe par plusieurs cycles d'onshore, et chaque onshore prend 21 jours.

Pour illustrer cela, voici quelques scénarios montrant combien de cycles et combien de temps il faudrait pour débarquer le montant total de xUSD détenu dans un coffre-fort.

Le premier exemple utilise un montant de départ de 10k XHV, et le deuxième exemple utilise un montant de départ de 100k XHV.
Les deux exemples utilisent une garantie 1: 1, ce qui signifie que le maximum que vous pouvez débarquer à tout moment est le montant maximum de XHV déverrouillé que vous avez dans le coffre-fort.
Dans la partie 2 de la proposition, nous verrons que la garantie changera en fonction de l'état du protocole.

Il est facile de voir que plus vous avez de garanties déverrouillées dans le coffre-fort, moins vous aurez besoin de cycles pour reconvertir entièrement tous vos xUSD en XHV.

Les deux scénarios suivants utilisent respectivement un prix XHV croissant et décroissant.

À partir de là, nous pouvons voir qu'avec un prix croissant en XHV, moins de cycles Onshore sont nécessaires, mais vous vous retrouvez avec moins de XHV global que vous n'en auriez si vous aviez pu débarquer tous les xUSD en une seule conversion.

Inversement, à mesure que le prix du XHV diminue, davantage de cycles Onshore sont nécessaires pour convertir tout le xUSD, mais vous vous retrouvez avec plus de XHV.
Bien que cela semble gonfler le protocole, ces scénarios ne tiennent pas compte de l'état du protocole, ce qui empêchera le type d'inflation vu ci-dessus.
Cela nous amène à la partie suivante de la proposition.

La première partie de la proposition décrivait l'idée novatrice autour de VBS et comment elle serait mise en œuvre.

A lui seul cependant, le VBS n'arrêtera pas forcément l'inflation, d'autant plus que le prix du XHV diminue avec le temps, il ne fera qu'allonger le temps nécessaire pour gonfler le protocole.

Par conséquent, d'autres mesures sont nécessaires pour contrer l'inflation incontrôlée et la manipulation des baleines.

Ratio de capitalisation boursière

Comme de nombreux membres de la communauté l'auront déjà noté lors de discussions sur notre canal havenomics, l'un des meilleurs moyens de mesurer la santé du protocole consiste à utiliser un ratio de la capitalisation boursière totale combinée des actifs offshore (TOAMcap) et de la capitalisation boursière XHV (XHVMcap ).

Cela se calcule simplement comme suit :

Plus le nombre est bas, plus le protocole est sain et vice versa.
Bien qu'il s'agisse d'un point de données subjectif, un très bon rapport est considéré comme étant lorsque XHVmcap est 10 fois supérieur à TOAMcap, c'est-à-dire 0.1 en utilisant la formule ci-dessus.

Au moment de la rédaction (23 juin 2022), l'offre en circulation de XHV est d'environ 28,3 millions avec une capitalisation boursière de $16 millions (en utilisant le prix KuCoin de $0,567).
La capitalisation boursière totale de l'actif s'élève à ~$16 millions.
Donc, le ratio mcap que nous avons actuellement est presque exactement 1, qui est considéré comme un mauvais ratio et donc un état malsain du protocole.

Combinaison du ratio mcap avec VBS

Un état malsain du protocole peut être atteint des manières suivantes :

• baisse continue du prix du XHV
• très grandes conversions uniques
• trop de délocalisation
• trop de relocalisation, ce qui peut entraîner une pression de vente sur le marché libre
• toute combinaison des points ci-dessus

Si nous combinons l'état du protocole (ratio mcap) avec notre modèle VBS, nous pouvons limiter davantage le mécanisme de shoring pour garantir que le système ne bascule pas trop vers un état malsain.

La façon dont nous proposons de le faire pour l'Onshore et l'Offshore est différente.

À TERRE

Pour les Onshores, nous augmenterons la garantie nécessaire à mesure que le ratio mcap augmente, ce qui signifie que vous devez avoir plus de XHV dans votre coffre-fort pour le même montant de xUSD lorsque le protocole tend vers un mauvais état.

Supposons que le ratio soit à 0,5, le protocole se dirige vers un état malsain. Cela signifie que vous ne pourrez plus utiliser une garantie 1:1 pour onshore votre xUSD.
Un calcul dynamique de ce ratio aurait pu arriver à une garantie de 1:3, ce qui signifie que vous auriez besoin d'avoir 3 fois plus de XHV dans votre coffre-fort que la quantité de XHV que vous essayez d'onshore.

Pour mieux visualiser cela, utilisons le même scénario que précédemment : un montant XHV de départ de 10 000 avec un prix constant, mais cette fois avec une garantie de 1:3.

Avec une garantie de 1: 1 de l'exemple précédent, nous aurions eu besoin de 7 onshores pour convertir entièrement tous les xUSD en XHV.
Avec une garantie de 1:3, comme ci-dessus, le nombre d'onshores est passé à 17, nécessitant une année entière pour convertir tous les xUSD en XHV.

Comparons également le même scénario, mais avec un montant XHV de départ de 100k.

Auparavant, avec une garantie de 1:1, il aurait fallu 4 onshores (84 jours) pour convertir la totalité du xUSD.
Avec une garantie de 1:3, il est passé à 9 onshores, soit 189 jours.

Bien sûr, ces scénarios sont assez irréalistes dans le monde réel ; il est impossible de prédire les fluctuations du marché et des prix, les fondamentaux, le sentiment, les tactiques de conversion, etc.

La conclusion que nous pouvons en tirer est qu'à mesure que l'état du protocole se détériore, le montant de la garantie nécessaire pour convertir xUSD en XHV augmente également, ce qui augmente à son tour le nombre de cycles et le temps nécessaire pour débarquer le montant total.

OFFSHORE

Pour les Offshores, le concept actuel est de maintenir la garantie à 1:1, mais nous augmenterons les frais à mesure que le ratio mcap augmentera. De plus, nous ajouterons également des frais de glissement pour les conversions plus importantes, ce qui ferait passer l'état du protocole de bon ou de mauvais à pire.

REMARQUE: La raison pour laquelle nous n'envisageons pas de frais pour les Onshores, autres que les frais de conversion standard, est que nous pensons que cela entraînerait une baisse de xUSD, ce qui pourrait créer une spirale descendante du prix sur le marché libre.

Offshore – Frais de conversion

Nous pensons qu'il est dans l'intérêt du protocole de brûler la majorité des frais afin de garder l'inflation sous contrôle, mais aussi de laisser suffisamment de frais pour le coût opérationnel du projet, plus les salaires.
Aux fins de cette proposition, nous supposons un minimum de 0,5% de frais pour le Trésor, tout excédent étant brûlé.
Les chiffres exacts seront convenus ultérieurement.

Pour calculer les frais de conversion, nous utiliserons une simple opération d'exponentiation entre le ratio mcap et un nombre qui est 2 ou très proche de celui-ci, +/- quelques décimales.
Si le nombre est trop élevé, le calcul deviendra trop rapidement exponentiel, ce qui le rendra inutilisable.

Pour illustrer cela, considérons l'exemple suivant, où nous simulons différents niveaux de ratios mcap avec 4 niveaux différents d'exposants : [1.6], [1.8], [2] et [2.2]
Nous fixons également un minimum (0,5%) et un maximum (80%) de frais, 0,5% allant au Trésor et le reste étant brûlé.

Au fur et à mesure que le ratio augmente et que l'état du protocole se détériore, les frais pour tout offshore seront augmentés en conséquence.
L'idée derrière les frais élevés n'est pas de punir les utilisateurs mais de les décourager de faire évoluer le protocole vers un mauvais état, et de se protéger contre une inflation incontrôlée en brûlant une grande partie des frais.
 

Offshore – Frais de glissement

Les frais de glissement sont une mesure supplémentaire pour attraper les conversions importantes qui aggraveraient l'état du protocole avec une seule conversion.

Nous ajouterions des frais de glissement aux frais de conversion standard tels que calculés ci-dessus. Fondamentalement, les frais de glissement sont les frais après une augmentation potentielle du ratio qui s'ajoutent aux frais de conversion standard.

Voici un exemple où le ratio est dans un bon état avant un offshore, mais après une seule conversion par une baleine, il le met dans un mauvais état.

autres considérations

Le ratio Market Cap est-il suffisant pour calculer l'état du protocole ?
La réponse est non.

Il y a autre chose à considérer que nous n'avons pas encore mentionné; la se propager rapport entre TOAMcap et XHVMcap.

L'état du protocole dans lequel nous nous trouvons actuellement, c'est-à-dire malsain, signifie que nous n'aurons pas beaucoup de conversions passant par le système car soit c'est trop cher, soit cela prendrait trop de garantie.
Cela pourrait cependant changer dès que le prix du XHV atteindra un niveau où le ratio de capitalisation boursière deviendra favorable aux onshores.

Au fur et à mesure que les gens commencent à débarquer et que le prix du XHV augmente, l'écart entre TOAMcap et XHVMcap s'élargit plus rapidement, ce qui incite davantage à débarquer, ce qui gonfle l'offre.
Cela pourrait continuer jusqu'à ce que tout le xUSD ait été converti en XHV et l'offre en circulation de XHV aurait été fortement gonflée.

Pour contrer cela, nous pourrions calculer le ratio d'écart entre les deux plafonds par rapport au prix XHV, et si l'écart devient trop important, nous pourrions appliquer des restrictions similaires aux conversions, même lorsque le ratio de capitalisation boursière est en bon état.

Le tableau de simulation ci-dessous montre comment cela pourrait être calculé.
Lorsque le ratio de capitalisation boursière est faible (état sain - ligne bleue), mais que le ratio de spread est élevé (ligne verte), nous pourrions augmenter le collatéral pour les Onshores et augmenter les frais pour les Offshores.

Pour rappel, nous proposons les mesures suivantes

DÉLOCALISATION

1. VBS avec garantie 1: 1, plus temps de verrouillage (21 jours proposés).
2. Ratio Mcap pour déterminer les frais en fonction de l'état du protocole.
3. Les frais de glissement dépendent de la taille de l'offshore et de l'état du protocole après un potentiel offshore.
4. Frais de ratio de propagation.
5. S'applique aux conversions XHV -> xUSD.

LOCATION

1. VBS avec temps de blocage (21 jours proposés).
2. Collatéral minimum de 1:1 et maximum 1:3 ou 1:4 (à discuter).
3. Garantie à déterminer selon l'état du protocole.
4. Garantie à déterminer par le ratio de répartition.
5. Frais de conversion de base.
6. S'applique aux conversions xUSD -> XHV.

La principale conclusion de cette proposition est que les discussions et les commentaires de la communauté doivent être centrés sur la nouvelle idée, VBS.
Nous aimerions vraiment savoir ce que vous pensez et si vous voyez des problèmes flagrants dans ce modèle.
 

Il y a un travail de développement important avec ce que nous proposons et pendant que l'équipe de développement étudie cela, nous voulons prendre le temps d'entendre les commentaires de la communauté sur cette proposition, en particulier la nouvelle approche de VBS.

Les membres peuvent en discuter le plus efficacement dans le #havenomics canaliser.​