NewbieToNode

#termmax @TermMax

The 45-day example in TermMax's Morpho integration caught me off guard.

A borrower has 50,000 USDC against wstETH, locked into a TermMax position with a maturity date.

Fixed rate. Known term.

Straightforward enough.

Then I noticed the escape route.

Roll to Morpho lets that same borrower close the TermMax position before maturity and move the identical collateral into a Morpho floating-rate loan, atomically.

No lapse in coverage. No need to source repayment funds first.

Their own example spells out why: if a borrower expects floating rates to fall, they can leave the fixed position early and refinance through Morpho.

So the interesting part isn't the rate.

It's the commitment.

TermMax built a fixed-rate product, then built a deliberate low-friction way out of the fixed part.

Which means the maturity date isn't really a wall.

It's more like a default setting a borrower can override when their rate view changes.

Here's what I can't answer just from reading the mechanism:

When rates move hard enough to make Roll to Morpho attractive, does that exit protect TermMax's liquidity, or does it drain the fixed side exactly when the protocol needs commitment to hold?

That's the behavior I'd want to see once real volume, not a clean 50,000 USDC example, is pushing through it.

$TMX isn't live yet, so I'm less interested in what the token does today. I'm more interested in whether this architecture can hold up at scale before the token becomes part of the equation.

#dusk $DUSK @Dusk

Ich bin beim ersten Mal beim Generator-Reward mit 80% stehen geblieben, als ich die Aufteilung der Block-Belohnung von Dusk gelesen habe.

Dann ist mir aufgefallen, dass die 80% gar nicht pauschal sind.

Die Belohnung wird zu 80% an den Generator, zu 10% an das Abstimmungskomitee und zu 10% an Dusk aufgeteilt.

Nur 70% des Anteils des Generators sind fest. Die verbleibenden 10% hängen davon ab, wie viele Komitee-Abstimmungen in das Blockzertifikat einfließen – gewichtet nach den Voter-Credits. Berücksichtige alle Stimmen, und der Generator erhält die vollen 80%.

Das Gewinnen des Blocks und das Maximieren seiner Belohnung sind also zwei verschiedene Dinge.

Der Generator muss mehr tun, als nur den Block zu erzeugen; er muss auch die Arbeit des Komitees in das Zertifikat einarbeiten.

Das schafft einen einfachen, aber interessanten Anreiz: Ein Teil der wirtschaftlichen Kennzahlen des Generators hängt davon ab, wie vollständig dieses Zertifikat ist.

Was ich aus den Dokumenten nicht sagen kann, ist, wie stark das in der Praxis tatsächlich ins Gewicht fällt. Wenn Stimmen zu spät eintreffen: Wie oft wird diese variable 10% dann wirklich eingefangen?

#termmax @TermMax

2M $TMX.

Das ist die Zahl, zu der ich immer wieder zurückkam, nachdem ich mir die Booster-Kampagne von TermMax angesehen hatte...

1,7M gehen in die Verlosung. 300K gehen an Binance Square Creator.

Und der größte Belohnungs-Topf ist ziemlich unkompliziert. Die aufgelisteten Aufgaben für die Verlosung sind im Grunde folgen, reposten, Quiz, Discord und deine Wallet verbinden — keine Einzahlung oder tatsächliche Aktivitäten im Bereich Borrowing, Lending oder Options sind für diesen Weg erforderlich.

Moment mal...

Die gesamte Produktgeschichte von TermMax dreht sich um Borrowing, Lending und Options mit festen Zinssätzen — Kapital, bei dem du Rate und Laufzeit im Voraus kennst.

Aber die größte Belohnungs-Schiene erfordert nicht wirklich, dass Nutzer diese Produkte verwenden.

Der kleinere 300K-TMX-Topf ist die Binance-Square-Seite: Dort müssen Creators tatsächlich auf Inhaltsqualität und Ranking miteinander konkurrieren.

Also war ich vielleicht dabei, den Booster falsch zu betrachten.

Es sieht so aus, als wäre der 1,7M-TMX-Pool für unkomplizierte Reichweite und Wallet-Verbindungen gebaut... während der kleinere Square-Pool Creator-Sichtbarkeit und Ranking belohnt.

