Ich habe kein Kapital in einen TermMax-Markt eingesetzt, bis ich genau nachvollzogen hatte, was das Protokoll bei Fälligkeit macht, ohne irgendeine Aktion von mir.
Automatisierte Abwicklung bei TermMax bedeutet, dass Positionen zum Nennwert schließen, wenn der Fälligkeitsblock eintrifft. Das zugrunde liegende Asset wird an die Kreditgeber zurückgegeben, Kreditnehmer zahlen den Kapitalbetrag plus eine feste Verzinsung zurück, und das Protokoll übernimmt die Buchhaltung, ohne dass manuell eingegriffen werden muss.
Darauf habe ich immer wieder gedrängt: der Sonderfall. Was passiert, wenn das Sicherheitenvermögen eines Kreditnehmers so stark gefallen ist, dass die Position zum Zeitpunkt der Fälligkeitsabwicklung unterbesichert ist.
Der automatisierte Prozess geht davon aus, dass die Sicherheiten ausreichen. Die Dokumentation dazu, was passiert, wenn dies nicht der Fall ist, war dünner, als ich es mir gewünscht hätte, bevor ich mich zu irgendetwas entschlossen habe. #termmax @TermMax
Ich habe der Settlement-Architektur von TermMax keine Aufmerksamkeit geschenkt, bis ich begann, die Gaskosten zwischen Protokollen mit festverzinslichen Produkten zu vergleichen, und feststellen musste, dass sich die Zahlen in einer Weise auseinanderentwickelten, die erklärungsbedürftig war.
Fixed-Rate-Settlement on-chain ist standardmäßig teuer. Jedes Fälligkeitsereignis, jede Rückzahlung und jeder Positionsabschluss berührt den Vertragszustand in einer Weise, die sich schnell zu Gaskosten aufsummiert – insbesondere über eine große Nutzerbasis hinweg. TermMax V2 hat die Settlement-Ebene gezielt umstrukturiert, um diese Kosten zu senken, ohne die Integrität der Positionsbuchhaltung zu beeinträchtigen.
Was ich prüfen wollte, war, ob die Gaskostenoptimierung aus echten architektonischen Verbesserungen kam oder aus Vereinfachungen, die die Komplexität an eine weniger sichtbare Stelle verlagerten.
Die V2-Dokumentation zeigte mir die Verbesserungen. Es dauerte länger, herauszufinden, welche Annahmen diese Verbesserungen über das Nutzerverhalten treffen. #termmax @TermMax
Ich habe es nicht in Betracht gezogen, Liquidität bei TermMax bereitzustellen, bis ich verstanden hatte, was Single-Sided-Provisioning im Hinblick auf mein Risiko gegenüber traditionellen AMM-Liquiditätspositionen wirklich bedeutet.
In den meisten AMMs sitzen Liquiditätsanbieter gleichzeitig auf beiden Seiten des Marktes. TermMax trennt das. Ein Maker wählt eine Seite – Borrow oder Lend – und legt seine eigenen Spread-Parameter innerhalb dieser Position fest. Das Protokoll zwingt dich nicht, beide Seiten eines Trades mitzumachen, bei dem du nur eine Seite willst.
Dieses Design reduziert die Dynamik des impermanenten Verlusts, die die Liquiditätsbereitstellung in traditionellen AMMs für Fixed-Income-Instrumente unvorhersehbar macht.
Was ich immer wieder geprüft habe, war, wer die andere Seite übernimmt, wenn Spreads aggressiv gesetzt werden, und ob eine geringe Beteiligung auf einer Seite die Preisfindung (Rate Discovery) für alle anderen beeinflusst. #termmax @TermMax
Ich habe dem festen Zinssatz-Mechanismus von TermMax nicht vertraut, bis ich lange genug mit der Mathematik zusammengesessen habe, um zu verstehen, wo der Zinssatz tatsächlich herkommt.
TermMax verwendet maßgeschneiderte Bonding-Kurven statt linearer Preisgestaltung, um feste Zinssätze über unterschiedliche Fälligkeitszeitpunkte hinweg zu berechnen. Die Nichtlinearität ist beabsichtigt. Zinsmärkte verhalten sich nicht linear, und eine Kurve, die so tut, als würden sie es, bepreist das Risiko an den Rändern falsch – dort, wo es am meisten zählt.
Was die Bonding-Kurve hervorbringt, ist ein Zinssatz, der innerhalb einer Laufzeit-Tranche auf Angebot und Nachfrage reagiert, ohne dass eine ständige manuelle Anpassung erforderlich ist. Das Prinzip ist elegant.
Was ich immer wieder geprüft habe, war, ob die Kurvenparameter vom Protokoll gesetzt werden, durch Governance oder durch jemanden mit Interessen, die ich verstehen sollte, bevor ich irgendetwas ausleihe. #termmax @TermMax
Ich habe nicht verstanden, warum TermMax ein Orderbuch mit einem AMM kombiniert, bis ich aufgehört habe zu fragen, welches Modell besser ist, und angefangen habe zu fragen, woran jedes einzelne Modell für sich genommen scheitert.
Reine AMMs haben Schwierigkeiten mit Festzins-Kreditvergabe. Die Constant-Product-Formel wurde nicht für Instrumente mit definierten Laufzeiten und planbaren Cashflows entwickelt.
Reine Orderbücher haben Schwierigkeiten mit Liquidität in dünnen Märkten. TermMax platziert das AMM dort, wo die Liquidität gering ist, und das Orderbuch dort, wo die Teilnehmer Preiskontrolle wünschen.
Diese Kombination ergibt theoretisch Sinn. Was ich jedoch noch untersuche, ist, ob die beiden Mechanismen auch unter Stressbedingungen sauber zusammenspielen oder ob der Hybrid Edge Cases erzeugt, die keines der beiden Modelle allein hervorrufen würde. #termmax @TermMax
Ich habe Netzwerke beobachtet, die sich in der Dokumentation als sauber und zuverlässig präsentierten, unter der Last eines beliebten Token-Launches jedoch zusammenbrachen. Gas-Kriege. Fehlgeschlagene Transaktionen. Mempool-Backlogs, die stundenlang anhielten. Die Netzwerke, die es gut bewältigten, waren nicht unbedingt schneller. Sie waren besser darin, Prioritäten und Sequenzierung unter Druck zu steuern.
Dusk’ Behauptungen zur Überlastprävention beruhen auf seinem Succinct Attestation-Konsens und der deterministischen Blockproduktion, die damit einhergeht. Keine Bieterkämpfe im Mempool. Transaktionen werden gemäß den Protokollregeln aufgenommen – statt über Gebotsauktionen.
Die Design-Logik ist stimmig. Was ich sehen möchte, ist ein tatsächlich hochvolumiges Tokenisierungsereignis, das wirklich auf Mainnet läuft.
Die Dokumentation beschreibt das beabsichtigte Verhalten. Lasttests zeigen das tatsächliche Verhalten. Diese beiden Dinge sind nicht immer dieselbe Unterhaltung.
Ich habe gelernt, langsamer zu werden, sobald ein Projekt eine bestimmte prozentuale Reduktion auf eine Netzwerkbehauptung festlegt. Fünfzig Prozent ist präzise genug, um gemessen zu wirken, und zugleich vage genug, um nicht widerlegbar zu sein, ohne die Benchmark-Methodik zu kennen.
Kadcast ist Dusks P2P-Protokoll, aufgebaut auf einer strukturierten Kademlia-basierten Topologie – statt auf dem Gossip-Flooding, das die meisten Blockchain-Netzwerke verwenden. Gossip-Protokolle sind zwar simpel und robust, aber verschwenderisch. Jeder Knoten erhält jede Nachricht mehrfach. Kadcast routet Nachrichten gezielter und reduziert so redundante Übertragungen.
Das Effizienz-Argument ist real. Strukturiertes Routing nutzt unter normalen Bedingungen weniger Bandbreite als ungeordnetes Gossip.
Meine Frage ist jedoch, was unter Bedingungen mit Gegnern passiert. Die Redundanz von Gossip ist auch seine Robustheit. Eine effizientere Routing-Topologie kann auf effizientere Weise gestört werden.
Die Behauptung von fünfzig Prozent braucht einen veröffentlichten Benchmark, bevor ich sie als Spezifikation behandle.
#dusk $DUSK @Dusk Was ist für Kaccasts 50%-Effizienzbehauptung am wichtigsten?
🎙️ Speichere als König, die Speicherplatinen-Sparte ist total durchgedreht. Man kann auch mit dem Algorithmus ein bisschen die Ameisen-Positionen abgrasen, um Gewinne mitzunehmen.
🎙️ Krypto-Quoten-Austausch; Fragen von Neueinsteigern beantworten✅ Aufbau der Community konsequent fördern🦅 Verbreitung der Idee von freier Meinungsäußerung! Für ein ökologisches Gleichgewicht sorgen!
Wasmer ist ein produktionstauglicher WebAssembly-Interpreter mit einer nachweisbaren Erfolgsbilanz außerhalb der Blockchain. Das ist wichtig. Die meisten ZK-fokussierten Chains bauen Ausführungsumgebungen auf experimenteller Infrastruktur auf und verbringen dann Jahre damit, die Stabilitätsprobleme zu beheben, die die experimentelle Infrastruktur verursacht.
Dusk hat sich dafür entschieden, Wasmer als Piecrust-Ausführungsengine zu verwenden – eine Entscheidung, die ich als bewusst konservativ in die richtige Richtung lese. Du erfindest keinen neuen Runtime, wenn es bereits einen erprobten gibt, der angepasst werden kann.
Die Frage der Anpassung ist das, was ich sorgfältig untersucht habe. Wasmer behandelt die allgemeine WASM-Ausführung sauber. Die Generierung von Zero-Knowledge-Proofs innerhalb einer WASM-Umgebung führt zu Einschränkungen, für die allgemeine Runtimes nicht ausgelegt waren.
Wie Piecrust die Grenze zwischen WASM-Ausführung und ZK-Programmerstellung (Circuit Generation) handhabt, ist die technische Nahtstelle, die es zu verstehen gilt, bevor man davon ausgeht, dass die Integration reibungslos funktioniert.