Le plan d'action Ziggy UST

Cet article décrit le plan d'action proposé pour "Ziggy", une approche étape par étape pour réancrer TerraUSD, ou UST(C). Le plan est sujet à changement en fonction du marché ou d'autres conditions qui ne sont pas nécessairement sous notre contrôle.

Date d'édition : 7 février 2023.

Contexte : Proposition #11324
Ziggy : Discussion sur la proposition finale

Cette partie est réservée aux journaux des modifications de ce document.

#1 — Comprendre la situation

Le cœur de tout plan de ré-ancrage de l'UST est la question : "comment pouvons-nous injecter 8,5 milliards de dollars que nous n'avons pas ?"

À tout moment, nous pouvons obtenir la "valeur manquante" en soustrayant la capitalisation boursière de Terra (dans ce plan, USTC) de l'offre entièrement en circulation (nombre d'unités) de Terra :

9,800,000,000 units minus $300,000,000 mkt cap = $9,500,000,000 deficit

Nous soustrayons ensuite le montant de Luna (LUNC) dans la capitalisation boursière totale. Ce nombre peut théoriquement sauvegarder les pièces Terra à tout moment (en supposant des liquidations complètes et totales):

$9,500,000,000 minus $1,000,000,000 = $8,500,000,000 deficit

Dans le modèle précédent de Terra Classic, une nouvelle LUNA serait émise chaque fois que l'UST passerait en dessous de l'ancrage pour couvrir le déficit. D'un autre côté, LUNA serait brûlé chaque fois que l'UST dépasserait sa cheville.

Par exemple:

• 1,00 $ UST = 1,00 $ LUNA => aucun changement
• 0,98 $ UST = 1,02 $ LUNA => le déficit est imprimé
• 1,02 $ UST = 0,98 $ LUNA => l'excédent est brûlé

Malheureusement, alors que le programme fonctionnait «comme prévu», c'était un problème de conception - un environnement a été créé où LUNA pouvait être perpétuellement court-circuité, permettant aux acteurs du marché à fort levier de supprimer les prix et d'hyper-gonfler continuellement LUNA.

Considérez le tableau précédent. Chaque fois que le prix de Luna était supérieur au prix de Terra, une quantité suffisante de LUNA pouvait être brûlée pour répondre à sa demande. Remarquez comment la ligne bleue (supérieure) a toujours eu une tendance à la hausse ; il y avait suffisamment de garanties dans le système pour rétablir la parité. Cela ne tient pas compte de l'inflation, qui est comme une "brûlure légère" pour les personnes qui jalonnent et ne veulent pas vendre.

Dans ce graphique, nous indiquons plutôt le nombre de «réclamables» disponibles à un moment donné. Cela signifie simplement "combien de Terras (UST) puis-je obtenir pour mes Lunas (LUNA) ?"

La période est la même. Remarquez comment le montant total des réclamations connaît un pic entre les périodes #23 et #25. Le taux d'échange de LUNA <> UST était si élevé qu'il permettait de couvrir beaucoup de Terra (UST) sur un seul échange, mais le processus inverse signifiait que l'échange d'UST contre LUNA était une mauvaise affaire. (sauf si vous pariez gros et pariez long !)

Lorsque le prix de la Luna passe finalement en dessous de celui de Terra, "l'inflation algorithmique" commence, ou la frappe de nouvelles LUNA. Le système continuera à imprimer de l'argent jusqu'à ce que suffisamment d'offres soient satisfaites sur Luna. Cependant, les nouvelles offres (achats) ne peuvent presque certainement pas suivre le taux d'inflation programmé.

Ce phénomène était connu sous le nom de «spirale de la mort» lors du désancrage. Je recadrerais plutôt cela comme une « spirale de décomposition » et une « spirale de croissance » pour aller de l'avant. L'émission de la nouvelle Luna a permis une opportunité mondiale excentrique d'aider à récupérer une valeur immense et à la redéfinir de manière appropriée.

Vous pouvez en savoir plus sur la thèse de la dette du réseau ici : Bilan du réseau

#2 — Réactiver les swaps de marché contrôlés