Das könnte tatsächlich für eine TGE-Kampagne Sinn ergeben.

Aber was passiert dann, nachdem das TMX gelandet ist?

Werden diese 1,7M-TMX-Teilnehmer zu TermMax-Nutzern... oder endet die Kampagne dort, wo auch die Belohnung endet?

#termmax @TermMax

Ich bin heute Morgen durch das neueste Update von TermMax gegangen ... habe mit den TGE-Details vom 25. August angefangen und bin irgendwie dazu gekommen, in den Zahlen zu graben.

$90M+ TVL. 1,5M+ registrierte Wallets. 90K+ tägliche aktive Nutzer. 10 EVM-Chains.

Okay... das ist schon eine ziemlich große Präsenz.

Aber dann habe ich bemerkt, wo diese gleiche Fixed-Rate-Idee jetzt tatsächlich auftaucht.

Kreditvergabe, Optionen, tokenisierte Aktien... und sogar institutionelle Finanzierung auf Canton.

Das hat mich kurz innehalten lassen.

Denn das ist nicht nur @TermMax jemanden der einen Kreditprodukt-Idee zu nehmen und sie auf mehr Chains zu bringen. Sie bringen dasselbe „bekannter Zinssatz, bekannte Laufzeit“-Konzept in sehr unterschiedliche Arten von Kapital.

Hmm... ich bin mir nicht sicher, ob das so einfach ist, wie es klingt.

Wenn das Kapital größer wird und die Menschen, die es nutzen, Cashflows planen müssen, wird Verlässlichkeit wahrscheinlich noch wertvoller.

Aber DeFi wurde auch seit Jahren auf Flexibilität gebaut.

Also: Wer gewinnt, wenn die beiden anfangen, in entgegengesetzte Richtungen zu ziehen?

$TMX geht am 25. August live.

Ich nehme an, darauf schaue ich jetzt.

#dusk $DUSK @Dusk

Früher dachte ich, dass sich der regulatorische Teil von On-Chain-Assets hauptsächlich auf das Asset selbst reduzieren lässt.

Kann es dieses Token geben? Kann es gehandelt werden?

Aber als ich mir angesehen habe, wie NPEX’s Lizenzen aufgeschlüsselt sind, kam mir der Gedanke, dass das wahrscheinlich zu simpel ist.

MTF, Broker, ECSP und DLT-TSS klingen nicht wirklich nach einem einzelnen Compliance-Label, das an ein Asset angeheftet ist.

Sie wirken eher wie unterschiedliche Berechtigungen für verschiedene Dinge, die man mit diesem Asset tun kann.

Das ist der Punkt, der meine Sicht darauf verändert hat.

Dasselbe Asset kann in Emission, Distribution oder sekundärem Handel vorkommen, aber das sind nicht dieselben regulierten Handlungen.

Von außen kann „reguliertes Finance auf Dusk“ daher wie eine einzige Fähigkeit klingen.

Je mehr ich darüber nachdenke, desto weniger fühlt es sich nach einem einzigen Thema an.

Es fühlt sich eher an wie eine Reihe getrennter Funktionen, die zufällig dasselbe Asset an unterschiedlichen Stellen berühren.

Vielleicht bleibt diese Trennung größtenteils auf der Ebene der Lizenzen.

Was mich jetzt interessiert, ist, ob sie sich auch in der tatsächlichen Produktarchitektur zeigt.

#dusk $DUSK @Dusk

Was, wenn das Token sagt, dass du das Eigentum an der Sicherheit hast, aber das Gesetz sagt, dass der echte Eintrag irgendwo anders geführt wird?

Ich bin auf diese Frage gestoßen, als ich Dusk’s neuesten Artikel zur Tokenisierung von KMU gelesen habe.

Der Artikel nennt ein konkretes niederländisches Beispiel: Die Übertragung von BV-Anteilen erfordert eine notariell beurkundete Urkunde.

Das wirft eine Frage auf, die ich so vorher nicht wirklich bedacht hatte. Wenn die Sicherheit zwar on-chain abgebildet ist, aber ein gesetzlich erforderlicher Prozess weiterhin außerhalb der Kette liegt, was genau repräsentiert dann das Token?

