12188 | Terra Classic Markt Modul 2.0 (nicht-geprägte Version)
Quelle von:
- https://validator.info/terra-classic/governance/12188
- https://github.com/Market-Module-2-0/proposal/blob/main/proposal-nomint.md
Terra Classic Markt-Modul 2.0
Version ohne Minze
Eine Netto-Deflationsmaschine, die sich ohne Hypermining öffnen kann, sich selbst drosselt, wenn das Angebot schrumpft, und die nicht durch veraltete Preise ausgetrickst werden kann.
Dieses basiert auf dem ursprünglichen Entwurf des “Terra Classic Market-Module 2.0“, enthält jedoch Mechanismen zur Vermeidung des Mint/Burns, der bei einigen Community-Mitgliedern für Bedenken sorgte.
Wenn Sie eine kurze nicht-technische Zusammenfassung wünschen, gehen Sie bitte zu Anhang 1 (Zusammenfassung) und Anhang 2 (Fragen und Antworten).
1. Kontext & Ziele
2022 hat zwei harte Lektionen gelernt:
- Unbegrenzte Kapazität ist tödlich – die Erhöhung des Basispools und die Verkürzung der Pool-Recovery-Periode (PRP) ermöglichen es den Händlern, schneller zu prägen, als der Markt absorbieren kann, und zerstören damit LUNC.
- Die harte 1-Dollar-Bindung ist tödlich – die Bewertung des UST mit 1 Dollar, während er mit Pfennigen gehandelt wurde, führte zu einer Hyperinflation.
Heute ( 25. Juni 2025 ) sitzen wir auf ca. 6,50 T LUNC und 6 B USTC; die Verbrennungen betragen nur ≈ 1,3 B LUNC / Monat (0,02 %). Die Gemeinschaft will das Marktmodul (MM) so schnell wie möglich zurück, um den Nutzen und den Gebührenfluss wiederherzustellen – aber sie wird nur einen kontinuierlichen Rückgang des Nettoangebots akzeptieren.
2. Wie das Marktmodul historisch geprägt wurde
2.1 base_pool – die “virtuelle SDR-Reserve”
Wenn Sie USTC → LUNC (oder umgekehrt) tauschen, tut das Modul so, als ob Sie mit einem virtuellen SZR-Pool interagieren würden. Die eigentliche Berechnung beinhaltet:
- Umrechnung des USTC-Betrags in seinen SZR-Wert unter Verwendung der aktuellen Orakelpreise
- Bestimmen, wie viel LUNC Sie prägen müssen, damit die virtuelle Konstanten-Produkt-Kurve ausgeglichen bleibt
- Aktualisierung der durch den Swap entstandenen SZR-“Schuld”
Vereinfacht gesagt, wenn Sie USTC → LUNC tauschen, stellt sich das Modul als ein SDR/LUNC AMM dar, dessen eine Seite ein virtueller Pool der Größe base_pool ist:
ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before
Ein größerer base_pool ermöglicht es, mit einem einzigen Swap mehr LUNC zu geben, bevor sich der Kurs bewegt.
2.2 PRP – der Nachfüll-Timer
Nach einem Swap merkt sich das Modul ein SZR-Defizit d (wie stark der virtuelle SZR-Pool entleert ist). Bei jedem Block “füllt” es einen festen Anteil wieder auf:
d_next = d_current × ( 1 – 1 / PRP )
Jeder Block stellt 1/PRP des Defizits wieder her. Also:
- Kurzes PRP → schnelles Nachfüllen → kann Minuten später wieder drucken
- Langes PRP → langsames Nachfüllen → muss Stunden oder Tage warten
Die gesamte Swap-Kapazität pro Tag (wenn Händler sie jedes Mal vollständig entleeren) beträgt ungefähr:
swap_cap_day ≈ 2 × base_pool / ( PRP / 14 400 )
(14 400 ≈ Blöcke pro Tag auf Terra Classic).
Diese Formel leitet sich davon ab, wie viel SZR pro Tag verbraucht und wieder aufgefüllt werden können, ohne dass Swaps unmöglich sind.
3. Ansatz ohne Minting (epochenbasiert)
Derzeit wird die Burn Tax auf der Kette zu 10% in den Community Pool, zu 10% in den Oracle Pool und zu 80% in den Burn aufgeteilt.
Um das Prägen von Token zu vermeiden, wird vorgeschlagen, 60% in einen temporären “Marktmodul-Liquiditätspool” umzuleiten. Dadurch wird der unmittelbare Burn durch die Steuer zwar auf 20% reduziert, aber in jeder 30-Tage-Epoche werden immer noch zusätzliche Burns stattfinden (siehe unten).
Im ersten Block H₀ jeder 30-Tage-Epoche, für jeden Token separat (USTC und LUNC):
- Jeder Token (USTC und LUNC), der den Liquiditätspool des Marktmoduls erreicht hat, wird in einen eigenen Swap-Pool für das Marktmodul verschoben. Dies ist die Menge dieses Tokens, die den Nutzern zum Swappen zur Verfügung steht.
- Dies entspricht 75 % der Steuerverbrennungen des letzten Monats für jeden Token.
- Anstatt beim Tausch über das Marktmodul Münzen zu prägen und zu verbrennen, werden Token einfach aus diesem Pool entnommen und diesem hinzugefügt.
- Zu Beginn der nächsten 30-Tage-Epoche werden alle Reste in den Pools verbrannt.
4. Adaptive base_pool & PRP für die Epoche
Wir wollen Ausbrüche, wenn die Volatilität in die Höhe schießt, aber wir müssen immer noch unter den monatlichen Freibetrag passen.
4.1 Wählen Sie einen Burst-Faktor
Standard F = 0,07 → höchstens 10 % des aktuellen Liquiditätspoolsaldos können an einem einzigen Tag genutzt werden.
Gewünschte_Tagesobergrenze = pool_balance × F
4.2 Lösen Sie für base_pool
Neuordnung der Formel für die Tageskappe:
base_pool_raw = gewünschte_tägliche_Kapazität × PRP / ( 2 × 14 400 )
4.3 PRP auf der Angebotsskala
PRP = max( 14 400 , 14 400 × ( S / 1 T ) )
6,5 T Zufuhr → PRP ≈ 93 600 Blöcke (6,5 Tage).
Wenn das Angebot sinkt, wird das Nachfüllen schneller – der Wasserhahn schrumpft, während sich der Tank leert.
4.4 Endgültige Klammern
base_pool = min( base_pool_raw, 0.00010 × supply_value_in_SDR, 5 000 000 SDR ) // absolutes Dach
Beispiel für die erste Epoche (heute)
| Artikel | Wert |
|---|---|
| tax_30d (B₀) | 1.0 B LUNC |
| in den Pool umgeleitet = 0,6 × B₀ | 600M LUNC ≈ 24.400 SDR |
| PRP (6,5 T Vorrat) | 93 600 Blöcke |
| gewünschte_tägliche_Kappe (z.B. F = 0.1) | 60M LUNC (abhängig vom aktuellen Guthaben) |
| base_pool_raw | ≈ 7,9 k SDR |
| base_pool nach Klammern | 7,9 k SDR |
| Poolnutzung pro Tag (max) | 2 × 7,9 k / 6,5 ≈ 2,45 k SDR ≈ 60,4 M LUNC |
60,4 M > 60 M, also ist F, nicht die PRP-Klammer, die aktive Bremse.
5. Live-Kurseingabe & Anti-Manipulationswächter
| Komponente | Regel |
|---|---|
| Zeitraum der Preisabstimmung | 5 Blöcke ≈ 30 s |
| USTC-Preis | price_uusd(USTC) = Stimmrechtsgewichteter Median in diesem Zeitraum |
| Quorum-Autokill | Wenn einer der Vermögenswerte Preisstimmen von < 50 % VP für 25 Blöcke hat → MM.enabled=false bis das Quorum wiederhergestellt ist |
| TWAP Sanity Klammer | Jeder Swap scheitert, wenn der Peg-Preis um mehr als 10 % von einem Oracle-TWAP mit 45 Blöcken (gespeist von denselben Orakeln) abweicht. |
| Stabile→stabile Route | Im Code hart deaktiviert (ErrStableSwapDisabled) |
6. Absolute Bremsen & Governance
- ⅔ Supermajorität kann MM jederzeit schließen
7. Verbrennungen
Am Ende der 30-Tage-Epoche werden alle Restbestände im Pool verbrannt. Je nach Swap-Verhalten der Nutzer kann dies ähnlich sein wie die Verbrennungen, die ohne diesen Ansatz stattgefunden hätten, oder eher an einen der beiden Token angelehnt sein (siehe Zusammenfassung in Anhang 1).
8. Szenarien
8.1 Bull-but-boring (Versorgungsrenditen)
Beispiel mit getrennten Berechnungen für beide Token:
LUNC im normalen Wachstumsszenario
- Die LUNC-Steuereinnahmen erreichen in Epoche 3 2 B / Monat, die USTC-Einnahmen erreichen 560 K / Monat.
- PRP immer noch > 3 Tage, base_pool begrenzt durch Zulage.
Szenario a.) Die Benutzer tauschen gleichermaßen zwischen LUNC und USTC hin und her
| Epoche | LUNC Steuer | USTC-Steuer | Pool LUNC vor | Pool USTC vor | Pool LUNC nach | Pool USTC nach |
|---|---|---|---|---|---|---|
| 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 |
| Verbrannt | 2.76B | 822 K |
In diesem Szenario werden die gleichen Mengen an LUNC und USTC verbrannt wie ohne geöffnetes MM.
Szenario b.) Die Nutzer tauschen hauptsächlich (80%) von USTC in LUNC, angenommener Preis der Einfachheit halber: 200 LUNC/USTC (in Wirklichkeit würde dieser Preis schwanken).
| Epoche | LUNC Steuer | USTC-Steuer | Pool LUNC vor | Pool USTC vor | Pool LUNC nach | Pool USTC nach |
|---|---|---|---|---|---|---|
| 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 |
| Verbrannt | 552 M | 11.87 M |
In diesem Szenario würden 2,2 B LUNC weniger verbrannt werden als ohne das offene MM. Im Gegenzug würden 11 M USTC mehr verbrannt werden.
Szenario c.) Die Nutzer tauschen hauptsächlich (80%) von LUNC in USTC, angenommener Preis der Einfachheit halber: 200 LUNC/USTC (in Wirklichkeit würde dieser Preis schwanken).
| Epoche | LUNC Steuer | USTC-Steuer | Pool LUNC vor | Pool USTC vor | Pool LUNC nach | Pool USTC nach |
|---|---|---|---|---|---|---|
| 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 |
| Verbrannt | 2.89 B | 164.4 K |
In diesem Szenario würden 130 M LUNC mehr verbrannt werden als ohne geöffnete MM. Im Gegenzug würden 660 K USTC weniger verbrannt werden.
8.2 Flash-Absturz und Orakel-Ausfall
- USTC fällt auf $0,004 (80 LUNC/USTC); zwei Top-Validierer offline.
- Nach 30 s Quorum < 50 % → MM wird geschlossen.
- In der nächsten Epoche brechen die Steuereinnahmen für beide Token zusammen.
LUNC im Krisenszenario
- Die Steuereinnahmen von LUNC brechen auf 0,2 B/Monat ein.
- USTC-Steuereinnahmen brechen auf 56 K/Monat ein
Szenario a.) Die Benutzer tauschen gleichermaßen zwischen LUNC und USTC hin und her
| Epoche | LUNC Steuer | USTC-Steuer | Pool LUNC vor | Pool USTC vor | Pool LUNC nach | Pool USTC nach |
|---|---|---|---|---|---|---|
| 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 |
| Verbrannt | 360 M | 100.8 K |
In diesem Szenario werden die gleichen Mengen an LUNC und USTC verbrannt wie ohne geöffnetes MM.
(*) MM wird in der Mitte dieser Epoche aufgrund eines Orakelausfalls angehalten und nicht wieder aufgenommen. Von diesem Zeitpunkt an finden keine weiteren Swaps mehr statt.
Szenario b.) Nutzer tauschen hauptsächlich (80%) von USTC zu LUNC, angenommener Preis der Einfachheit halber: 80 LUNC/USTC (wie im Crash-Szenario definiert).
| Epoche | LUNC Steuer | USTC-Steuer | Pool LUNC vor | Pool USTC vor | Pool LUNC nach | Pool USTC nach |
|---|---|---|---|---|---|---|
| 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 |
| Verbrannt | 192 M | 2.13 M |
In diesem Szenario würden 150 M LUNC weniger verbrannt werden als ohne das MM offen. Im Gegenzug würden 2 M USTC mehr verbrannt werden.
(*) MM wird in der Mitte dieser Epoche aufgrund eines Orakelausfalls angehalten und nicht wieder aufgenommen. Von diesem Zeitpunkt an finden keine weiteren Swaps mehr statt.
Szenario c.) Die Nutzer tauschen hauptsächlich (80%) von USTC zu LUNC, angenommener Preis der Einfachheit halber: 80 LUNC/USTC (wie im Crash-Szenario definiert).
Wir lassen dieses Szenario außen vor, da es unwahrscheinlich ist, dass die Leute bei einem angenommenen Preissturz von LUNC auf USTC umsteigen.
Selbst im Katastrophenfall schrumpft der Float für beide Token unabhängig voneinander.
9. Spread-Gebührenpolitik für MM-Swaps
| Zustand | Gebühr angewandt | Anmerkungen |
|---|---|---|
| MM deaktiviert (keine Swaps) | — | Keine Gebühr, keine Verbrennung; die Route ist inert. |
| MM aktiviert & Freibetrag > 0 | 0,35 % des Nominalwerts | Wird in der Ausgabeanlage gesammelt (LUNC auf USTC→LUNC Swaps, USTC auf LUNC→USTC). |
| Erlaubnis erschöpft (Epochenobergrenze erreicht) | — | Der Tausch wird abgelehnt; keine Gebühr, keine Verbrennung. |
Begründung
- Machbares Niveau – 0,35 % ist niedrig genug, um die Arbitrage gegenüber den typischen CEX-Spreads (≈ 0,10 – 0,25 %) profitabel zu halten und dennoch die Orakel- und Halterkosten zu decken.
- Keine Doppelbesteuerung – Die kettenweite Verbrennungssteuer von 0,50 % gilt nicht für diese modulinternen Swaps; die Spread-Gebühr ersetzt sie.
- Buchhaltung – Gebühren werden zu 50% an Burn und zu 50% an den Oracle Pool weitergeleitet.
- Stabiler-zu-stabiler Pfad – Vollständig deaktiviert (§ 4.4), so dass die Gebühr immer nur für LUNC ↔ USTC-Trades gilt.
10. Kompatibilität mit Oracle-Modulen
Die Reaktivierung des MM mit dynamischer Preisgestaltung erfordert Aktualisierungen der aktuellen Orakel-Infrastruktur:
- USTC-Preiseinspeisung – USTC muss dem Orakel-Voting-Set hinzugefügt werden. Das MM geht derzeit von einem festen Preis von 1 $ aus. Diese Logik muss entfernt und durch Echtzeitpreiseingaben von Validatoren ersetzt werden.
- Erweiterung des Feeder-Anbieters – Der bestehende Feeder unterstützt nur begrenzte Quellen. Um eine genaue und manipulationssichere Preisgestaltung zu gewährleisten, müssen zusätzliche Datenanbieter (z.B. mehrere CEXs, Aggregatoren) integriert werden.
- Einarbeitung der Prüfer – Alle Prüfer müssen bei der Aktualisierung ihrer Oracle-Feeder-Binärdateien und -Konfigurationen zur Unterstützung von USTC angeleitet werden. Dokumentation und Koordination der Einführung sind erforderlich, um Quorum-Ausfälle zu vermeiden.
- (Optional) Überarbeitung des Feeders – Eine vollständige Überarbeitung der Feeder-Binärdatei ist nicht unbedingt erforderlich, wird aber dringend empfohlen. Der aktuelle Feeder ist veraltet und bietet keine Unterstützung für moderne APIs, keine Fallback-Logik und keine angemessene Fehlerbehandlung.
Diese Änderungen müssen vorgenommen werden, bevor das MM wieder geöffnet wird. Ohne diese Änderungen sind die Preiseingaben ungültig oder nicht vorhanden, wodurch die automatischen Abschaltmechanismen ausgelöst werden.
11. Fahrplan
- Code-Zusammenführung für Testnet & Überprüfung – ≈ 500-1000 Zeilen Code (Pool-Logik, adaptive Regler, Kill-Switch).
- Öffentliches Testnetz – injizieren Sie Preisspitzen, Quorum-Drops, 10× Burn Bursts.
- Mainnet-Upgrade (zweistufig)
- Modul bereitstellen inaktiv
- Aktivieren Sie an der nächsten Epochengrenze, nachdem der Pool während der Epoche gefüllt wurde.
- 90-Tage-Post-Mortem – Änderung 60 % Umleitung oder F nur durch Hard Fork (Ketten-Upgrade).
12. Was wir gewinnen
- Sofortige Wiedereröffnung – Händler können an Tag 1 Arbitrage betreiben.
- Garantierte Deflation – das Angebot muss immer noch jede Epoche von 30 Tagen fallen.
- Elastische Drosselung – wenn das Angebot schrumpft, verlangsamt sich das Nachfüllen und der Pool schrumpft.
- Oracle-sicher – 30 s Verzögerung kann nicht aufgeblasen werden; 75 s Verzögerung tötet das Modul.
- Oracle-Pool auffüllen – Spread-Gebühren aus dem Marktmodul werden in den Oracle-Pool für zukünftige Belohnungen umgeleitet (50%)
- Verbrennungen – 50% der Streugebühr werden verbrannt
13. Freiwillige Verbrennungen
Zu diesem Zeitpunkt stammt ein großer Teil des verbrannten Angebots aus freiwilligen Verbrennungen (Münzen, die an das On-Chain-Verbrennungsmodul – terra1…anxu – geschickt werden).
Diese Gelder sollten von der Berechnung der 30-Tage-Epochen-Burns ausgeschlossen werden, um nicht die Unterstützung von Unternehmen wie Binance und Community-Mitgliedern zu verlieren. Dies wird die möglichen verfügbaren Token einschränken. Es sollte in Betracht gezogen werden, die Pools bei Bedarf zu erweitern. Dies müsste jedoch mit den betroffenen Einrichtungen besprochen werden, sobald das allgemeine Konzept umgesetzt und getestet wurde.
14. Wichtige Hinweise
Die Höhe der Steuerabgaben für die kommenden Monate kann nicht vorhergesagt werden, so dass die Auswirkungen auf den MM-Plan auf Annahmen beruhen. Parameter und Mechanismen können und sollten während der öffentlichen Testnet-Phase angepasst werden, und es ist wichtig, die Auswirkungen und Mechanismen im Testnet gründlich zu testen, bevor eine Veröffentlichung im Mainnet in Betracht gezogen wird.
Dies ist ein Vorschlag, der signalisiert, dass die Verwaltung und die Gemeinschaft diesen Ansatz umgesetzt sehen wollen. Die Umsetzung wird eine freiwillige Anstrengung/Beitrag von StrathCole sein, daher gibt es keine festen Fristen. Eine alternative Option ist, dass ein bezahltes Team sich entschließt, ein Angebot für die Arbeit abzugeben und die Zustimmung der Governance erhält. Dies könnte den Zeitplan für die Implementierung eventuell beschleunigen.
15. Risiken
Das Risiko einer Hyperinflation wird dadurch gemildert, dass nur Gelder verwendet werden, die aus den Steuereinnahmen der vorangegangenen Periode in einen eigenen Pool umgeleitet werden. Dadurch bleibt die MM-Prägung deaktiviert.
Die Hauptrisiken dieser Implementierungen sind:
- reduzierte Verbrennungen von entweder LUNC oder USTC (nicht beides) für den Fall, dass die Auslagerung nur sehr selten und einseitig genutzt wird
- Enttäuschung der Gemeinschaft über nicht erfüllte Erwartungen
Anhang 1: Non-Tech Zusammenfassung
Um die Idee in nicht-technischen Begriffen zusammenzufassen, können wir sie wie folgt beschreiben:
Wichtig: Dies ist KEIN Repeg-Vorschlag und behandelt USTC NICHT als stabile Anlage.
Wir werden Schutzmaßnahmen für das Marktmodul einführen, so dass es nicht auf Swaps angerechnet wird. Wir sind uns bewusst, dass dies vom ursprünglichen Konzept des MM abweicht. 60% der Einnahmen aus der Verbrennungssteuer (KEINE manuellen Verbrennungen durch Wallets) werden für die nächste Periode in den MM-Swap-Pool umgeleitet.
Der Preis von USTC wird vom Kettenorakel gemeldet und ist nicht mehr intern auf $1 festgelegt. Dies ermöglicht einen Tausch zum realen Marktwert, der den korrekten Betrag oder LUNC für USTC ergibt und umgekehrt.
Beim Tausch von USTC gegen LUNC wird LUNC aus dem MM-Pool bereitgestellt und der Benutzer gibt seinerseits USTC an den Pool ab. Beim Tausch von LUNC gegen USTC wird USTC aus dem Pool ausgegeben und LUNC wird vom Benutzer zurückgegeben. Dies ist nicht genau die Art und Weise, wie das Marktmodul ursprünglich funktionierte (mint and burn), aber die Logik für die Berechnungen bleibt erhalten. Die Münzprägung wird durch die Verwendung eines vorgefüllten Pools ersetzt.
Die Gebühr für jeden Swap (ohne Steuer, aber mit 0,35% Spread-Gebühr) wird im Verhältnis 50:50 zwischen Burns und dem Oracle Pool aufgeteilt.
Anreize, das MM zum Swappen zu nutzen, könnten Arbitrage-Optionen zwischen CEX-Preisen, DEX-Preisen und dem Marktmodul sein. Dies geschieht, weil der On-Chain-Kurs des Orakels nur alle 30 Sekunden aktualisiert wird, was bedeutet, dass er oft hinter den CEX-Kursen zurückbleibt. Auch die DEX-Preise weichen oft untereinander und von den CEXen ab, was weitere Arbitragemöglichkeiten bietet.
Darüber hinaus könnte die Verwendung des MM zum Swappen einen Anreiz für Benutzer darstellen, die durch ihre Swaps Verbrennungen auf einer Seite (entweder LUNC oder USTC) verursachen wollen (siehe Mechanismen zu den monatlichen Poolverbrennungen).
Die meisten Risiken werden durch Sicherheitsvorkehrungen gemildert. Aber es besteht immer noch das Risiko, dass die Gemeinschaft enttäuscht wird, wenn sie von diesen Maßnahmen eine Wirkung erwartet, die über das hinausgeht, was erreicht wird. Es ist auch möglich, dass die Verbrennungen geringer ausfallen als erwartet, falls die Nutzer das MM nur dazu nutzen, USTC in LUNC zu tauschen, bis der Pool erschöpft ist. Dies hätte jedoch wiederum den Vorteil, dass die Verbrennungen von USTC zunehmen.
Anhang 2: Fragen und Antworten
F: Kann dies zu einer weiteren Hyperinflation in der LUNC führen?
A: Nein. Bei Swaps wird die Münzprägung vermieden, das verfügbare LUNC ist auf den Betrag im Pool beschränkt, der auf den Steuereinnahmen der vorherigen Periode basiert.
F: Handelt es sich dabei um eine Neuverknüpfung von USTC?
A: Nein. USTC ist ein spekulativer Vermögenswert und wird bei dieser Idee auch so behandelt. Er wird zum Marktpreis für die Swaps bewertet.
F: Was ist mit Binance Burns? Sie haben aufgehört zu brennen, als wir vorher geprägt haben.
A: Wir vermeiden bei diesem Ansatz die Prägung vollständig. Während wir anfangs geringere Burns haben, wenn wir Teile der Steuer in den Swap-Pool umleiten, werden alle verbleibenden Guthaben des Pools am Ende der Periode verbrannt.
F: Was ist der “MM-Swap-Pool”?
A: Es handelt sich um den Betrag von LUNC und USTC, der während eines Zeitraums für Swaps verwendet werden darf. Der tatsächlich getauschte Betrag kann höher sein, da der Saldo durch Swaps auf die andere Seite wieder erhöht wird.
Q: ??? Kann ich ein Beispiel haben?
A: Sicher: Stellen Sie sich vor, 1 USTC ist 200 LUNC wert. In der vorangegangenen Periode hatten wir 667M LUNC Steuereinnahmen. Bei einer Rate von 60% würde dies den MM-Swap-Pool mit 400 Mio. LUNC für die nächste Periode füllen. Wenn also jetzt 2.000.000 USTC über das MM in LUNC geswapt werden, würde dies dem Nutzer wiederum 400M LUNC aus dem Pool bescheren, was weitere Swaps in dieser Richtung effektiv verhindert. Wenn nun aber Swaps von LUNC zu USTC stattfinden (z.B. 100M LUNC für 500.000 USTC), dann wären diese 100M LUNC wieder für Swaps verfügbar.
F: Aber würde das die Verbrennungen nicht insgesamt deutlich senken, wenn so viel in den Pool umgeleitet wird?
A: Nein. Alle verbleibenden Guthaben im Pool würden zu Beginn der nächsten Epoche verbrannt werden. Es hängt vom Swap-Verhalten ab, ob mehr LUNC verbrannt wird und weniger USTC oder mehr USTC und weniger LUNC.
F: Aber ist das dann nicht sinnlos?
A: Nein, für jeden Swap fällt eine Gebühr von 0,35% an, die auf Burn (50%) und Oracle Pool (50%) verteilt wird. Je mehr Swaps, also je häufiger die Swaps stattfinden, desto mehr Gebühren fallen an.
F: Okay, aber wie viele Swaps können wir erwarten? Würde nicht jeder nur seine USTC-Belohnungen gegen LUNC eintauschen?
A: Das könnte passieren, aber selbst dann würde das Angebot an USTCs wieder sinken. Aber wenn Sie sich das LUNC/USTC-Verhältnis in den letzten Monaten ansehen, stellen Sie fest, dass der Wert meist zwischen 190 und 230 LUNC pro USTC schwankte. Das deutet darauf hin, dass die Menschen beim Handel beide Richtungen nutzen.
F: Gut, welches Volumen können wir dann erwarten?
A: Das ist sehr schwer abzuschätzen und hängt vom On-Chain-Volumen und auch von der Arbitrage ab. Die LUNC/USTC-Paare auf unseren DEXes hatten kürzlich ein Volumen von etwa 120-130k USD pro Monat. Wenn man davon ausgeht, dass sich dieses Volumen zu gleichen Teilen auf die DEXes und den MM verteilt, würde dies zu einem MM-Volumen im Wert von vielleicht 30-40k USD führen.
F: Aber Sie haben gesagt, dass USTC zum Marktwert bewertet wird. Wie soll da Arbitrage möglich sein?
A: Die Orakelpreise auf Chain werden alle 30 Sekunden gemeldet. Insbesondere bei hoher Volatilität können die CEX-Preise recht schnell schwanken. Auch die DEX-Preise haben in den vergangenen Monaten eine erhebliche Volatilität gezeigt, die Arbitrage-Optionen mit dem MM bieten könnte. Dies ist jedoch nicht garantiert.
F: Was sind die größten Risiken? Und wie werden sie eingedämmt?
A: Wie gesagt, das Risiko einer Hyperinflation wird durch sehr strenge Grenzen und Beschränkungen gemildert. Das Risiko technischer Fehler bei der Implementierung wird durch eine gründliche Überprüfung und, wenn die Community bereit ist, dafür zu zahlen, durch ein Code-Audit (was zu empfehlen wäre) gemildert. Im unwahrscheinlichen Fall eines schwerwiegenden Fehlers könnten 33,4% der Prüfer die Kette für einen Hotfix “notdürftig halten”. Es wird nicht erwartet, dass dies notwendig sein wird.
Das wahrscheinlichste Risiko sind zu hohe Erwartungen, die dann zu Enttäuschungen führen können.
Ein weiteres Risiko besteht darin, dass ein Teil der LUNC-Verbrennungen verloren geht, wenn der MM nur in eine Richtung verwendet wird (USTC->LUNC). Das Äquivalent von USTC würde dann im Übermaß verbrannt werden.
F: Wer entwickelt es? Ist es fertig? Wie sieht der Zeitplan aus?
A: Ich (StrathCole) biete an, dies freiwillig zu entwickeln. Da ich dies in meiner Freizeit tue, gibt es keinen festen Zeitplan. Ich gehe davon aus, dass die reine Implementierung (ohne die Tests) 2-3 Wochen dauern wird. Es besteht immer die Möglichkeit, dass ein Team ein Angebot für die Arbeit abgibt und die Zustimmung der Community zur Umsetzung erhält.
F: Wenn Sie es freiwillig tun, warum brauchen Sie dann einen Vorschlag?
A: Weil ich nicht die Zeit für die Entwicklung aufwenden kann, ohne einen Vorschlag zu machen, der zeigt, dass dieser Ansatz, wie gezeigt, von der Gemeinschaft/Regierung gewünscht wird. Es gab eine Menge Vorbehalte gegen die Öffnung des Marktmoduls. Daher ist die Zustimmung dazu eine Voraussetzung dafür, dass ich persönlich mit der Entwicklungsarbeit beginnen kann.
F: Wie lange werden die Tests dauern?
A: Das ist nicht absehbar. Da es sich um einen kritischen Teil der Blockchain handelt, müssen wir diesen Ansatz auf alle möglichen Arten von Stress testen. Dazu gehören simulierte Preismanipulationen, Ausfälle der Orakel-Zuführung, Preisschwankungen, Swap-Volumen usw. Je mehr helfende Hände sich an den Tests und der Überprüfung beteiligen, desto besser.
F: Da von Überprüfung/Audit die Rede war, ist dies keine kostenlose Arbeit?
A: Nein. Das Team, das einen Kostenvoranschlag für eine Überprüfung erstellen würde, oder die Wirtschaftsprüfungsgesellschaft, die eine Prüfung anbietet, würde sicherlich Mittel dafür beantragen.
F: Was ist, wenn wir das MM später in seiner ursprünglichen Form verwenden möchten?
A: Die Änderungen werden so minimal wie möglich sein, was die Umstellung von Mint/Burn auf den Pool-Ansatz betrifft. Es ist möglich, diese Änderungen für eine spätere Verwendung des MM einschließlich des Mint/Burn-Mechanismus rückgängig zu machen.