Cette fonctionnalité de base est définie dans ce que l'on appelle le Market Module . Ce module, en plus des modules Oracle et Trésorerie, sont inexistants sur LUNA2.

Le module Market permet des échanges atomiques entre différentes dénominations de stablecoins Terra, et entre Terra et Luna. Ce module garantit un marché disponible et liquide, des prix stables et des taux de change équitables entre les actifs du protocole.

La stabilité des prix de TerraSDR est obtenue grâce à l'activité d'arbitrage Terra<>Luna contre le teneur de marché algorithmique du protocole, qui élargit et contracte l'offre de Terra pour maintenir son ancrage.

Source:https://classic-docs.terra.money/docs/develop/module-specifications/spec-market.html

Nous voulons réactiver cette fonction. Cependant, nous souhaitons opérer sous certaines conditions :

• Pas de nouvelle frappe de Luna (LUNC);
• Quantité fixe de frappe Terra (USTC et al)

Mais n'ont-ils pas déjà une option ? Et bien non. Considérons l'exemple suivant :

• Un utilisateur jalonnant 10 millions de LUNC peut payer 0,04 USTC par transaction en frais de transaction pour retirer les récompenses de délégation et les jalonner. Comme ils sont exonérés d'impôt, ils ne paient que 0,08 USTC.
• Un utilisateur échangeant USTC contre LUNC paiera 0,04 USTC par transaction en frais de transaction, un minimum de 0,30 % en écart et 0,2 % supplémentaire en taxes. Si l'USTC est de 0,03 $, alors une conversion en 10 millions en LUNC, ou 300 000 USTC, signifie qu'ils paieront 900 USTC en spread (0,30 % minimum) versés aux fournisseurs de liquidités, et 600 USTC en taxes, pour un total de 1 500,04 USTC.

Un acteur du marché rationnel voit qu'il n'y a « pas de choix » lorsqu'il pense en termes de rentabilité pure, car il est tout simplement plus rentable de négocier sur Binance. Les CEX permettent également ce qu'on appelle le trading perpétuel à effet de levier sur les positions longues et courtes, ce qui signifie que les traders peuvent emprunter de l'argent pour acheter des ventes longues ou courtes. En combinaison avec des récompenses de mise, nous permettons activement de parier contre notre réseau !

C'est la différence entre vous demander :

• Voulez-vous payer 1,00 $ à la caisse pour un bar Snickers ?
• Voulez-vous payer 5,00 $ à la caisse pour un bar Snickers ?

Bien sûr, Binance fait de grosses brûlures, mais rappelez-vous qu'ils le font avec des frais de 0,1 % - nous facturons 0,30 % + 0,20 % + frais de transaction. Pourquoi ne pas donner à ces commerçants une raison d'utiliser notre chaîne ?

Parlons également des brûlures manuelles. À 6 billions de LUNC comme approvisionnement total, une combustion manuelle de 2 m LUNC supprime 3,333 × 10 ^ -5% de l'approvisionnement. Cela prendra des millénaires à accomplir, si l'intérêt pour LUNC existe toujours d'ici là !

La question que la communauté LUNC doit poser est : "qu'est-ce qui ramènerait LUNC et USTC des CEX comme Binance sur la chaîne ?"

Pour cela, nous avons besoin de cas d'utilisation. À l'heure actuelle, il nous reste très, très peu de dApps, qui ont toutes perdu de l'argent en mai 22 et continuent de payer pour le soutenir, même s'ils ne sont pas du tout rentables.

Nous pouvons faire appel aux détenteurs de NFT, mais sans modèles commerciaux, ils sont subjectivement valorisés et/ou motivés par la spéculation. Nous avons également des DEX où les utilisateurs peuvent fournir des liquidités, mais ceux-ci sont incroyablement «minces» pour terminer les commandes. Un peu contraignant, n'est-ce pas ?

À ~ 0,03 $ USTC et ~ 0,000185 $ LUNC, 12,84 millions USTC ne représentent que 385 200 $ de liquidités disponibles pour le commerce. Cela semble beaucoup, mais quand vous pensez que Binance fait des milliards de volumes de trading par jour, l'écart est tout simplement trop important pour que les traders puissent payer ; ils resteront sur Binance même si le taux d'imposition est proche de zéro.