Ich hatte Tokenisierung von Eigentum bisher vor allem als Frage betrachtet, ob der Vermögenswert on-chain gestellt wird. Der schwierigere Teil könnte jedoch darin liegen, dass der digitale Eigentumsstatus mit dem übereinstimmt, was die jeweilige Rechtsordnung tatsächlich als Eintrag anerkennt.

Wenn diese beiden Zustände jemals voneinander abweichen können, hat die Tokenisierung die Abstimmung (Reconciliation) nicht vollständig abgeschafft. Sie hat stattdessen ein neues Koordinationsproblem zwischen der digitalen und der rechtlichen Seite geschaffen.

Wenn der On-Chain-Eigentumsstatus und der rechtsverbindliche Eintrag voneinander abweichen, welchen davon behandelt Dusk als Quelle der Wahrheit?

$HEMI
$ACE

#dusk $DUSK @Dusk

Ich dachte früher, „regulierte Assets auf der Kette“ sei im Grunde nur eine regulatorische Hürde.

Als ich mir die Partnerschaft von Dusk mit NPEX angesehen habe, wurde mir klar: Das ist weitaus komplexer.

Die eigenen Materialien von Dusk nennen vier Lizenzen: eine MTF-Lizenz für einen regulierten Sekundärmarkt, eine Broker-Lizenz zum Beschaffen von Assets wie MMFs und Anleihen, eine ECSP-Lizenz für Anlageinstrumente, die durch Privatanleger finanziert werden, und eine DLT-TSS-Lizenz, die an die native Emission und Tokenisierung regulierter Assets on-chain gekoppelt ist.

Das Spannende ist nicht nur, dass NPEX vier Lizenzen hat. Sondern dass sie auf unterschiedliche Dinge abbilden, die eine Institution mit einem Asset tatsächlich tun kann.

Der Handel mit einem bestehenden regulierten Asset und die Erstellung dieses Assets nativ auf der Kette sind zwei verschiedene Workflows – mit unterschiedlichen regulatorischen Anforderungen darunter.

Ich hatte das vorher nicht getrennt. „Reguliertes Finance auf Dusk“ klingt von außen nach einer einzigen Fähigkeit, aber die Infrastruktur dahinter ist viel granularer.

Der Teil, den ich jetzt beobachte, ist, ob diese regulatorische Trennung auch in der tatsächlichen Produktarchitektur sichtbar wird.

Erfordert die native Emission auf Dusk einen grundsätzlich anderen Workflow als das Hinzufügen eines bestehenden regulierten Assets zum Netzwerk?

@Dusk

Nach der Warnung kann ein Dusk-Provisioner 10% seines Anteils in Rewards verschieben, aber die Token werden nicht verbrannt.

Das war der Teil, den ich nicht erwartet hatte.

Das endgültig festgelegte Soft-Slashing-Mechanismus von Dusk eskaliert bei aufeinanderfolgenden Verstößen. N Verstöße bedeuten, dass N × 10% des Anteils in das Rewards-Guthaben desselben Knotens verschoben werden, während der Provisioner für N Epochen vom Konsens ausgeschlossen wird.

Die Strafe ist also nicht einfach „Ihre Token verschwinden“.

Der Anteil bleibt beim selben Provisioner. Was sich ändert, ist, wie viel davon für den Konsens aktiv bleibt.

Es gibt noch einen weiteren Aspekt, den ich sogar noch interessanter fand. Die Fehleranzahl wird nicht einfach zurückgesetzt, nur weil die Aussetzung endet. Dusk sagt, dass die Warnung und die Fehleranzahl zurückgesetzt werden, wenn der Provisioner tatsächlich eine Belohnung verdient, indem er einen Block erzeugt oder erfolgreich abstimmt.

Warten stellt also nicht wieder alles her. Erfolgreiche Teilnahme tut es.

Die Reduktion des aktiven Anteils kann sich außerdem weiterhin in Richtung des Netzwerk-Minimums von 1.000 DUSK bewegen.

Ich habe danach angefangen, Soft Slashing anders zu denken. Es geht weniger darum, jemandem die Token wegzunehmen, und mehr darum, das aktive Gewicht und die Berechtigung eines Provisioners schrittweise zu reduzieren, der weiterhin Fehler macht.

