12188 | Terra Classic Market Module 2.0 (version non monnayée)
Source de :
- https://validator.info/terra-classic/governance/12188
- https://github.com/Market-Module-2-0/proposal/blob/main/proposal-nomint.md
Module Terra Classic Market 2.0
Version sans menthe
Un moteur de déflation nette qui peut s’ouvrir sans hyperminage, qui s’étrangle lui-même lorsque l’offre se réduit et qui ne peut pas être piégé par des prix périmés.
Il est basé sur le projet original “Terra Classic Market-Module 2.0“, mais incorpore des mécanismes pour éviter la menthe/brûlure, qui a suscité des inquiétudes parmi plusieurs membres de la communauté.
Si vous souhaitez un résumé non technique, veuillez consulter l’annexe 1 (résumé) et l’annexe 2 (questions/réponses).
1. Contexte et objectifs
2022 a permis de tirer deux leçons difficiles :
- La capacité illimitée tue – l’augmentation du pool de base et le raccourcissement de la période de récupération du pool (PRP) permettent aux traders de monnayer plus vite que le marché ne l’absorbe, ce qui détruit le LUNC.
- Une parité fixe de 1 $ est mortelle – évaluer l’UST à 1 $ alors qu’il se négociait à quelques centimes a provoqué une hyperinflation.
Aujourd’hui (25 juin 2025), nous sommes assis sur environ 6,50 T LUNC et 6 B USTC; les brûlures ne représentent que ≈ 1,3 B LUNC / mois (0,02 %). La communauté souhaite que le module de marché (MM) soit rétabli dès que possible afin de restaurer les flux de services et de redevances – mais elle n’acceptera qu’une baisse continue de l’offre nette.
2. Comment le module de marché a été historiquement frappé
2.1 base_pool – la “réserve virtuelle de DTS”.
Lorsque vous échangez USTC → LUNC (ou vice versa), le module prétend que vous interagissez avec un pool virtuel de SDR. Le calcul proprement dit est le suivant :
- Conversion du montant de l’USTC en sa valeur en DTS en utilisant les prix courants de l’oracle
- Déterminer la quantité de LUNC à battre pour que la courbe du produit virtuel constant reste équilibrée.
- Mise à jour de la “dette” DTS créée par le swap
Pour simplifier, lorsque vous échangez USTC → LUNC, le module se présente comme un AMM SDR/LUNC dont l’une des faces est un pool virtuel de taille base_pool :
ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before
Un pool de base plus important permet à un seul échange de donner plus de LUNC avant que le prix ne bouge.
2.2 PRP – la minuterie de recharge
Après un échange, le module se souvient d’un déficit de DTS d (à quel point le pool virtuel de DTS a été vidé). À chaque bloc, il “recharge” une fraction fixe :
d_next = d_current × ( 1 – 1 / PRP )
Chaque bloc rétablit 1/PRP du déficit. Donc :
- PRP court → recharge rapide → possibilité de réimprimer quelques minutes plus tard
- PRP long → recharge lente → doit attendre des heures ou des jours
La capacité totale d’échange par jour (si les commerçants la vident complètement à chaque fois) est d’environ :
swap_cap_day ≈ 2 × base_pool / ( PRP / 14 400 )
(14 400 ≈ blocs par jour sur Terra Classic).
Cette formule est dérivée de la quantité de DTS qui peut être épuisée et réapprovisionnée par jour tout en maintenant la faisabilité des swaps.
3. Approche sans dépouillement (basée sur l’épochage)
Actuellement, la taxe de combustion sur la chaîne est répartie à raison de 10 % pour le Community Pool, 10 % pour l’Oracle Pool et 80 % pour la combustion.
Pour éviter toute frappe de jetons, il est proposé de rediriger 60 % vers un pool temporaire de “liquidité de module de marché”. Bien que cela réduise la combustion immédiate de la taxe à 20 %, des brûlures supplémentaires se produiront toujours à chaque période de 30 jours (voir ci-dessous).
Au premier bloc H₀ de chaque période de 30 jours, pour chaque jeton séparément (USTC et LUNC) :
- Chaque jeton (USTC et LUNC) qui a atteint le pool de liquidité du module de marché est déplacé vers un pool d’échange distinct pour le module de marché. Il s’agit de la quantité de ce jeton disponible pour les utilisateurs à des fins d’échange.
- Cela équivaut à 75 % des brûlures fiscales du mois dernier pour chaque jeton.
- Au lieu d’utiliser la frappe et la combustion lors des échanges via le module de marché, les jetons sont simplement prélevés et ajoutés à cette réserve.
- Au début de la période de 30 jours suivante, tous les restes des piscines sont brûlés.
4. Base_pool et PRP adaptatifs pour l’époque
Nous voulons des coups d’éclat lorsque la volatilité augmente, mais nous devons rester dans les limites de l’allocation mensuelle.
4.1 Choisir un facteur d’éclatement
Défaut F = 0,07 → au maximum 10 % du solde actuel du pool de liquidités peut être utilisé en une seule journée.
cap_journalier_désiré = solde_pool × F
4.2 Solve for base_pool
Réarrangement de la formule du plafond journalier :
base_pool_raw = capacité journalière souhaitée × PRP / ( 2 × 14 400 )
4.3 PRP à l’échelle de l’offre
PRP = max( 14 400 , 14 400 × ( S / 1 T ) )
6,5 T d’approvisionnement → PRP ≈ 93 600 blocs (6,5 jours).
Lorsque l’offre diminue, la recharge est plus rapide – le robinet se rétrécit au fur et à mesure que le réservoir se vide.
4.4 Pinces finales
base_pool = min( base_pool_raw, 0.00010 × supply_value_in_SDR, 5 000 000 SDR ) // toit absolu
Exemple pour la première époque (aujourd’hui)
| Objet | Valeur |
|---|---|
| tax_30d (B₀) | 1,0 B LUNC |
| redirigé vers le bassin = 0,6 × B₀ | 600M LUNC ≈ 24 400 SDR |
| PRP (approvisionnement de 6,5 tonnes) | 93 600 blocs |
| cap_quotidien_désiré (par exemple F = 0,1) | 60M LUNC (en fonction du solde actuel) |
| base_pool_raw | ≈ 7,9 k SDR |
| base_pool après les pinces | 7,9 k SDR |
| Utilisation de la piscine par jour (max) | 2 × 7,9 k / 6,5 ≈ 2,45 k SDR ≈ 60,4 M LUNC |
60,4 M > 60 M, donc F, et non la pince PRP, est le frein actif.
5. Entrée des prix en direct et gardes anti-manipulation
| Composant | Règle |
|---|---|
| Prix Période de vote | 5 blocs ≈ 30 s |
| Prix USTC | price_uusd(USTC) = médiane pondérée par les droits de vote pour cette période |
| Quorum auto-kill | Si l’un des actifs a des votes de prix de < 50 % VP pendant 25 blocs → MM.enabled=false jusqu’à ce que le quorum soit rétabli |
| Pince de sécurité TWAP | Chaque échange échoue si le prix du peg diffère de plus de 10 % d’un Oracle-TWAP de 45 blocs (alimenté par les mêmes oracles). |
| Stable→stable route | Désactivé dans le code (ErrStableSwapDisabled) |
6. Freins absolus et gouvernance
- ⅔ La super-majorité peut fermer le MM à tout moment
7. Brûlures
À la fin de la période de 30 jours, tous les restes du pool sont brûlés. En fonction du comportement d’échange des utilisateurs, cette opération peut être similaire aux brûlages qui auraient eu lieu sans cette approche, ou plus proche de l’un des deux jetons (voir le résumé à l’annexe 1).
8. Scénarios
8.1 Le taureau mais l’ennui (retours d’utilité)
Exemple montrant des calculs séparés pour les deux jetons :
LUNC dans un scénario de croissance normale
- Le produit de la taxe LUNC atteint 2 milliards d’euros par mois à l’époque 3, tandis que le produit de la taxe USTC s’élève à 560 000 euros par mois.
- PRP toujours > 3 jours, base_pool limité par l’allocation.
Scénario a.) Les utilisateurs échangent également entre LUNC et USTC.
| Époque | Taxe LUNC | Taxe de l’USTC | Piscine LUNC avant | Pool USTC avant | Piscine LUNC après | Pool USTC après |
|---|---|---|---|---|---|---|
| 1 | 1.3 B | 360 K | 720 M | 216 K | 720 M | 216 K |
| 2 | 1.6 B | 450 K | 840 M | 270 K | 840 M | 270 K |
| 3 | 2.0 B | 560 K | 1.20 B | 336 K | 1.20 B | 336 K |
| Brûlé | 2.76B | 822 K |
Dans ce scénario, les mêmes quantités de LUNC et d’USTC sont brûlées que lorsque le MM est ouvert.
Scénario b.) Les utilisateurs échangent principalement (80 %) des USTC contre des LUNC, prix supposé pour simplifier : 200 LUNC/USTC (en réalité, ce prix fluctuerait).
| Époque | Taxe LUNC | Taxe de l’USTC | Piscine LUNC avant | Pool USTC avant | Piscine LUNC après | Pool USTC après |
|---|---|---|---|---|---|---|
| 1 | 1.3 B | 360 K | 720 M | 216 K | 144 M | 3.1 M |
| 2 | 1.6 B | 450 K | 840 M | 270 K | 168 M | 3.63 M |
| 3 | 2.0 B | 560 K | 1.20 B | 336 K | 240 M | 5.14 M |
| Brûlé | 552 M | 11.87 M |
Dans ce scénario, 2,2 B LUNC de moins seraient brûlés que si le MM était ouvert. En contrepartie, 11 M USTC de plus seraient brûlés.
Scénario c.) Les utilisateurs échangent principalement (80 %) des LUNC contre des USTC, prix supposé pour simplifier : 200 LUNC/USTC (en réalité, ce prix fluctuerait).
| Époque | Taxe LUNC | Taxe de l’USTC | Piscine LUNC avant | Pool USTC avant | Piscine LUNC après | Pool USTC après |
|---|---|---|---|---|---|---|
| 1 | 1.3 B | 360 K | 720 M | 216 K | 754.5 M | 43.2 K |
| 2 | 1.6 B | 450 K | 840 M | 270 K | 882 M | 54 K |
| 3 | 2.0 B | 560 K | 1.20 B | 336 K | 1.254 B | 67.2 K |
| Brûlé | 2.89 B | 164.4 K |
Dans ce scénario, 130 M LUNC de plus seraient brûlés que si le MM était ouvert. En contrepartie, 660 K USTC seraient brûlés en moins.
8.2 Flash-crash et panne d’oracle
- USTC tombe à 0,004 $ (80 LUNC/USTC) ; deux des principaux validateurs sont hors ligne.
- Après 30 s, le quorum est < 50 % → MM se ferme.
- Les recettes fiscales s’effondrent pour les deux jetons à l’époque suivante.
LUNC en situation de crise
- Le produit de la taxe LUNC s’effondre à 0,2 milliard d’euros par mois.
- Les recettes fiscales de l’USTC s’effondrent à 56 K/mois
Scénario a.) Les utilisateurs échangent également entre LUNC et USTC.
| Époque | Taxe LUNC | Taxe de l’USTC | Piscine LUNC avant | Pool USTC avant | Piscine LUNC après | Pool USTC après |
|---|---|---|---|---|---|---|
| 1 | 0.2 B | 56 K | 120 M | 33.6 K | 120 M | 33.6 K |
| 2 | 0.2 B* | 56 K | 120 M | 33.6 K | 120 M | 33.6 K |
| 3 | 0.2 B | 56 K | 120 M | 33.6 K | 120 M | 33.6 K |
| Brûlé | 360 M | 100.8 K |
Dans ce scénario, les mêmes quantités de LUNC et d’USTC sont brûlées que lorsque le MM est ouvert.
(*) Le MM est interrompu au milieu de cette époque en raison d’une panne de l’oracle et n’est pas repris. Aucun autre échange n’a lieu à partir de ce moment
Scénario b.) Les utilisateurs échangent principalement (80 %) des USTC contre des LUNC, prix supposé pour plus de simplicité : 80 LUNC/USTC (tel que défini dans le scénario d’accident).
| Époque | Taxe LUNC | Taxe de l’USTC | Piscine LUNC avant | Pool USTC avant | Piscine LUNC après | Pool USTC après |
|---|---|---|---|---|---|---|
| 1 | 0.2 B | 56 K | 120 M | 33.6 K | 24 M | 1.2 M |
| 2 | 0.2 B* | 56 K | 120 M | 33.6 K | 48 M | 900 M |
| 3 | 0.2 B | 56 K | 120 M | 33.6 K | 120 M | 33.6 K |
| Brûlé | 192 M | 2.13 M |
Dans ce scénario, 150 M LUNC de moins seraient brûlés que si le MM était ouvert. En contrepartie, 2 M USTC de plus seraient brûlés.
(*) MM est interrompu au milieu de cette époque en raison d’une panne de l’oracle et ne reprend pas. Aucun autre échange n’a lieu à partir de ce moment.
Scénario c.) Les utilisateurs échangent principalement (80 %) des USTC contre des LUNC, prix supposé pour plus de simplicité : 80 LUNC/USTC (tel que défini dans le scénario d’accident).
Nous ne tenons pas compte de ce scénario, car il est peu probable que les gens passent de LUNC à USTC dans l’hypothèse d’un effondrement des prix de USTC.
Même en cas de catastrophe, le flottant continue de diminuer pour les deux jetons indépendamment.
9. Politique en matière de spreads et de commissions pour les swaps MM
| Condition | Frais appliqués | Notes |
|---|---|---|
| MM désactivé (pas d’échange) | — | Pas de frais, pas de brûlure ; l’itinéraire est inerte. |
| MM activé & allocation > 0 | 0,35 % du notionnel | Collecté dans l’actif de sortie (LUNC sur USTC→LUNC swaps, USTC sur LUNC→USTC). |
| Allocation épuisée (atteinte du plafond d’époque) | — | L’échange est refusé ; pas de frais, pas de brûlure. |
Raison d’être
- Niveau réalisable – 0,35 % est suffisamment bas pour que l’arbitrage reste rentable par rapport aux écarts typiques de la Bourse (≈ 0,10 – 0,25 %), tout en récupérant les coûts de l’oracle et de la gardienne.
- Pas de double imposition – La “burn tax” de 0,50 % applicable à l’ensemble de la chaîne ne s’applique pas à ces échanges dans les modules ; elle est remplacée par la commission d’écart de taux.
- Comptabilité – Les frais sont acheminés à 50 % vers le brûlage et à 50 % vers le pool Oracle.
- Trajectoire stable à stable – Entièrement désactivée (§ 4.4), de sorte que la redevance ne s’applique jamais qu’aux transactions LUNC ↔ USTC.
10. Compatibilité des modules Oracle
La réactivation du MM avec une tarification dynamique nécessite des mises à jour de l’infrastructure actuelle de l’oracle :
- Alimentation en prix de l’USTC – L’USTC doit être ajoutée à l’ensemble des votes de l’oracle. Le MM suppose actuellement un prix fixe de 1 $ ; cette logique doit être supprimée et remplacée par des prix en temps réel fournis par les validateurs.
- Expansion des fournisseurs de données – Le système de collecte existant prend en charge un nombre limité de sources. Pour garantir une tarification précise et à l’abri des manipulations, il faut intégrer des fournisseurs de données supplémentaires (par exemple, des CEX multiples, des agrégateurs).
- Intégration des validateurs – Tous les validateurs doivent être guidés dans la mise à jour de leurs binaires d’alimentation oracle et de leurs configurations pour prendre en charge USTC. La documentation et la coordination du déploiement seront nécessaires pour éviter les chutes de quorum.
- (Facultatif) Révision du chargeur – Une réécriture complète du binaire du chargeur n’est pas strictement nécessaire, mais fortement recommandée. Le chargeur actuel est obsolète et ne prend pas en charge les API modernes, la logique de repli et la gestion correcte des erreurs.
Ces changements doivent être mis en œuvre avant la réouverture du MM. Sans elles, les prix saisis ne seront pas valables ou seront absents, ce qui déclenchera les mécanismes d’arrêt automatique.
11. Feuille de route
- Fusion de code pour testnet & révision – ≈ 500-1000 lignes de code (logique de piscine, boutons adaptatifs, kill-switch).
- Réseau de test public – injectez des pics de prix, des chutes de quorum, des brûlures de 10×.
- Mise à niveau du réseau principal (en deux étapes)
- Module de déploiement inactif
- Activation à la limite de l’époque suivante après que la réserve a été remplie pendant l’époque.
- 90 jours post-mortem – changement 60 % redirection ou F uniquement par hard fork (mise à niveau de la chaîne).
12. Ce que nous gagnons
- Réouverture immédiate – les opérateurs peuvent arbitrer dès le premier jour.
- Déflation garantie – l’offre doit toujours diminuer tous les 30 jours.
- L’étranglement élastique – lorsque l’offre se contracte, le remplissage ralentit et la réserve se réduit.
- Oracle-safe – 30 s de décalage ne peuvent pas gonfler ; 75 s de décalage tuent le module.
- Recharge de la réserve d’oracle – les frais de diffusion du module de marché sont redirigés vers la réserve d’oracle pour les récompenses futures (50 %).
- Brûlures – 50 % de la taxe d’écartement sont brûlés
13. Brûlures volontaires
À l’heure actuelle, une grande partie de l’offre brûlée provient de brûlages volontaires (pièces envoyées au module de brûlage de la chaîne – terra1…anxu).
Ces fonds devraient être exclus du calcul des brûlures de l’époque de 30 jours pour éviter de perdre le soutien des entités comme Binance et des membres de la communauté. Cela réduira le nombre de jetons disponibles. Il faudrait envisager d’étendre les pools si nécessaire, mais cela devrait être discuté avec les entités concernées une fois que le concept général aura été mis en œuvre et testé.
14. Remarques importantes
Il n’est pas possible de prévoir le montant de la consommation fiscale pour les mois à venir, de sorte que l’impact sur le plan MM est basé sur des hypothèses. Les paramètres et les mécanismes peuvent et doivent être ajustés pendant la phase de testnet public, et il est important de tester minutieusement l’impact et les mécanismes sur le testnet avant d’envisager un lancement sur le mainnet.
Il s’agit d’une proposition qui signale que la gouvernance et la communauté souhaitent que cette approche soit mise en œuvre. La mise en œuvre sera un effort/contribution volontaire de StrathCole, il n’y a donc pas d’échéances fixes. Une autre option est qu’une équipe rémunérée décide de se mettre en avant et de faire un devis pour le travail et obtienne l’approbation de la gouvernance. Cela pourrait éventuellement accélérer le calendrier de mise en œuvre.
15. Risques
Le risque d’hyperinflation est atténué en utilisant uniquement des fonds redirigés vers un pool distinct à partir des recettes fiscales de la période précédente. Le MM ne peut donc pas battre monnaie.
Les principaux risques de cette mise en œuvre sont les suivants :
- des brûlures réduites de LUNC ou de USTC (pas les deux) dans le cas où l’échange n’est utilisé que très rarement et d’un seul côté.
- la déception de la communauté aux attentes non satisfaites
Annexe 1 : Résumé non technique
Pour résumer l’idée en termes non techniques, nous pouvons la décrire comme suit :
Important : il ne s’agit pas d’une proposition de repeg et l’USTC n’est pas considéré comme un actif stable.
Nous mettrons en place des garde-fous pour le module de marché, afin qu’il ne se monnaye pas pour les swaps. Nous reconnaissons que cela s’écarte du concept original du MM. 60 % du produit de la taxe sur les brûlures (PAS les brûlures manuelles par les portefeuilles) sont redirigés vers le pool de swaps du MM pour la période suivante.
Le prix de l’USTC sera communiqué par l’oracle de la chaîne et ne sera plus fixé à 1 dollar en interne. Cela permet d’échanger à la valeur réelle du marché, en donnant le montant correct ou LUNC pour USTC et vice versa.
Lors de l’échange USTC contre LUNC, LUNC est fourni par le pool MM et l’utilisateur donne USTC au pool à son tour. Lors de l’échange de LUNC contre USTC, USTC est fourni par le pool et LUNC est rendu par l’utilisateur. Ce n’est pas exactement la façon dont le module de marché fonctionnait initialement (battre monnaie et brûler), mais il conserve la logique des calculs. Le monnayage est remplacé par l’utilisation d’un pool pré-rempli.
La commission de chaque échange (qui n’inclut pas la taxe, mais 0,35 % de commission d’écart) sera répartie à raison de 50 % pour 50 % entre les brûleurs et le pool Oracle.
Les incitations à utiliser le MM pour échanger pourraient être des options d’arbitrage entre les prix CEX, les prix DEX et le module de marché. En effet, le prix en chaîne de l’oracle n’est mis à jour que toutes les 30 secondes, ce qui signifie qu’il est souvent en retard sur les prix CEX. Les prix des DEX varient également souvent entre eux et avec les CEX, ce qui offre d’autres possibilités d’arbitrage.
En outre, l’utilisation du MM pour échanger pourrait être une incitation pour les utilisateurs qui veulent causer des brûlures d’un côté (LUNC ou USTC) par leurs échanges (voir les mécanismes concernant les brûlures du pool mensuel).
La plupart des risques sont atténués par des mesures de sauvegarde. Mais la communauté risque toujours d’être déçue si elle attend de ces mesures un effet supérieur à celui qui est obtenu. Il est également possible que les brûlures soient plus faibles que prévu, au cas où les utilisateurs n’utiliseraient que le MM pour échanger des USTC contre des LUNC jusqu’à ce que le pool soit épuisé, mais cela aurait en retour l’avantage d’augmenter les brûlures d’USTC.
Annexe 2 : Questions et réponses
Q : Cette situation peut-elle entraîner une nouvelle hyperinflation de la LUNC ?
La frappe de monnaie est évitée dans les swaps, le LUNC disponible est limité au montant du pool, basé sur les recettes fiscales de la période précédente.
Q : S’agit-il d’un ré-encodage de USTC ?
L’USTC est un actif spéculatif et cette idée le traite comme tel. Il est évalué au prix du marché pour les swaps.
Q : Qu’en est-il de la combustion de Binance ? Ils ont cessé de brûler lorsque nous avons battu monnaie précédemment.
R : Nous évitons complètement de battre monnaie avec cette approche. Bien que nous ayons initialement des brûlures plus faibles lorsque nous redirigeons des parties de la taxe vers le pool de swap, tous les soldes restants du pool sont brûlés à la fin de la période.
Q : Qu’est-ce que le “MM swap pool” ?
R : Il s’agit du montant de LUNC et USTC qui peut être utilisé dans les swaps au cours d’une période. Le montant réellement échangé peut être plus élevé, car le solde est à nouveau augmenté par des échanges avec l’autre côté.
Q : ? ?? Puis-je avoir un exemple ?
R : Bien sûr : Imaginez que 1 USTC vaut 200 LUNC. Au cours de la période précédente, nous avons reçu 667 millions de LUNC de recettes fiscales. À un taux de 60 %, cela permettrait de remplir le pool de swaps MM avec 400 millions de LUNC pour la période suivante. Par conséquent, si 2 000 000 USTC sont échangés contre des LUNC par l’intermédiaire du MM, l’utilisateur recevra à son tour 400 millions de LUNC de la réserve, ce qui empêchera tout échange ultérieur dans cette direction. Mais si les échanges se font maintenant de LUNC à USTC (par exemple 100 millions de LUNC pour 500 000 USTC), ces 100 millions de LUNC seront à nouveau disponibles pour l’échange.
Q : Mais cela ne ferait-il pas baisser les brûlures de manière significative dans l’ensemble, si une telle quantité est redirigée vers la piscine ?
Tous les soldes restants dans le pool seront brûlés au début de l’époque suivante. Cela dépend du comportement de l’échange si plus de LUNC est brûlé et moins d’USTC ou plus d’USTC et moins de LUNC.
Q : Mais n’est-ce pas inutile ?
R : Non, chaque échange donne lieu à une commission de 0,35 % qui est répartie entre Burn (50 %) et Oracle Pool (50 %). Plus il y a d’échanges, donc plus les échanges sont fréquents, plus les frais sont élevés.
Q : D’accord, mais à combien d’échanges pouvons-nous nous attendre ? Tout le monde ne pourrait-il pas échanger ses récompenses USTC contre des récompenses LUNC ?
R : Cela pourrait arriver, mais même dans ce cas, l’offre de USTC diminuerait à son tour. Mais lorsque vous regardez le ratio LUNC/USTC au cours des derniers mois, vous vous rendez compte que la valeur a fluctué principalement entre 190 et 230 LUNC par USTC. Cela suggère que les gens utilisent les deux sens des transactions.
Q : D’accord, à quel volume pouvons-nous nous attendre ?
R : C’est très difficile à estimer et cela dépendra du volume sur la chaîne et de l’arbitrage. Les paires LUNC/USTC sur nos DEX ont eu un volume d’environ 120-130k USD par mois récemment. En supposant que ce volume soit réparti de manière égale entre les DEX et le MM, cela conduirait à un volume MM d’une valeur de 30 à 40 000 USD.
Q : Mais vous avez dit que l’USTC est évaluée à sa valeur de marché. Comment un arbitrage serait-il possible ?
R : Les prix de l’oracle sur la chaîne sont communiqués toutes les 30 secondes. Les prix CEX peuvent fluctuer assez rapidement, surtout en cas de forte volatilité. Les prix DEX ont également montré une volatilité significative au cours des derniers mois, ce qui pourrait offrir des options d’arbitrage avec le MM. Cela n’est toutefois pas garanti.
Q : Quels sont les principaux risques ? Et comment sont-ils atténués ?
R : Comme nous l’avons dit, le risque d’hyperinflation est atténué par des frontières et des limites très strictes. Le risque d’erreurs techniques dans la mise en œuvre est atténué par un examen approfondi et, si la communauté est prête à payer, par un audit du code (ce qui serait recommandé). Dans le cas improbable d’une faille majeure, 33,4 % des validateurs pourraient procéder à un “arrêt d’urgence” de la chaîne en vue d’un correctif. On ne s’attend pas à ce que cela soit nécessaire.
Le risque le plus probable est d’avoir des attentes trop élevées, ce qui peut conduire à des déceptions.
Un autre risque est de perdre une partie des brûlures LUNC au cas où le MM ne serait utilisé que dans un seul sens (USTC->LUNC). L’équivalent de USTC serait alors brûlé en excès.
Q : Qui le développe ? Est-il prêt ? Quel est le calendrier ?
R : Je (StrathCole) propose de développer ce projet volontairement. Comme je le fais pendant mon temps libre, il n’y a pas de calendrier fixe possible. Je m’attends à ce que la mise en œuvre pure (sans les tests) prenne 2 à 3 semaines. Il est toujours possible qu’une équipe propose un devis pour le travail et obtienne l’approbation de la communauté pour l’implémenter à la place.
Q : Si vous le faites volontairement, pourquoi avez-vous besoin d’une proposition ?
R : Parce que je ne peux pas consacrer du temps au développement sans une proposition de signalisation qui montre que cette approche est souhaitée par la communauté/gouvernance. De nombreuses réserves ont été émises à l’encontre de l’ouverture du module de marché. L’approbation de ce module est donc une condition préalable pour que je puisse personnellement commencer le travail de développement.
Q : Quelle est la durée des tests ?
R : Ce n’est pas prévisible. Comme il s’agit d’une partie essentielle de la blockchain, nous devons tester cette approche sous toutes les formes possibles. Il s’agit notamment de simuler des manipulations de prix, des pannes d’alimentation de l’oracle, la volatilité des prix, le volume des échanges, etc. Plus vous serez nombreux à participer aux tests et aux vérifications, mieux ce sera.
Q : L’examen/audit ayant été mentionné, il ne s’agit pas d’un travail gratuit ?
R : Non. L’équipe qui propose un devis pour un examen, ou la société d’audit qui propose un audit, demanderait certainement des fonds à cet effet.
Q : Que se passe-t-il si nous voulons utiliser le MM dans sa forme originale plus tard ?
R : Les modifications seront conçues de manière à être aussi minimes que possible en ce qui concerne le passage de l’approche de la menthe/brûlée à l’approche du pool. Il est possible de revenir en arrière pour une utilisation ultérieure du MM incluant le mécanisme de mint/burn.