Bien sûr, nous pouvons ajouter de l'argent à ceux-ci, mais il n'y a pas de forme stable de trading sur le réseau. Cela signifie que nous pourrions ajouter de l'argent et, en raison du fonctionnement des AMM, subir une forte perte ! (Vous pouvez en savoir plus sur la perte impermanente ici !)

Alors, quelle est la solution ? Pourquoi ne pas autoriser les utilisateurs à échanger des devises sur leur portefeuille ?

C'est ce que fait le module de marché. Si vous voyagez en Europe et vivez aux États-Unis, vous devez échanger dans la devise locale. Cependant, vous ne voulez pas renoncer à votre LUNC. Au lieu de cela, vous échangez des USD (USTC) contre des EUR (EUTC) et les utilisez comme mode de paiement. Les frais facturés sur le trading ( spread ) vont aux jalonneurs LUNC.

Nous voulons une activité commerciale entre ces devises. Nous le ferons d'abord sur un testnet afin que tout le monde puisse participer .

#3 — Concevoir et tester des contrôles pour l'algorithme.

Une partie de la proposition de Ziggy adopte une approche étape par étape. Ceci s'applique aux actions génériques (comprendre, réactiver, tester) et s'applique également aux valeurs numériques (0.01, 0.02, 0.03).

Si nous voulons être encore plus approfondis, nous comptabilisons également chaque micro-unité (0,000001 dans Terra Classic), et nous comptons également chaque tranche qui existe dans cet ensemble discret, tout en tenant compte des chaînes compatibles EVM. Cela signifie que chaque groupe de nombres entre 1x10^–18 et 1,00, extrapolant ensuite cette information au-delà de 1,00.

C'est-à-dire, quel est le plan lorsque le prix est, disons, 0,000005 et 0,50 ? C'est beaucoup de nombres et de groupes, même s'il s'agit d'un ensemble discret (fini) de nombres.

Or, ce type d'approche approfondie nécessite l'assistance de spécialistes de la finance quantitative. Les gens traiteront les actifs Luna et Terra différemment à différents niveaux de prix. Ils peuvent acheter USTC/LUNC lorsqu'ils sont respectivement à 0,005 $/0,00005 $ en quantités énormes, mais lorsqu'ils sont à 0,04 $/0,0004 $, ils peuvent être plus réservés ou prendre des bénéfices sur une certaine période.