Macht das die Genesung von wiederholten Verstößen absichtlich schwieriger als einfach die Aussetzung abzuwarten?

@Dusk #dusk $DUSK

#dusk $DUSK

Ich dachte, eine schnelle DuskEVM-Transaktion sei im Grunde eine bereits abgewickelte (settled) Transaktion.

Dann fand ich in den Dusk-Dokumentationen eine Warnung, die diese Annahme ins Wanken brachte.

DuskEVM trennt die Aufnahme einer Transaktion von der Abwicklung.

Eine Transaktion kann schnell in einen L2-Block aufgenommen werden, aber das bedeutet nicht, dass der daraus resultierende Zustand bereits wieder in der Dusk-L1 abgerechnet ist. Die beiden Phasen sind über Batching, State Commitments und Fault Proofs miteinander verbunden.


Das Detail, das ich am interessantesten fand, ist, dass @Dusk explizit Anwendungen, die Werte zwischen DuskEVM und der Dusk L1 verschieben, darauf hinweist, NICHT allein aus der verstrichenen Zeit auf Finalität zu schließen.

Das klingt nach allem, was nach dem Lesen offensichtlich ist, aber es ist tatsächlich eine wichtige Design-Unterscheidung.

„Schnell bestätigt“ und „kann man als bereits abgewickelt betrachten“ sind nicht zwangsläufig dasselbe.

Wenn eine Anwendung, die echte Werte überträgt, einen Timer als Abkürzung nutzt, könnte das bedeuten, auf die Aufnahme zu reagieren, während der abteilungsübergreifende (Cross-Layer) Abwicklungsprozess zwischen den Schichten noch unvollständig ist.

Also bleibt mir eine Frage:

Welchen exakten Protokollstatus sollte eine Anwendung als maßgeblich (authoritativ) betrachten, bevor sie Werte über die Grenze DuskEVM ↔ Dusk L1 hinweg freigibt?

$BMT gerade einen brutalen Reset durchgemacht.

Von ca. $0,013 → $0,0436: BMT lieferte einen massiven Ausbruch.

Dann kam die andere Seite des Trades:

~50% Drawdown vom Hoch.

Jetzt beginnt der interessante Teil.

Im 1H-Chart ist $0,0208–$0,0220 die Schlüsselzone.

Wenn dieser Bereich hält und BMT zurückgewinnt:

→ $0,025
→ $0,027–0,028
→ $0,030

dann könnte die Korrektur dabei sein, eine Basis zu bilden, statt den Trend zu beenden.

Aber wenn $0,0208 unter hohem Volumen bricht, würde ich als Nächstes $0,018–$0,019 beobachten.

Auch das Volumen erzählt eine interessante Geschichte: Nach dem explosiven Ausbruch ist das Volumen deutlich abgekühlt.

Also frage ich nicht:

„Kann BMT auf $0,10 gehen?“

Die bessere Frage ist:

„Kann BMT ein höheres Tief aufbauen?“

Diese Antwort kommt zuerst.

#BMT #Bubblemaps

Diese Woche könnte für Krypto eine SEHR wichtige sein. 👀

Nicht wegen eines einzelnen Ereignisses.

Sondern weil Inflation + Öl + Geopolitik gleichzeitig auf den Markt treffen.

🇺🇸 Dienstag: Bestehende Hausverkäufe

🔥 Mittwoch: US-CPI + IEA-Ölmarktbericht

⚠️ Donnerstag: US-PPI

🇺🇸 Freitag: Michigan Consumer Sentiment

Der spannende Teil?

CPI → PPI kommen direkt hintereinander.

Wenn die Inflation heißer ausfällt als erwartet, können die Erwartungen an Zinssenkungen wieder durcheinandergebracht werden.

Und da die US–Iran-Situation weiterhin Öl beeinflusst und die Straße von Hormus, hat der Markt noch eine Inflations-Variable, die man im Blick behalten muss.

Für Krypto ist das entscheidend.

Heiße Inflation + höheres Öl = potenziell schwierigere Liquiditätsbedingungen.

Kühlerer Inflationsdruck nachlassend = eine deutlich freundlichere Ausgangslage für Risk Assets.

Darum beobachte ich über allem anderen nur eines:

