#termmax @TermMax ...Ich habe die neuesten V2-Fixes von TermMax durchgesehen, und eine Sache ließ mich nicht los.
Früher dachte ich, die meisten DeFi-Bugs liefen auf schlechte Mathematik hinaus.
Diesmal war die Mathematik größtenteils in Ordnung.
Das größere Problem war, dass die falsche Darstellung der Realität verwendet wurde.
Nehmen wir apr().
Die alte Logik sah sich den rohen XT-Saldo der Order an.
Klingt vernünftig, oder?
Aber V2 verwendet nicht den rohen XT-Saldo als Preiszustand. Es nutzt virtualXtReserve.
Dieser Unterschied ist entscheidend...
Stell dir einen Laden vor, in dem das Preisschild durch das interne Kassenbuch des Geschäfts gesteuert wird, aber du beginnst, Preise zu berechnen, basierend darauf, wie viel Bargeld jemand zufällig an der Theke fallen gelassen hat.
Das Bargeld änderte sich.
Das Preis-Modell nicht.
Das ist im Grunde das, was ein direkter XT-Transfer bei der alten APR-Berechnung anrichten könnte.
Ein Saldo kann sich bewegen, ohne dass sich die Kurve bewegt, doch apr() könnte diesen Saldo als neuen Preiszustand behandeln.
Der Fix stellt sicher, dass das Buchhaltungsmodell mit dem ökonomischen Modell übereinstimmt.
Und ich denke, das ist die spannendere Erkenntnis.
Bei finanziellen Smart Contracts ist die gefährliche Frage nicht immer:
„Ist die Formel korrekt?“
Manchmal lautet sie:...
„Füttern wir die Formel mit dem richtigen Zustand?“
Das gleiche Thema taucht auch im Liquidations-Fix auf.
Ein Debt-Oracle mit 18 Dezimalstellen könnte eine Dezimalkonvertierung den Kollateralvergleich kollabieren lassen und so Positionen, die eine 50%-Liquidation erlauben sollten, in eine vollständige Liquidation verwandeln.
Auch hier: kein wirklich kompliziertes Problem mit der Formel.
Es war ein Einheitenproblem.
Deshalb beginne ich, mehr auf diese eher langweilig aussehenden Änderungen zu achten.
Ein einzeiliger Buchhaltungs-Fix kann wichtiger sein als eine auffällige neue Funktion, weil er entscheidet, ob das Protokoll den Markt richtig interpretiert.
Für TermMax würde ich von hier aus genau eine Sache im Blick behalten:
nicht nur, wie viel Liquidität das System hat, sondern ob Preisbildung, Bewertung des Collaterals und Liquidationslogik alle dieselbe wirtschaftliche Realität lesen.....
Dort beginnt „Code funktioniert“ zu werden zu „finanzielle Infrastruktur funktioniert“.
Würdest du lieber zuerst die Formeln prüfen, zuerst den Buchhaltungszustand oder zuerst die Oracle-/Einheitenannahmen?....
Früher dachte ich, die meisten DeFi-Bugs liefen auf schlechte Mathematik hinaus.
Diesmal war die Mathematik größtenteils in Ordnung.
Das größere Problem war, dass die falsche Darstellung der Realität verwendet wurde.
Nehmen wir apr().
Die alte Logik sah sich den rohen XT-Saldo der Order an.
Klingt vernünftig, oder?
Aber V2 verwendet nicht den rohen XT-Saldo als Preiszustand. Es nutzt virtualXtReserve.
Dieser Unterschied ist entscheidend...
Stell dir einen Laden vor, in dem das Preisschild durch das interne Kassenbuch des Geschäfts gesteuert wird, aber du beginnst, Preise zu berechnen, basierend darauf, wie viel Bargeld jemand zufällig an der Theke fallen gelassen hat.
Das Bargeld änderte sich.
Das Preis-Modell nicht.
Das ist im Grunde das, was ein direkter XT-Transfer bei der alten APR-Berechnung anrichten könnte.
Ein Saldo kann sich bewegen, ohne dass sich die Kurve bewegt, doch apr() könnte diesen Saldo als neuen Preiszustand behandeln.
Der Fix stellt sicher, dass das Buchhaltungsmodell mit dem ökonomischen Modell übereinstimmt.
Und ich denke, das ist die spannendere Erkenntnis.
Bei finanziellen Smart Contracts ist die gefährliche Frage nicht immer:
„Ist die Formel korrekt?“
Manchmal lautet sie:...
„Füttern wir die Formel mit dem richtigen Zustand?“
Das gleiche Thema taucht auch im Liquidations-Fix auf.
Ein Debt-Oracle mit 18 Dezimalstellen könnte eine Dezimalkonvertierung den Kollateralvergleich kollabieren lassen und so Positionen, die eine 50%-Liquidation erlauben sollten, in eine vollständige Liquidation verwandeln.
Auch hier: kein wirklich kompliziertes Problem mit der Formel.
Es war ein Einheitenproblem.
Deshalb beginne ich, mehr auf diese eher langweilig aussehenden Änderungen zu achten.
Ein einzeiliger Buchhaltungs-Fix kann wichtiger sein als eine auffällige neue Funktion, weil er entscheidet, ob das Protokoll den Markt richtig interpretiert.
Für TermMax würde ich von hier aus genau eine Sache im Blick behalten:
nicht nur, wie viel Liquidität das System hat, sondern ob Preisbildung, Bewertung des Collaterals und Liquidationslogik alle dieselbe wirtschaftliche Realität lesen.....
Dort beginnt „Code funktioniert“ zu werden zu „finanzielle Infrastruktur funktioniert“.
Würdest du lieber zuerst die Formeln prüfen, zuerst den Buchhaltungszustand oder zuerst die Oracle-/Einheitenannahmen?....