La proposition de code ERM de Ziggy décrit une manière de traiter TerraSDR (SDT) comme une option, ou une paire de devises donnée (par exemple, USD/JPY) comme une option. En termes d'apport d'utilitaires en chaîne, il s'agit facilement de l'un des types de dApps les plus précieux que nous puissions intégrer. (En savoir plus sur le trading d'options Forex .)

Cela peut avoir un sens en tant que Layer-2, ou cela peut avoir un sens en tant que Layer-1. Du point de vue de l'itération, il est plus logique de tester de nouvelles fonctionnalités d'algorithme sur une chaîne latérale de couche 2, puis de les intégrer à la couche de base si cela s'avère inestimable. Un exemple de cela sur Ethereum serait de tester sur Arbitrum, Optimism ou Polygon avant de déplacer ses fonctionnalités vers Mainnet.

Les options sont un sujet financier plus complexe qui s'est généralisé ces dernières années en raison de l'émergence d'applications comme Robinhood. En général, on peut penser à deux types principaux :

• appel
• mettre

L'ERM est une directive de code généralisée qui permettrait l'achat et la vente d'USTC, de LUNC et d'autres paires. S'il y a 253 combinaisons uniques, nous les comptabilisons toutes, puis ajoutons 3 combinaisons non corrélées comme moyen de sauvegarder LUNC lui-même. Du point de vue des données, l'utilisation des 256 créneaux serait préférable, et de nouveaux pays membres peuvent toujours être intégrés. Les recommandations générales pour cela sont BTC, ETH et un stablecoin.*

*Remarque : bien que le BUSD ait été le choix de la foule, je travaille sur un livre blanc qui expliquera comment nous pouvons à la place créer un pool de pièces stables en xUSD, USDx et diverses devises d'autres pays qui ne préfèrent pas une institution ou un protocole de soutien. sur un autre. Vous pouvez voir quelques discussions sur mon Twitter sous #Moonflower .

L'utilisation d'un maintien de prix algorithmique de style options signifie que nous pouvons créer un système qui tient compte d'une action de prix extrêmement détaillée, allant des changements de base des prix au comptant aux dérivés associés à la volatilité implicite.

Le réseau lui-même agit comme contrepartie dans cette écriture algorithmique d'options. À tout moment, le réseau tente d'assurer l'approvisionnement disponible en Terra ou Luna par le biais d'un système d'appel de base. Cela signifie que, si l'ERM est mis en œuvre (même si le nom est changé), le risque total est assumé - nous pouvons atteindre 1,00 $ sur l'USTC et le voir baisser ou augmenter immédiatement .

Nous recueillons en outre des données autour de ces SoftPegplages. Si nous pensons plutôt au SoftPeg(high, low)comme SoftPeg(put, call), nous pouvons définir plus précisément sa fonctionnalité.

#4 — Développer des solutions parallèles pour se protéger contre les « événements de désancrage » — puis simuler un désancrage.

L'ERM tel quel présente de graves défauts du point de vue des risques, notamment dans son séquencement de mise en œuvre. Si nous rassemblons un consensus sur l'oracle des prix, puis changeons immédiatement d'algorithme sans le communiquer par le biais de la gouvernance, nous introduisons un certain degré de faute byzantine :

Dans une panne byzantine, un composant tel qu'un serveur peut apparaître de manière incohérente à la fois défaillant et fonctionnel pour les systèmes de détection de panne, présentant différents symptômes à différents observateurs. Il est difficile pour les autres composants de déclarer qu'il a échoué et de l'exclure du réseau, car ils doivent d'abord parvenir à un consensus sur le composant qui a échoué en premier lieu. La tolérance aux pannes byzantines ( BFT ) est la résilience d'un système informatique tolérant aux pannes à de telles conditions

Source:https://en.wikipedia.org/wiki/Byzantine_fault

Tendermint utilise une tolérance aux pannes byzantine pratique en utilisant une preuve de participation déléguée (autorité) ou pBFT-dPoS (A). Vous pouvez en savoir plus ici .

Maintenant, la proposition de Ziggy tient compte de la montée de "l'escalier" de la tarification, mais elle ne tient pas compte de la chute de l'escalier. Pour tester l'escalier à la recherche de fissures, nous allons monter les escaliers, puis redescendre. De cette façon, nous simulons un événement de désancrage en appliquant une immense pression de vente.

Nous tenons à préciser que ces événements peuvent être signalés dans le Ziggy ERM en définissant SoftPeg(put, call)ou SoftPeg(high, low)en rangeant. En effet, nous signalons à l'ensemble du marché que nous allons vendre un putUSTC (par exemple) à un highprix donné, et exercer un callUSTC à un lowprix donné.

Par exemple, nous définissons SoftPeg(0.04, 0.02) = 0.03avec un délai d'expiration de ModifierBlockDuration = 1000 blocks- en ce sens, nous permettons désormais aux traders financiers quantitatifs qualifiés de travailler sur un système ouvert en concevant leurs propres stratégies d'options.

Le Ziggy ERM définit une fourchette d' 0.02USTC de "tolérance à la volatilité". Nous pourrions être considérés comme une tranche ou une « portion d'argent ».

Alex Forshaw a proposé un plan de tranche-réserve (ci-dessus) fin 2022 qui peut être réexploré. Alors que le plan initial proposé par Forshaw, en plus de Maximilian Bryan et Edward Kim , suggérait 10 tranches utilisant une réserve de Bitcoin enveloppée de Terra twBTCpour les soutenir par des rachats algorithmiques, la principale préoccupation était, eh bien, de s'assurer que la réserve ne serait pas détruite. une attaque de marché soigneusement orchestrée.

Avec la grâce de ces proposants, nous voudrions leur demander de continuer à explorer ce plan comme un moyen de renforcer le rattachement à une tranche donnée en conjonction avec le Ziggy ERM en utilisant les réserves suggérées : , , ou des garanties « sécurisées twBTC» twETHsimilaires twUSDx.

C'est-à-dire qu'au lieu de délimiter 10 tranches, nous délimitons un ensemble discret de tranches entre 1x10^-18 et 1,00. (Encore une fois, ce nombre est beaucoup.)

Lorsque le Ziggy ERM exécute sa stratégie d'options hybrides (dans ce cas, un Strangle ), le système de tranches proposé par Forshaw et al peut être testé à plus petite échelle en s'engageant automatiquement avec des achats de réserve à la call// lowfin du SoftPeg- bien que ce soit important pour décider comment aborder la put// highfin ici, car ce n'est pas à cela que sert la réserve.

# 5 - Source de financement pour les tests et l'itération des plans liés à Ziggy.

La source la plus directe du réseau pour financer ces efforts est le pool communautaire. Cependant, lorsque nous considérons la longévité du réseau d'un point de vue fiscal, nous aimerions constituer une réserve dans le pool communautaire tout en soutenant le moins possible le financement de capital-risque imposé par le réseau du pool Oracle.

Un autre problème central abordé dans la proposition de Ziggy est "d'où vient l'incitation (l'argent) ?" La proposition implique qu'il peut provenir de l'arbitrage, mais l'arbitrage provient d'inefficiences du marché - nous ne pouvons pas le créer de force à des fins lucratives.

Au lieu de cela, nous proposons actuellement de permettre aux validateurs d'opter pour une fonction de retenue. La mise en œuvre d'une telle fonction a été discutée avec l'un des développeurs de Layer-1 au moment de la rédaction . Cette fonctionnalité se lit un peu comme :

• Fixez un pourcentage de commission
• Une partie de la commission est retenue (volontairement) dans un pool séparé pour financer la fonctionnalité Ziggy ERM

• Notre SoftPeg(pour des raisons de données) est de 0,03 $.
• Le réseau conservera le droit d'exercer son putprix $0.04au moyen d'un paramètre distinct.
• Le réseau conservera le droit d'exercer son callprix $0.02au moyen d'un paramètre distinct.

• Le putprix peut être exercé par les retenues des validateurs par le biais de leur propre commission. Ce faisant, un profit direct est réalisé. Cependant, comme cela est préférable à ceux qui exécutent des nœuds de validation plutôt que des délégués, nous renvoyons cet argent au pool Oracle et au pool communautaire en fonction d'un gestionnaire de gouvernance.
• Le callprix peut être exercé via le système de la tranche de réserve qui a alloué le capital à la tranche de tranche spécifique 0.02 — 0.04.

• La proposition de fractionnement fiscal AnteHandler de LuncBurnArmy
• Proposition communautaire DEX de faffyswap
• Proposition de système multi-pool de drlocum

#6 — Résumé et notes

Le résumé est le suivant :

1. Comprenez la situation et pourquoi c'est arrivé avant.
2. Réactivez les échanges de marché et effectuez des tests sur les réseaux de test avant le réseau principal. (sans nouvelle frappe de Luna, émission fixe de Terra)
3. Concevoir et tester des contrôles autour des swaps de marché. (Ziggy ERM)
4. Développez des solutions de protection parallèles pour vous préparer aux événements de désancrage, puis simulez ces désancrages pour tester leur robustesse. (mécanisme de tranche de réserve USTN dans le cadre du Ziggy ERM)
5. Source de financement à l'aide des retenues volontaires de la commission du validateur. Au lieu de rapporter à la maison 100 % de la commission de 5 %, utilisez-en la moitié pour financer la réintégration de l'algorithme sous Ziggy ERM. Ensuite, envoyez les bénéfices au pool Oracle et au pool communautaire. (inspiré de plusieurs propositions)

Cette idée est ouverte à l'itération. Un journal des modifications sera fourni en haut de cet article au cas où il devrait être réédité.

Commencez le remue-méninges, et faisons-le !