Was passiert mit den Inflationserwartungen nach dem CPI von Mittwoch?

Denn diese Woche könnte uns viel darüber sagen, was der nächste große Schritt in $BTC 👀

Was ist deine Einschätzung?

Heiße CPI oder kühle CPI?

🚀 $HEI JUST WENT PARABOLIC 🚀

0.1362 → 0.4906 in Stunden. Zertifiziertes Top-Gewinner-Energie.

📍 Jetzt: $0.4327

🟢 Support: $0.3524 (letzte Konsolidierungsbasis)
🔴 Widerstand: $0.4906 (lokales Allzeithoch, gerade getippt)
🎯 Ziel, falls es ausbricht: $0.55–$0.60

Das ist die Art von Move, die ein Portfolio macht oder bricht. Ich beobachte die $0.3524-Zone wie ein Habicht—verliert sie das und dann kühlt sich das schnell ab.

Keine Finanzberatung, eigene Recherche. 👀

@BabylonLabs_io

Ein Satz in der Dokumentation zu den Trustless Bitcoin Vaults (TBV) hat meine Sicht auf Liquidationen über mehrere Tresore hinweg vollständig verändert.

Ich suchte nach der Antwort darauf, was passiert, wenn eine einzelne Kreditposition von mehreren Tresoren abgesichert ist.

Ich erwartete, dass die Liquidation proportional erfolgt. Wenn drei Tresore eine Kreditposition absichern, nahm ich an, dass jeder Tresor seinen Anteil an dem eingezogenen Sicherungsvermögen beiträgt.

Stattdessen beschreibt die Dokumentation etwas viel Spezifischeres.

Wenn mehrere Tresore eine einzelne Kreditposition absichern, beschlagnahmt TBV ein Präfix der geordneten Tresorliste und stoppt, sobald genug Sicherheiten entnommen wurden, um die Zielbeschlagnahme zu erfüllen.

Ich habe diesen Satz tatsächlich angehalten und noch einmal gelesen.

Der Mechanismus ist nicht „von jedem Tresor ein bisschen nehmen“.

Es ist „Tresore aus der vorderen Reihe einer geordneten Liste nehmen, bis das Ziel erreicht ist“.

Das ließ mich sofort darüber nachdenken, wie diese geordnete Liste selbst aufgebaut wird. Die Dokumentation erklärt die Beschlagnahmeregel, aber auf dieser Seite erklärt sie nicht, was die Reihenfolge bestimmt.

Liegt es daran, wann Tresore erstellt werden? Gibt es eine andere Protokollregel, die dabei eine Rolle spielt? Können Kreditnehmer sie beeinflussen, bevor sie eine Position eröffnen?

Der Liquidationsmechanismus ist dokumentiert. Der Aufbau der geordneten Liste ist der Teil, den ich noch immer zu verstehen versuche, weil er anscheinend grundlegend dafür ist, wie sich Positionen über mehrere Tresore hinweg in der Praxis verhalten.

@BabylonLabs_io

#baby $BABY

@BabylonLabs_io

Ich habe Babylons neueste „Trustless Bitcoin Vaults“ (TBV)-Dokumentation geöffnet und erwartet, mehr Zeit damit zu verbringen, BitVM3 zu verstehen. Stattdessen fand ich den Entsperrungs-/Ablöse-Flow, der fast sofort über BABE erklärt wurde.

Das brachte mich zum Research-Bereich, um zu verstehen, warum.

Der Paper identifiziert eine der größten praktischen Einschränkungen von BitVM3: ungefähr 42 GiB Off-Chain-Speicher pro „garbled circuit“ (vertauschtem Schaltkreis). BABE wird eingeführt, um diese Beschränkung zu adressieren – mit dem Anspruch, etwa eine 1000-fache Reduzierung der Speicheranforderungen zu erreichen, während dabei die geringen On-Chain-Verifikationskosten von BitVM3 erhalten bleiben.

Ich ging davon aus, dass der schwierigste Teil von TBV die Kryptografie selbst ist. Am Ende dachte ich, dass die größere Herausforderung darin liegen könnte, diese Kryptografie praktisch genug zu machen, um sie tatsächlich betreiben zu können.

