#termmax Jede MLTV-Berechnung auf TermMax hängt von einer Sache ab, über die niemand spricht: wie das Protokoll tatsächlich weiß, was dein Sicherheitenwert gerade wert ist. 🛰️ Oracles erledigen diese unsexy Aufgabe, und sie verdienen mehr Aufmerksamkeit, als sie bekommen.
So spielt das insbesondere bei einem Produkt mit festem Zinssatz und fester Laufzeit eine Rolle: Dein MLTV-Limit (z. B. 0,8) wird anhand einer live ermittelten Bewertung der Sicherheiten berechnet – nicht anhand des Preises zum Zeitpunkt, als du die Position eröffnet hast. Wenn der Oracle-Feed dem echten Markt hinterherhinkt – auch nur kurz – kann sich dein tatsächliches Risiko von dem unterscheiden, was die Oberfläche anzeigt. 🕐📉
Grobe Illustration, warum Verzögerungen wichtig sind: Wenn deine Sicherheit wirklich 950 $ wert ist, der Oracle jedoch aufgrund einer kurzen Feed-Verzögerung noch 1.000 $ meldet, berechnet das Protokoll deine MLTV gegen eine Zahl, die bereits 5 % veraltet ist. Bei einer 0,8-MLTV-Position frisst diese 5%-Lücke ungefähr ein Viertel deines verbleibenden Puffers bis zur Liquidation (0,8 → effektiv näher an 0,84 in der Realität) – das bedeutet: Dein echter Sicherheitsabstand ist geringer, als die angezeigte Zahl vermuten lässt, genau in der Art von schnellen Bewegung, in der diese Lücke tatsächlich zählt. ➗
Das ist kein TermMax-spezifisches Problem – jedes Kreditprotokoll, das nicht mit einem eigenen internen Orderbuch handelt, hat in irgendeiner Form Abhängigkeiten von Oracles. Was an TermMax spezifisch ist: Die Genauigkeit des Oracle beeinflusst das zweistufige Liquidationssystem – ein veralteter Oracle zum falschen Zeitpunkt könnte der Unterschied zwischen einer sauberen Liquidation und einem Fallback-Event sein. 🔻
Wenn du nicht prüfst, welcher Oracle-Feed einen Markt abbildet, bevor du ihn für einen Leverage nutzt, dann ist das genau das, was du in diese Checkliste aufnehmen solltest.
@TermMax #TermMax
So spielt das insbesondere bei einem Produkt mit festem Zinssatz und fester Laufzeit eine Rolle: Dein MLTV-Limit (z. B. 0,8) wird anhand einer live ermittelten Bewertung der Sicherheiten berechnet – nicht anhand des Preises zum Zeitpunkt, als du die Position eröffnet hast. Wenn der Oracle-Feed dem echten Markt hinterherhinkt – auch nur kurz – kann sich dein tatsächliches Risiko von dem unterscheiden, was die Oberfläche anzeigt. 🕐📉
Grobe Illustration, warum Verzögerungen wichtig sind: Wenn deine Sicherheit wirklich 950 $ wert ist, der Oracle jedoch aufgrund einer kurzen Feed-Verzögerung noch 1.000 $ meldet, berechnet das Protokoll deine MLTV gegen eine Zahl, die bereits 5 % veraltet ist. Bei einer 0,8-MLTV-Position frisst diese 5%-Lücke ungefähr ein Viertel deines verbleibenden Puffers bis zur Liquidation (0,8 → effektiv näher an 0,84 in der Realität) – das bedeutet: Dein echter Sicherheitsabstand ist geringer, als die angezeigte Zahl vermuten lässt, genau in der Art von schnellen Bewegung, in der diese Lücke tatsächlich zählt. ➗
Das ist kein TermMax-spezifisches Problem – jedes Kreditprotokoll, das nicht mit einem eigenen internen Orderbuch handelt, hat in irgendeiner Form Abhängigkeiten von Oracles. Was an TermMax spezifisch ist: Die Genauigkeit des Oracle beeinflusst das zweistufige Liquidationssystem – ein veralteter Oracle zum falschen Zeitpunkt könnte der Unterschied zwischen einer sauberen Liquidation und einem Fallback-Event sein. 🔻
Wenn du nicht prüfst, welcher Oracle-Feed einen Markt abbildet, bevor du ihn für einen Leverage nutzt, dann ist das genau das, was du in diese Checkliste aufnehmen solltest.
@TermMax #TermMax
