Ich finde immer, dass Protokolle erst dann wirklich Sinn ergeben, wenn man sie tatsächlich nutzt. Deshalb habe ich mir etwas Zeit genommen, das Public Testnet von Babylon zu erkunden. Die Headline lautet „native & trustless Bitcoin borrowing“, aber wenn man den Ablauf selbst sieht, erklärt sich diese Idee viel besser als jede Ankündigung es je könnte.
Was mich besonders angesprochen hat, war nicht, dass das Ausleihen jetzt möglich ist. Es war, wie wenig die Erfahrung von dir verlangt, darüber nachzudenken, dein Bitcoin zu verändern, bevor du ihn als Sicherheit verwendest. Der Prozess wirkt so gestaltet, dass BTC „native“ bleibt, während du gleichzeitig durch die Aave-v4-Integration das Borrowing erkunden kannst—ein anderer Ausgangspunkt als das, woran sich viele Bitcoin-Inhaber inzwischen gewöhnt haben.
Es ist immer noch ein Public Testnet, und genau deshalb denke ich, dass es sich lohnt, es auszuprobieren. Produkte zeigen normalerweise ihre Stärken—und die Fragen, die sie noch beantworten müssen—erst dann, wenn echte Menschen anfangen, mit ihnen zu interagieren und Feedback zu teilen.
Was ist dir nach dem Ausprobieren des Public Testnets mehr aufgefallen: die Borrowing-Erfahrung selbst oder die Idee, natives BTC zu nutzen, ohne zu verändern, was es in erster Linie ist??
Die Partnerliste von Babylon wächst weiter—Ledger, GoMining, Aegis, Aave v4, Keystone und mehr.
Doch ich interessiere mich nicht mehr dafür, Logos zu zählen.
Was ich sehen möchte, ist **echte Akzeptanz**. Wie viel BTC wurde tatsächlich eingezahlt? Wie viele Nutzer sind aktiv? Wie viel Kreditaufnahme findet statt? Wie viel Liquidität bleibt im Ökosystem?
GoMining sagt, es könnte **bis zu 1.000 BTC** einbringen. Aegis plant die Einführung von Festzins-Kreditvergabe im Q4. Keystone sagt, die Partnerschaft expandiert. Das sind vielversprechende Ankündigungen, aber wo sind die Ergebnisse?
Babylon hat über **$10B an aktiviertem nativen BTC** gemeldet, während die DeFi-Aktivität auf Babylon Genesis deutlich kleiner bleibt. Das sind zwar unterschiedliche Kennzahlen, aber sie werfen eine wichtige Frage auf: **Übersetzt sich Sicherheit in echte Nutzung des Ökosystems?**
Ich würde es begrüßen, wenn Babylon eine Partnerschafts-Dashboard veröffentlicht, das Folgendes zeigt:
Ich fand mich dabei, @BabylonCapital Trustless Bitcoin Vaults mit einer falschen Erwartung zu vermessen. Ich fragte weiter, wie schnell der Prozess abläuft, obwohl die spannendere Frage vielleicht gewesen wäre, warum er gar nicht versucht, schneller zu werden.
Beim Lesen der Dokumentation wirkt es so, als würde das Protokoll bewusst das Warten akzeptieren, wo eine Verifizierung wichtig ist. Das ist eine andere Denkweise als dem reibungslosesten möglichen Erlebnis hinterherzujagen. Die Verzögerung wird nicht als etwas dargestellt, das man den Nutzern vorenthalten will. Sie ist Teil davon, die Vertrauensannahmen rund um die Übertragung von Wert zu verringern.
Ich respektiere diese Entscheidung tatsächlich, weil „schneller“ nicht automatisch „sicherer“ bedeutet. Trotzdem heißt das auch: Menschen, die an sofortige Interaktionen gewöhnt sind, könnten zuerst Reibung spüren, bevor sie den Grund dafür verstehen.
Manchmal sagt dir ein Protokoll, was ihm wichtig ist, daran, wozu es sich nicht optimieren lässt.
Ist es die richtige Abwägung, langsamere Abwicklung zu akzeptieren, um stärkere Sicherheitsgarantien zu erhalten, oder werden Nutzererwartungen das Design irgendwann doch in Richtung mehr Bequemlichkeit drängen? 🤔
Eine Designentscheidung in Babylons Trustless-Bitcoin-Tresoren hat mich mehr überrascht, als ich erwartet hatte. Ein Tresor wird nicht als universelles Sicherheitenmittel erstellt, das sich sofort zwischen verschiedenen Anwendungen verschieben lässt. Er ist an die Anwendung gebunden, für die er erstellt wurde, und ich fragte mich die ganze Zeit, warum man diese Einschränkung akzeptiert.
Je länger ich darüber nachdachte, desto mehr sah es nach einer Isolationsstrategie aus. Wenn jeder Tresor standardmäßig überall funktionieren müsste, würden die Verbindungen zwischen den Protokollen zwangsläufig komplizierter werden. Jeden Tresor auf eine bestimmte Integration zu beschränken, fühlt sich an, als würde man eine Grenze ziehen, bevor sich Komplexität ausbreiten kann.
Ich mag, dass dadurch klarere Annahmen erzwungen werden, wofür die Sicherheiten tatsächlich verwendet werden. Aber es wirft auch eine praktische Frage auf, weil Nutzer oft erwarten, dass sich Vermögenswerte frei bewegen können, sobald sie eingezahlt wurden.
Manchmal ist Flexibilität nicht das stärkste Feature. Manchmal sind vorhersehbare Grenzen es.
Schafft es unnötige Reibung, einen Tresor auf eine einzige Anwendung zu beschränken, oder ist die Reduzierung des vernetzten Risikos den Verlust dieser Portabilität wert?
Ich dachte immer wieder, dass die Erstellung eines Bitcoin-Tresors das BTC sofort bereit machen sollte, um dagegen zu borgen. Die Dokumentation hat mich jedoch immer wieder vom Gegenteil überzeugt.
Meine These ist ganz einfach: Verwahrung und Sicherheit sollten nicht denselben Zustand bilden.
@BabylonLabs_io trennt das Erstellen eines trustlosen Bitcoin-Tresors davon, ihn als Sicherheit zu aktivieren. Zuerst kam es mir wie ein zusätzlicher Schritt vor. Dann habe ich verstanden, dass das Protokoll zwei unterschiedliche Fragen stellt. Zuerst: Ist die $BTC sicher nach den Regeln des Tresors gesperrt? Erst danach kann sie für das Borgen in Frage kommen. Diese überraschend strikte Grenze macht die Berechtigung zum Borgen aber auch einfacher nachvollziehbar.
Es ist weniger bequem, sicher. Aber das Mischen von Vermögensschutz mit der Genehmigung für Kredite würde verwischen, wo die eine Verantwortung endet und die nächste beginnt.
Wird klares Bitcoin-Borrowing eher dadurch erreicht, dass Schritte reduziert werden, oder dadurch, dass jeder kritische Zustand getrennt wird, bevor Gelder nutzbar werden?? 🤔
Der Teil, den ich unterschätzt habe, war nicht, dass Bitcoin nicht gelockt wird. Es war, was das Protokoll danach nicht annehmen wollte.
Zuerst dachte ich, dass sobald $BTC in einen Trustless Bitcoin Vault eingetreten war, das Ausleihen im Grunde nur auf den nächsten Klick warten würde. Die Doku erzählt eine andere Geschichte.
Das Sperren von BTC beweist, dass das Protokoll den Vermögenswert gemäß seinen Verwahrungsregeln unter seiner Obhut gesichert hat. Es beweist jedoch nicht automatisch, dass die Kredit-Seite diesem Bitcoin als Sicherheit vertrauen sollte. Das sind zwei getrennte Entscheidungen, und Babylon hält sie absichtlich so auseinander.
Je mehr ich dem Ablauf folgte, desto mehr ergab diese Grenze Sinn. Verwahrung beantwortet die Frage, ob das Bitcoin geschützt ist. Sicherheit beantwortet die Frage, ob das Kreditprotokoll bereit ist, finanzielle Risiken dagegen einzugehen. Das eine garantiert das andere nicht automatisch, auch wenn beide mit demselben BTC zu tun haben.
Das ist eine subtile Unterscheidung, aber sie verändert, wie ich den gesamten Ausleihprozess betrachte. Das Protokoll bremst die Dinge nicht um der Bremse willen. Es weigert sich, zwei Verantwortlichkeiten zu verwischen, die sehr unterschiedliche Konsequenzen haben.
Sollte ein Kreditsystem jemals gesperrtes Bitcoin als automatisch akzeptierte Sicherheit behandeln, oder macht gerade die Trennung dieser Entscheidungen das Design stärker??
Etwas hat mich beim Lesen des Trustless Bitcoin Vault-Workflows gestört. Ich ging davon aus, dass der wichtige Moment die Erstellung des Vaults ist.
Dem ist nicht so.
Das Erstellen eines Vaults beweist, dass dein BTC nach den Verwahrungsregeln des Protokolls unter seine Obhut gesperrt wurde. Das ist ein wichtiger Schritt, aber es macht diese Coins nicht automatisch innerhalb des Kredit-Systems nutzbar.
Das Protokoll muss den Vault erst als aktives Sicherheiten-Asset erkennen, bevor überhaupt etwas geschehen kann.
Diese Trennung wirkt bewusst gewählt.
Ein Zustand beantwortet: „Ist der Bitcoin sicher gesperrt?“ Der andere antwortet: „Kann sich das Lending-Protokoll darauf verlassen?“ Das klingt ähnlich, bis man merkt, dass hier völlig unterschiedliche Probleme gelöst werden.
Ich mag diese Grenze sogar. Sie verhindert, dass Verwahrung und Sicherheit so behandelt werden, als wären sie dasselbe.
Aber das bedeutet auch: Wenn du siehst, dass ein Vault erfolgreich erstellt wurde, heißt das noch nicht, dass der Borrowing-Flow bereits bereit ist zu beginnen. Die Sperre ist nur eine Seite des Übergangs. Das Protokoll muss den BTC noch in einen Zustand bringen, in dem er als Sicherheit teilnehmen kann.
Das ist eine kleine Unterscheidung, aber wahrscheinlich eine der leichtesten, die man übersieht, wenn man sich den Flow zum ersten Mal ansieht.
Wenn also Leute sagen, ihr BTC sei bereits „im Vault“, sprechen sie dann von gesperrtem Bitcoin… oder von Sicherheit, die das Protokoll tatsächlich bereits zu verwenden begonnen hat??
Ich bin immer wieder auf eine Frage zurückgekommen, nachdem ich mehr über Trustless Bitcoin Vaults (TBV) gelesen hatte. Warum haben wir akzeptiert, dass die Nutzung von Bitcoin meist bedeutet, einen Teil seines ursprünglichen Eigentumsmodells aufzugeben?
Das ist die Annahme, die TBV offenbar herausfordert. Der interessante Punkt ist nicht einfach, dass native $BTC als Sicherheit dienen kann. Sondern dass sich Eigentum und Nutzen nicht mehr wie Gegensätze anfühlen. Bitcoin kann weiterhin nativen Charakter haben und trotzdem einen Zweck erfüllen, der über das bloße Liegen in einer Wallet hinausgeht — und das verändert, wie ich über Sicherheiten insgesamt denke.
Die meisten Menschen bemessen Sicherheiten daran, was sie freischalten. In letzter Zeit frage ich mich jedoch, ob die bessere Frage nicht ist, was sie dich zuerst zu geben zwingt. Wenn die Nutzung eines Vermögenswerts bedeutet, dass man seine Form verändert oder die Kontrolle irgendwo anders abgibt, dann ist das bereits Teil der Kosten — selbst bevor überhaupt ein Kredit existiert.
Ich mag diese Richtung, weil sie das Gespräch stärker auf Bitcoin selbst fokussiert, statt eine weitere Version davon zu erschaffen. Trotzdem dürfte es schwieriger sein, Eigentum und Nutzen voneinander zu trennen, als es zunächst scheint — und genau darauf würde ich beim Fortschreiten des Designs am genauesten achten.
Vielleicht geht es bei der Zukunft der Sicherheit #bitcoin nicht darum, $BTC mehr in Bewegung zu bringen. Vielleicht geht es darum, dass Eigentum weniger in Anspruch genommen wird, während der Nutzen sich ausweitet.
Ich habe eine Weile damit verbracht, über trustlose Bitcoin-Vaults (TBV) zu lesen, und etwas hat mich dabei ständig gestört. Die meisten Gespräche über das Ausleihen beginnen mit Zinssätzen, aber ich denke, die wichtigere Frage kommt viel früher. Was muss mit deinem Bitcoin passieren, bevor überhaupt mit dem Ausleihen begonnen wird?
Genau da fühlt sich TBV anders an. Die Idee ist nicht einfach, dass natives $BTC ein Darlehen absichern kann. Es geht vielmehr darum, dass das Sicherungsvermögen nicht erst durch Wrapping oder einen anderen vertrauenswürdigen Schritt zu etwas anderem werden muss. Bitcoin bleibt nativ, ist aber dennoch als Sicherheit verwendbar, und das verändert still und leise, was ich gerade bewerte. Ich höre auf zu fragen „Worauf kann ich mir Geld leihen?“ und fange an zu fragen „Welche Annahmen musste ich akzeptieren, bevor das Ausleihen überhaupt beginnt?“
Ich mag diese Verschiebung, weil sie das Vertrauensmodell vor das Finanzprodukt stellt. Gleichzeitig bedeutet das aber auch: Die Qualität des Verifizierungsprozesses ist das, worauf man am meisten achten sollte. Dort wird wahrscheinlich letztlich das Vertrauen verdient oder verloren, nicht im Ausleih-Flow selbst.
Vielleicht messen wir das bitcoinbasierte Ausleihen schon die ganze Zeit vom falschen Ausgangspunkt aus. Ist die eigentliche Innovation besseres Ausleihen – oder dass man weniger Vertrauensannahmen braucht, bevor das Ausleihen überhaupt erst startet.