Wenn diese Effizienzgewinne bis in die Produktion durchschlagen, könnte das weit über das Forschungs-Paper hinaus relevant sein. Geringere Speicheranforderungen könnten eine der operativen Kosten reduzieren, die hinter dem nativen Bitcoin-gestützten Borrowing (Kreditaufnahme) über TBV stehen – und das Protokoll damit praxistauglicher machen, um es in großem Maßstab laufen zu lassen.

Eine Formulierung stach für mich ebenfalls heraus: „preserving BitVM3's on-chain savings.“ Ich glaube nicht, dass das ausreicht, um zu dem Schluss zu kommen, BABE ersetze BitVM3 vollständig. Es liest sich eher wie eine Evolution in dieselbe Richtung. Klar ist aber, dass jemand, der sich heute über TBV informiert, zuerst mit BABE konfrontiert wird.

Das veränderte, wie ich die Dokumentation las. Anstatt zu fragen, ob Bitcoin diese Beweise verifizieren kann, interessiere ich mich nun stärker dafür, was die Babylons-Ingenieure als die nächste praktische Engstelle ansehen, sobald der Speicheraufwand durch diese starke Reduktion dramatisch gesenkt ist.

@BabylonLabs_io #baby $BABY

@BabylonLabs_io

Ich hatte erwartet, dass das Vertrauensmodell in Trustless Bitcoin Vaults (TBV) einfach ist.

Beim Lesen der Dokumentation von Babylon bin ich zu dem Abschnitt gekommen, in dem aufgelistet wird, worauf sich ein Einleger verlässt. Dort werden das Bitcoin-Netzwerk, das gemeinsam signierte Bitcoin-Skript genannt, das bei der Erstellung des Tresors erzeugt wurde, das Ethereum-Netzwerk und die Zielanwendung. Ich dachte wirklich, das sei das komplette Bild.

Dann brachte mich ein einziger Satz direkt darunter dazu, die Seite anzuhalten und erneut zu lesen.

Die Doku ergänzt, dass neben den eigentlichen Ketten das verbleibende Vertrauen noch immer bei der Governance des Protokolls und den Multi-Sigs für Notfallmaßnahmen liegt. Sie beschreibt diese als Übergangssicherheitsnetze, die das Protokoll im Laufe der Zeit außer Dienst stellen kann.

Auf derselben Seite erklärt Babylon außerdem, dass ein Einleger keine Föderation von Signierern braucht, um zusammenzuarbeiten, wenn er BTC über den vorgesehenen Rückzahlungsweg des Protokolls einlöst.

Wenn ich diese beiden Aussagen zusammen lese, hat sich verändert, wie ich das Wort trustless verstehe.

Ich lese es nicht als „jede Vertrauensannahme ist bereits verschwunden“. Ich lese es als ein Protokoll, das die Vertrauensannahmen, die heute noch bestehen, klar dokumentiert und gleichzeitig das System so entwirft, dass diese Annahmen im Laufe der Zeit kleiner werden können.

Ich schätze diesen Ansatz tatsächlich mehr, als so zu tun, als sei die Reise bereits abgeschlossen. Zu wissen, wo das verbleibende Vertrauen sitzt, ist genauso wichtig wie zu wissen, wo es bereits entfernt wurde.

Der Teil, der mich jetzt am meisten interessiert, ist, welches für Babylon das Meilenstein-Kriterium ist, um diese Übergangssicherheitsnetze zurückzuziehen. Wird das durch Governance gesteuert, durch technische Reife, durch Security-Audits oder durch eine Kombination aus allem drei?

@BabylonLabs_io #baby $BABY

$93 versus mehr als $15.000.

Dieser Vergleich ließ mich innehalten, als ich beim Lesen von Abschnitt 3 der Trustless Bitcoin Vaults (TBV) Whitepaper von @BabylonLabs_io

Ich versuchte, eine praktische Frage zu beantworten: Was kostet es tatsächlich, eine ungültige Behauptung anzufechten?

Die Arbeit vergleicht zwei Designs. Unter der aktuellen TBV-Architektur schätzt sie eine Bitcoin-Mainnet-Challenge-Transaktion auf etwa $93. Mit dem früheren BitVM2-Ansatz kostete die entsprechende Challenge mehr als $15.000. Das entspricht ungefähr einer 170×-Reduzierung.

Das Interessante ist nicht nur die Zahl. Es ist, was sich geändert hat, damit das möglich wurde.

Anstatt den ZK-Beweis direkt auf Bitcoin zu verifizieren, verwendet das aktuelle Design einen garbled-circuit- Challenge-Prozess, der ein Geheimnis nur dann offenbart, wenn eine ungültige Behauptung angefochten wird. Die Arbeit sagt, dass die Reduzierung der Menge an On-Chain-Arbeit das ermöglicht, was viel kleinere Sicherheitsbonds praktikabel macht.

Das hat geändert, wie ich das Design gelesen habe. Der Durchbruch war nicht einfach, Streitfälle vertrauensminimierter zu machen. Es war, sie so günstig zu machen, dass sie für natives Bitcoin-gestütztes Leihen praktisch werden.

Das Nächste, worauf ich achte, ist, ob diese geschätzten Kosten nahe an der Realität bleiben, während TBV über das Testen hinaus voranschreitet. Wenn die Bitcoin-Transaktionsgebühren in Phasen starker Netzwerküberlastung stark ansteigen, halten dann die ökonomischen Annahmen hinter dem Streitprozess noch stand?

#baby $BABY

Ich habe Abschnitt 9 geöffnet und erwartet, eine Liste unterstützter Chains zu finden.

Stattdessen habe ich eine Rollout-Sequenz gefunden.

@BabylonLabs_io beschreibt Trustless Bitcoin Vaults (TBV) als Ermöglichung, dass natives Bitcoin als Sicherheit über verschiedene Chains und Anwendungen hinweg genutzt werden kann. Die Whitepaper-Erklärung erläutert, wie diese Fähigkeit vorgesehen ist.

Natives Bitcoin-gestütztes Ausleihen beginnt mit Ethereum und EVM-Rollups. Solana wird als zukünftige Umsetzung beschrieben. Eine Erweiterung auf zusätzliche Ökosysteme, einschließlich Chains wie Solana und Sui, erfolgt erst, nachdem die zentralen Vault- und Liquidator-Services Stabilität demonstriert haben, wobei weitere Rollouts von der Babylon-Governance abhängig sind.

Der nächste Abschnitt beantwortete, warum.

Jede unterstützte Chain braucht ihre eigenen Deposit-Smart-Contracts, entwickelt für die Ausführungsumgebung und den Token-Standard dieser Chain. Die Architektur ist chain-agnostisch. Die Bereitstellung ist bewusst sequenziell.

Das veränderte, wie ich den Ausdruck „any chain“ lese.

Ich sehe ihn nicht mehr als Beschreibung dessen, was heute verfügbar ist. Ich sehe ihn als das Designziel, auf das das Protokoll hinarbeitet – erreicht jeweils ein Ökosystem nach dem anderen, statt alles auf einmal.

Ich beobachte nun, was Babylon irgendwann als echtes Multi-Chain-Meilensteinereignis betrachtet. Geht es dabei einfach darum, ein weiteres unterstütztes Netzwerk hinzuzufügen, oder um den Punkt zu erreichen, an dem die Integration einer neuen Chain zur Routine wird – statt zu einer maßgeschneiderten Engineering-Anstrengung?

#baby $BABY

@BabylonLabs_io

Zwanzig Minuten zur Erstellung. Dreiundvierzig Gigabyte zum Speichern, pro Gegenpartei.

Diese beiden Zahlen haben meine Denkweise über vertrauenslose Bitcoin-Tresore (TBV) verändert.

Das Whitepaper erklärt, dass Kreditnehmer ihre eigenen Betrugs-Erkennungsschaltungen erzeugen und speichern können, sodass sie unehrliches Verhalten unabhängig verifizieren können, ohne sich auf einen professionellen Betreiber verlassen zu müssen.

Von großen Kreditnehmern wird erwartet, dass sie diesen Mehraufwand selbst übernehmen. Für kleinere Kreditnehmer führt die Arbeit professionelle Betreiber ein, die diese Schaltungen stattdessen erzeugen und speichern.

Der Betreiber kann Ihre BTC jedoch immer noch nicht ausgeben. Jede Transaktion erfordert weiterhin Ihre Signatur. Aber wenn Sie diese Schaltungen nie selbst erzeugen und speichern, wird der Betreiber zur Partei, die die Infrastruktur bereitstellt und betreibt, die die unabhängige Betrugserkennung in Ihrem Namen ermöglicht.

Das Protokoll macht Selbstbetrieb möglich. Was ich weniger sicher einschätze, ist, wie viele Kreditnehmer sich dafür tatsächlich entscheiden werden, sobald die Betriebskosten greifbar werden.

Das ist eine der Fragen, die mich am meisten interessiert: Wie sich ein natives, durch Bitcoin abgesichertes Leihen über TBV entwickelt, während es auf dem öffentlichen Testnet ausgeübt wird.

#baby $BABY

Ich bin zwei Seiten zurückgegangen, weil ich dachte, ich hätte eine Abhängigkeit übersehen.

Ich hatte es nicht.

Der Self-Claim-Pfad wartete nicht darauf, dass der Vault Provider zurückkommt.

Er war bereits festgeschrieben, als der Vault erstellt wurde.

Das änderte für mich das Wiederherstellungsmodell.

Die meisten Diskussionen rund um Trustless Bitcoin Vaults (TBV) konzentrieren sich auf böswillige Akteure. Dieser Teil des Protokolls bereitet jedoch auf das Ausbleiben des Operators vor.

Mit der vorab festgeschriebenen Winternitz-Once-Time-Signatur (WOTS) kann der Einzahlende BTC zurückerlangen, selbst wenn der Vault Provider verschwindet oder nicht mehr kooperiert – gemäß dem TBV-Design.

Die Wiederherstellung wird nicht erst nach einem Fehlschlag hinzugefügt.

Sie wird festgeschrieben, bevor ein Fehlschlag überhaupt existiert.

Ich hatte nicht erwartet, dass „das Verschwinden des Operators“ als Protokollzustand und nicht als betriebliche Ausnahme behandelt wird.

Als Nächstes beobachte ich, ob dieser Wiederherstellungspfad sich im öffentlichen TBV-Testnetz genauso vorhersehbar verhält wie im Protokolldesign.

@BabylonLabs_io

Ich werde nur anders denken über $BABY , wenn diese Wiederherstellungsgarantien genauso zuverlässig bleiben, sobald TBV über frühe Rollouts hinausgeht und echte Operatoren beginnen zu verschwinden, sich zu rotieren oder unter normalen Betriebsbedingungen auszufallen.

#baby $BABY

@BabylonLabs_io

Ich dachte, Abschnitt 5.1 habe einen Fehler.

Es waren drei Handlungen als vertrauenslos markiert.

Die vierte nicht.

Kreditnehmer zieht Sicherheiten zurück → Vertrauenslos.

Liquidator liquidiert Sicherheiten → Vertrauenslos.

Großer Kreditgeber tritt aus dem Darlehensvertrag aus → Vertrauenslos.

Kreditnehmer hinterlegt Sicherheiten → Vertraut k-von-n Liquidatoren und j-von-m große Kreditgebern.

Ich ging zurück und erwartete, dass ich die Tabelle falsch gelesen hatte.

Hatte ich nicht.

Das Whitepaper erklärt den Mechanismus: Für die Erstellung des Tresors ist eine Schwelle an Liquidatoren erforderlich, die mitzeichnen, damit ein einzelner Liquidator keine neue Einzahlung zensieren kann.

Was mich weniger über die Ausnahme selbst überraschte.

Es war, dass die Tabelle nie fragt, ob Trustless Bitcoin Vaults (TBV) vertrauenslos sind.

Sie fragt, ob jede Handlung es ist.

Ich hatte „vertrauenslos“ als Eigenschaft des Tresors behandelt.

Babylon dokumentiert es als Eigenschaft der Operation.

Jetzt frage ich mich, ob die Erstellung des Tresors der einzige Ort ist, an dem TBV absichtlich eine Vertrauensannahme beibehält, oder ob derselbe Design-Umriss auch an anderer Stelle im Protokoll auftaucht.

Ich werde nur anders denken über $BABY , wenn diese Grenze konsistent bleibt, während TBV wächst.

#baby $BABY