MICHAEL MOORE
7.6k Beiträge
MICHAEL MOORE
Trade eröffnen
Regelmäßiger Trader
5.9 Monate
694 Following
15.9K+ Follower
5.0K+ Like gegeben
Beiträge
Portfolio
Alle
Zitierungen
Live
PINNED
Verifiziert
Okay, dieses hier hat mich tatsächlich mitten beim Scrollen aufgehalten. DuskEVMs Testnet ist laut der offiziellen Ankündigung am 10. August live gegangen. Solidity- und Hardhat-Unterstützung gibt es, Gas wird in DUSK bezahlt, und die Abwicklung wird zurück zu DuskDS geroutet.
Ich bin durch ältere Beiträge zurückgegangen, um zu sehen, wie es bei der Privatsphäre-Seite aussieht. Hedger, die Engine hinter Dusk’ Pitch für vertrauliche Smart Contracts, hat bereits am 6. November 2025 Alpha-Tests gestartet. Dieser Test lief auf Sepolia, einem separaten Ethereum-Testnetz, nicht auf Dusk’ eigener Kette.
Ich glaube nicht, dass diese Lücke an sich schon ein Problem ist. Die Ausführungsschicht und die Privatsphäre-Schicht auf getrennten Schienen zu bauen, ist ein normaler Weg, um komplexe Kryptografie zu testen, bevor man sie in eine Live-Umgebung zusammenführt.
Was mir aufgefallen ist, ist etwas anderes: Die Ankündigung vom 10. August handelt ausschließlich von allgemeinem EVM-Tooling. Sie erwähnt Hedger nicht, und ich konnte keine offizielle Quelle finden, die bestätigt, wann oder ob die beiden auf demselben Testnet zusammenkommen.
Hier ist meine eigene Einschätzung. Wenn DuskEVMs Testnet seit drei Tagen live ist und sich die öffentliche Roadmap der Privacy-Engine seit letztem November nicht bewegt hat, sind das ungefähr neun Monate, in denen die beiden großen Teile einer Privacy-Blockchain für finanzielle Anwendungen nicht auf denselben Schienen gezeigt wurden.
EVM-Kompatibilität allein hilft Entwicklern bereits. Solidity und Hardhat senken die Einstiegshürde für alle, die von Ethereum kommen, und das ist ein echter Fortschritt – unabhängig davon, was als Nächstes mit Hedger passiert.
Ich schaue wieder nach, sobald ein Update diese Lücke schließt.
@Dusk #dusk $DUSK
Ich bin durch ältere Beiträge zurückgegangen, um zu sehen, wie es bei der Privatsphäre-Seite aussieht. Hedger, die Engine hinter Dusk’ Pitch für vertrauliche Smart Contracts, hat bereits am 6. November 2025 Alpha-Tests gestartet. Dieser Test lief auf Sepolia, einem separaten Ethereum-Testnetz, nicht auf Dusk’ eigener Kette.
Ich glaube nicht, dass diese Lücke an sich schon ein Problem ist. Die Ausführungsschicht und die Privatsphäre-Schicht auf getrennten Schienen zu bauen, ist ein normaler Weg, um komplexe Kryptografie zu testen, bevor man sie in eine Live-Umgebung zusammenführt.
Was mir aufgefallen ist, ist etwas anderes: Die Ankündigung vom 10. August handelt ausschließlich von allgemeinem EVM-Tooling. Sie erwähnt Hedger nicht, und ich konnte keine offizielle Quelle finden, die bestätigt, wann oder ob die beiden auf demselben Testnet zusammenkommen.
Hier ist meine eigene Einschätzung. Wenn DuskEVMs Testnet seit drei Tagen live ist und sich die öffentliche Roadmap der Privacy-Engine seit letztem November nicht bewegt hat, sind das ungefähr neun Monate, in denen die beiden großen Teile einer Privacy-Blockchain für finanzielle Anwendungen nicht auf denselben Schienen gezeigt wurden.
EVM-Kompatibilität allein hilft Entwicklern bereits. Solidity und Hardhat senken die Einstiegshürde für alle, die von Ethereum kommen, und das ist ein echter Fortschritt – unabhängig davon, was als Nächstes mit Hedger passiert.
Ich schaue wieder nach, sobald ein Update diese Lücke schließt.
@Dusk #dusk $DUSK
Übersetzung ansehen
..........
MICHAEL MOORE
·
--
Okay, dieses hier hat mich tatsächlich mitten beim Scrollen aufgehalten. DuskEVMs Testnet ist laut der offiziellen Ankündigung am 10. August live gegangen. Solidity- und Hardhat-Unterstützung gibt es, Gas wird in DUSK bezahlt, und die Abwicklung wird zurück zu DuskDS geroutet.
Ich bin durch ältere Beiträge zurückgegangen, um zu sehen, wie es bei der Privatsphäre-Seite aussieht. Hedger, die Engine hinter Dusk’ Pitch für vertrauliche Smart Contracts, hat bereits am 6. November 2025 Alpha-Tests gestartet. Dieser Test lief auf Sepolia, einem separaten Ethereum-Testnetz, nicht auf Dusk’ eigener Kette.
Ich glaube nicht, dass diese Lücke an sich schon ein Problem ist. Die Ausführungsschicht und die Privatsphäre-Schicht auf getrennten Schienen zu bauen, ist ein normaler Weg, um komplexe Kryptografie zu testen, bevor man sie in eine Live-Umgebung zusammenführt.
Was mir aufgefallen ist, ist etwas anderes: Die Ankündigung vom 10. August handelt ausschließlich von allgemeinem EVM-Tooling. Sie erwähnt Hedger nicht, und ich konnte keine offizielle Quelle finden, die bestätigt, wann oder ob die beiden auf demselben Testnet zusammenkommen.
Hier ist meine eigene Einschätzung. Wenn DuskEVMs Testnet seit drei Tagen live ist und sich die öffentliche Roadmap der Privacy-Engine seit letztem November nicht bewegt hat, sind das ungefähr neun Monate, in denen die beiden großen Teile einer Privacy-Blockchain für finanzielle Anwendungen nicht auf denselben Schienen gezeigt wurden.
EVM-Kompatibilität allein hilft Entwicklern bereits. Solidity und Hardhat senken die Einstiegshürde für alle, die von Ethereum kommen, und das ist ein echter Fortschritt – unabhängig davon, was als Nächstes mit Hedger passiert.
Ich schaue wieder nach, sobald ein Update diese Lücke schließt.
@Dusk #dusk $DUSK
Ich bin durch ältere Beiträge zurückgegangen, um zu sehen, wie es bei der Privatsphäre-Seite aussieht. Hedger, die Engine hinter Dusk’ Pitch für vertrauliche Smart Contracts, hat bereits am 6. November 2025 Alpha-Tests gestartet. Dieser Test lief auf Sepolia, einem separaten Ethereum-Testnetz, nicht auf Dusk’ eigener Kette.
Ich glaube nicht, dass diese Lücke an sich schon ein Problem ist. Die Ausführungsschicht und die Privatsphäre-Schicht auf getrennten Schienen zu bauen, ist ein normaler Weg, um komplexe Kryptografie zu testen, bevor man sie in eine Live-Umgebung zusammenführt.
Was mir aufgefallen ist, ist etwas anderes: Die Ankündigung vom 10. August handelt ausschließlich von allgemeinem EVM-Tooling. Sie erwähnt Hedger nicht, und ich konnte keine offizielle Quelle finden, die bestätigt, wann oder ob die beiden auf demselben Testnet zusammenkommen.
Hier ist meine eigene Einschätzung. Wenn DuskEVMs Testnet seit drei Tagen live ist und sich die öffentliche Roadmap der Privacy-Engine seit letztem November nicht bewegt hat, sind das ungefähr neun Monate, in denen die beiden großen Teile einer Privacy-Blockchain für finanzielle Anwendungen nicht auf denselben Schienen gezeigt wurden.
EVM-Kompatibilität allein hilft Entwicklern bereits. Solidity und Hardhat senken die Einstiegshürde für alle, die von Ethereum kommen, und das ist ein echter Fortschritt – unabhängig davon, was als Nächstes mit Hedger passiert.
Ich schaue wieder nach, sobald ein Update diese Lücke schließt.
@Dusk #dusk $DUSK
Übersetzung ansehen
...........
MICHAEL MOORE
·
--
Ehrlich gesagt bin ich bei einer 93-Dollar-Zahl stehen geblieben, die in Babylons Whitepaper steckt.
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Übersetzung ansehen
$93 That Should Almost Never Be Paid.
MICHAEL MOORE
·
--
Ehrlich gesagt bin ich bei einer 93-Dollar-Zahl stehen geblieben, die in Babylons Whitepaper steckt.
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Verifiziert
Ehrlich gesagt bin ich bei einer 93-Dollar-Zahl stehen geblieben, die in Babylons Whitepaper steckt.
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Diese Zahl ist die On-Chain-Kostenposition des Challenge-Pfads in TBV – die Gebühr, die gezahlt wird, wenn jemand tatsächlich eine Behauptung zu gesperrtem Bitcoin anficht. Laut Whitepaper wurde diese Transaktion direkt auf dem Bitcoin-Mainnet getestet.
Was mich dann jedoch aufgehalten hat, ist das, was das Papier direkt danach über diese Zahl sagt. Es heißt, diese Gebühr werde in der Praxis fast nie gezahlt, weil ein ordnungsgemäß funktionierendes System überhaupt keine Challenges haben sollte.
Dieser Satz hat mich innehalten lassen. Die meisten Projekte listen ihre Kosten auf und machen dann weiter. Dieses hier nennt eine Gebühr und argumentiert im Stillen, dass die Kosten theoretisch bleiben sollten, wenn alles wie vorgesehen funktioniert.
Im normalen Betrieb bleibt der Beweis die ganze Zeit off-chain. Der 93-Dollar-Pfad wird nur aktiv, wenn eine Behauptung tatsächlich strittig gemacht wird – und laut demselben Dokument passiert das nur, wenn diese Behauptung von Anfang an nicht legitim war.
Das ist eine ganz bestimmte Art von Vertrauen, die man so schriftlich festhält. Die meisten technischen Dokumente beschreiben Worst-Case-Kosten, ohne zu sagen, dass der Worst Case per Design selten sein soll.
Im Whitepaper ist klar, wofür die Gebühr steht. Es sagt jedoch noch nichts darüber, wie oft die reale Welt den Anspruch getestet hat, der fast nie fällig werden sollte.
@BabylonLabs_io #baby $BABY
Der fehlende Schritt vor BitVM3.
Die Architektur hinter TBV.
Die Architektur hinter TBV.
MICHAEL MOORE
·
--
Ehrlich gesagt bin ich bei einem Beispiel in Babylons Whitepaper hängen geblieben, das zu sauber wirkte, um die echte Lösung zu sein.
Ein Kreditnehmer bindet BTC, um von einem Kreditgeber auf Ethereum zu leihen. Laut dem Whitepaper signieren beide Seiten im Voraus eine Reihe von Bitcoin-Transaktionen, die genau festlegen, wann jede Partei die Gelder beanspruchen kann.
Ich hatte erwartet, dass das Paper dort aufhört und sagt: Problem gelöst. Tut es nicht. Die nächste Zeile sagt, dass dieser Pre-Signing-Ansatz nur für ein ganz bestimmtes auslösendes Ereignis funktioniert und sich nicht auf beliebige DeFi-Bedingungen verallgemeinern lässt.
Genau dieses eine Detail hat mich erwischt. Ein Mechanismus, der Vertrauenlosigkeit beweisen soll, stellt in seinen eigenen Worten sofort klar, dass er nur eine bestimmte Art von Ereignis abdeckt und sich nicht auf beliebige Bedingungen ausdehnen lässt.
Deshalb existiert BitVM3 überhaupt im Design. Laut demselben Dokument verallgemeinert es diese Idee so, dass sie gegen jeden Off-Chain-Statusnachweis funktioniert – nicht nur gegen einen fest codierten Trigger – und dabei die Notwendigkeit entfernt, dass ein Gegenüber online bleiben muss.
Ich habe eine Weile über die Reihenfolge dieser Erklärung nachgedacht. Die meisten Versionen von TBV führen direkt zum fertigen Mechanismus. Das Whitepaper führt durch die einfache Version, zeigt, wo sie an ihre Grenzen stößt, und führt dann die eigentliche Lösung ein.
Die meisten Zusammenfassungen springen direkt zu BitVM3. Kaum jemand erwähnt, was zuerst noch zurückgelassen werden musste. Diese Reihenfolge fühlt sich für mich immer noch nach dem ehrlichsten Teil des Designs an.
@BabylonLabs_io #baby $BABY
Ein Kreditnehmer bindet BTC, um von einem Kreditgeber auf Ethereum zu leihen. Laut dem Whitepaper signieren beide Seiten im Voraus eine Reihe von Bitcoin-Transaktionen, die genau festlegen, wann jede Partei die Gelder beanspruchen kann.
Ich hatte erwartet, dass das Paper dort aufhört und sagt: Problem gelöst. Tut es nicht. Die nächste Zeile sagt, dass dieser Pre-Signing-Ansatz nur für ein ganz bestimmtes auslösendes Ereignis funktioniert und sich nicht auf beliebige DeFi-Bedingungen verallgemeinern lässt.
Genau dieses eine Detail hat mich erwischt. Ein Mechanismus, der Vertrauenlosigkeit beweisen soll, stellt in seinen eigenen Worten sofort klar, dass er nur eine bestimmte Art von Ereignis abdeckt und sich nicht auf beliebige Bedingungen ausdehnen lässt.
Deshalb existiert BitVM3 überhaupt im Design. Laut demselben Dokument verallgemeinert es diese Idee so, dass sie gegen jeden Off-Chain-Statusnachweis funktioniert – nicht nur gegen einen fest codierten Trigger – und dabei die Notwendigkeit entfernt, dass ein Gegenüber online bleiben muss.
Ich habe eine Weile über die Reihenfolge dieser Erklärung nachgedacht. Die meisten Versionen von TBV führen direkt zum fertigen Mechanismus. Das Whitepaper führt durch die einfache Version, zeigt, wo sie an ihre Grenzen stößt, und führt dann die eigentliche Lösung ein.
Die meisten Zusammenfassungen springen direkt zu BitVM3. Kaum jemand erwähnt, was zuerst noch zurückgelassen werden musste. Diese Reihenfolge fühlt sich für mich immer noch nach dem ehrlichsten Teil des Designs an.
@BabylonLabs_io #baby $BABY
Verifiziert
Ehrlich gesagt bin ich bei einem Beispiel in Babylons Whitepaper hängen geblieben, das zu sauber wirkte, um die echte Lösung zu sein.
Ein Kreditnehmer bindet BTC, um von einem Kreditgeber auf Ethereum zu leihen. Laut dem Whitepaper signieren beide Seiten im Voraus eine Reihe von Bitcoin-Transaktionen, die genau festlegen, wann jede Partei die Gelder beanspruchen kann.
Ich hatte erwartet, dass das Paper dort aufhört und sagt: Problem gelöst. Tut es nicht. Die nächste Zeile sagt, dass dieser Pre-Signing-Ansatz nur für ein ganz bestimmtes auslösendes Ereignis funktioniert und sich nicht auf beliebige DeFi-Bedingungen verallgemeinern lässt.
Genau dieses eine Detail hat mich erwischt. Ein Mechanismus, der Vertrauenlosigkeit beweisen soll, stellt in seinen eigenen Worten sofort klar, dass er nur eine bestimmte Art von Ereignis abdeckt und sich nicht auf beliebige Bedingungen ausdehnen lässt.
Deshalb existiert BitVM3 überhaupt im Design. Laut demselben Dokument verallgemeinert es diese Idee so, dass sie gegen jeden Off-Chain-Statusnachweis funktioniert – nicht nur gegen einen fest codierten Trigger – und dabei die Notwendigkeit entfernt, dass ein Gegenüber online bleiben muss.
Ich habe eine Weile über die Reihenfolge dieser Erklärung nachgedacht. Die meisten Versionen von TBV führen direkt zum fertigen Mechanismus. Das Whitepaper führt durch die einfache Version, zeigt, wo sie an ihre Grenzen stößt, und führt dann die eigentliche Lösung ein.
Die meisten Zusammenfassungen springen direkt zu BitVM3. Kaum jemand erwähnt, was zuerst noch zurückgelassen werden musste. Diese Reihenfolge fühlt sich für mich immer noch nach dem ehrlichsten Teil des Designs an.
@BabylonLabs_io #baby $BABY
Ein Kreditnehmer bindet BTC, um von einem Kreditgeber auf Ethereum zu leihen. Laut dem Whitepaper signieren beide Seiten im Voraus eine Reihe von Bitcoin-Transaktionen, die genau festlegen, wann jede Partei die Gelder beanspruchen kann.
Ich hatte erwartet, dass das Paper dort aufhört und sagt: Problem gelöst. Tut es nicht. Die nächste Zeile sagt, dass dieser Pre-Signing-Ansatz nur für ein ganz bestimmtes auslösendes Ereignis funktioniert und sich nicht auf beliebige DeFi-Bedingungen verallgemeinern lässt.
Genau dieses eine Detail hat mich erwischt. Ein Mechanismus, der Vertrauenlosigkeit beweisen soll, stellt in seinen eigenen Worten sofort klar, dass er nur eine bestimmte Art von Ereignis abdeckt und sich nicht auf beliebige Bedingungen ausdehnen lässt.
Deshalb existiert BitVM3 überhaupt im Design. Laut demselben Dokument verallgemeinert es diese Idee so, dass sie gegen jeden Off-Chain-Statusnachweis funktioniert – nicht nur gegen einen fest codierten Trigger – und dabei die Notwendigkeit entfernt, dass ein Gegenüber online bleiben muss.
Ich habe eine Weile über die Reihenfolge dieser Erklärung nachgedacht. Die meisten Versionen von TBV führen direkt zum fertigen Mechanismus. Das Whitepaper führt durch die einfache Version, zeigt, wo sie an ihre Grenzen stößt, und führt dann die eigentliche Lösung ein.
Die meisten Zusammenfassungen springen direkt zu BitVM3. Kaum jemand erwähnt, was zuerst noch zurückgelassen werden musste. Diese Reihenfolge fühlt sich für mich immer noch nach dem ehrlichsten Teil des Designs an.
@BabylonLabs_io #baby $BABY
Übersetzung ansehen
vaultBTC Is Not What You Think.
MICHAEL MOORE
·
--
Ehrlich gesagt bin ich bei einem Namen hängen geblieben, der mich anfangs komplett in die Irre geführt hat.
vaultBTC. Ich ging davon aus, dass es wie jeder andere gewrappte Bitcoin-Token funktioniert, den ich bisher gesehen habe: etwas, das man sich holt, herumbewegt, auf einem Sekundärmarkt handelt. Laut Babylons offizieller Einreichung im Aave-Governance-Forum ist diese Annahme falsch.
Aave erkennt nur ERC-20-Token als Sicherheiten an. Nativer Bitcoin, der in einem Taproot-UTXO gesperrt ist, ist jedoch überhaupt kein ERC-20-Token. Deshalb brauchte Babylon eine Umgehungslösung. Ihre Antwort war eine Eins-zu-Eins-Repräsentation auf Ethereum namens vaultBTC, die rein deshalb geprägt wurde, damit das Lending-Protokoll bestätigen kann, dass ein bestimmtes Vault existiert.
So hat sich für mich das Verständnis für das gesamte Design verändert. Dieser Token kann sich nur zwischen drei fest definierten Punkten bewegen, die direkt in der Integration festgelegt sind—nichts darüber hinaus. Ich habe geprüft, wie sich das von typischen „Wrapped“-Assets unterscheidet, und die Lücke ist total: kein offener Markt, keine uneingeschränkte Bewegung, kein Handel auf irgendeinem Sekundärmarkt.
Ich habe eine Weile über diesen Unterschied nachgedacht. Ein normaler „Wrapped“-Token entfaltet seinen Nutzen dadurch, dass er sich ohne Einschränkungen zwischen Wallets und Plattformen bewegen kann. Babylon hat diesen Weg hier bewusst blockiert und sich für ein härteres Design entschieden, speziell damit der Token niemals zu einer handelbaren Ersatzlösung für das echte Asset werden kann.
Diese Begrenzung ist es, die die Self-Custody tatsächlich auf mechanischer Ebene erzwingt—nicht nur als Versprechen, das irgendwo schriftlich steht. Es wäre bei weitem einfacher gewesen, vaultBTC wie jedes andere Asset funktionieren zu lassen.
Ich habe immer noch niemanden gesehen, der gefragt hat, was mit der Komponierbarkeit passiert, sobald ein Token so eng gesperrt ist. Das fühlt sich wie die nächste wirklich relevante Frage an.
@BabylonLabs_io #baby $BABY
vaultBTC. Ich ging davon aus, dass es wie jeder andere gewrappte Bitcoin-Token funktioniert, den ich bisher gesehen habe: etwas, das man sich holt, herumbewegt, auf einem Sekundärmarkt handelt. Laut Babylons offizieller Einreichung im Aave-Governance-Forum ist diese Annahme falsch.
Aave erkennt nur ERC-20-Token als Sicherheiten an. Nativer Bitcoin, der in einem Taproot-UTXO gesperrt ist, ist jedoch überhaupt kein ERC-20-Token. Deshalb brauchte Babylon eine Umgehungslösung. Ihre Antwort war eine Eins-zu-Eins-Repräsentation auf Ethereum namens vaultBTC, die rein deshalb geprägt wurde, damit das Lending-Protokoll bestätigen kann, dass ein bestimmtes Vault existiert.
So hat sich für mich das Verständnis für das gesamte Design verändert. Dieser Token kann sich nur zwischen drei fest definierten Punkten bewegen, die direkt in der Integration festgelegt sind—nichts darüber hinaus. Ich habe geprüft, wie sich das von typischen „Wrapped“-Assets unterscheidet, und die Lücke ist total: kein offener Markt, keine uneingeschränkte Bewegung, kein Handel auf irgendeinem Sekundärmarkt.
Ich habe eine Weile über diesen Unterschied nachgedacht. Ein normaler „Wrapped“-Token entfaltet seinen Nutzen dadurch, dass er sich ohne Einschränkungen zwischen Wallets und Plattformen bewegen kann. Babylon hat diesen Weg hier bewusst blockiert und sich für ein härteres Design entschieden, speziell damit der Token niemals zu einer handelbaren Ersatzlösung für das echte Asset werden kann.
Diese Begrenzung ist es, die die Self-Custody tatsächlich auf mechanischer Ebene erzwingt—nicht nur als Versprechen, das irgendwo schriftlich steht. Es wäre bei weitem einfacher gewesen, vaultBTC wie jedes andere Asset funktionieren zu lassen.
Ich habe immer noch niemanden gesehen, der gefragt hat, was mit der Komponierbarkeit passiert, sobald ein Token so eng gesperrt ist. Das fühlt sich wie die nächste wirklich relevante Frage an.
@BabylonLabs_io #baby $BABY
Verifiziert
Ehrlich gesagt bin ich bei einem Namen hängen geblieben, der mich anfangs komplett in die Irre geführt hat.
vaultBTC. Ich ging davon aus, dass es wie jeder andere gewrappte Bitcoin-Token funktioniert, den ich bisher gesehen habe: etwas, das man sich holt, herumbewegt, auf einem Sekundärmarkt handelt. Laut Babylons offizieller Einreichung im Aave-Governance-Forum ist diese Annahme falsch.
Aave erkennt nur ERC-20-Token als Sicherheiten an. Nativer Bitcoin, der in einem Taproot-UTXO gesperrt ist, ist jedoch überhaupt kein ERC-20-Token. Deshalb brauchte Babylon eine Umgehungslösung. Ihre Antwort war eine Eins-zu-Eins-Repräsentation auf Ethereum namens vaultBTC, die rein deshalb geprägt wurde, damit das Lending-Protokoll bestätigen kann, dass ein bestimmtes Vault existiert.
So hat sich für mich das Verständnis für das gesamte Design verändert. Dieser Token kann sich nur zwischen drei fest definierten Punkten bewegen, die direkt in der Integration festgelegt sind—nichts darüber hinaus. Ich habe geprüft, wie sich das von typischen „Wrapped“-Assets unterscheidet, und die Lücke ist total: kein offener Markt, keine uneingeschränkte Bewegung, kein Handel auf irgendeinem Sekundärmarkt.
Ich habe eine Weile über diesen Unterschied nachgedacht. Ein normaler „Wrapped“-Token entfaltet seinen Nutzen dadurch, dass er sich ohne Einschränkungen zwischen Wallets und Plattformen bewegen kann. Babylon hat diesen Weg hier bewusst blockiert und sich für ein härteres Design entschieden, speziell damit der Token niemals zu einer handelbaren Ersatzlösung für das echte Asset werden kann.
Diese Begrenzung ist es, die die Self-Custody tatsächlich auf mechanischer Ebene erzwingt—nicht nur als Versprechen, das irgendwo schriftlich steht. Es wäre bei weitem einfacher gewesen, vaultBTC wie jedes andere Asset funktionieren zu lassen.
Ich habe immer noch niemanden gesehen, der gefragt hat, was mit der Komponierbarkeit passiert, sobald ein Token so eng gesperrt ist. Das fühlt sich wie die nächste wirklich relevante Frage an.
@BabylonLabs_io #baby $BABY
vaultBTC. Ich ging davon aus, dass es wie jeder andere gewrappte Bitcoin-Token funktioniert, den ich bisher gesehen habe: etwas, das man sich holt, herumbewegt, auf einem Sekundärmarkt handelt. Laut Babylons offizieller Einreichung im Aave-Governance-Forum ist diese Annahme falsch.
Aave erkennt nur ERC-20-Token als Sicherheiten an. Nativer Bitcoin, der in einem Taproot-UTXO gesperrt ist, ist jedoch überhaupt kein ERC-20-Token. Deshalb brauchte Babylon eine Umgehungslösung. Ihre Antwort war eine Eins-zu-Eins-Repräsentation auf Ethereum namens vaultBTC, die rein deshalb geprägt wurde, damit das Lending-Protokoll bestätigen kann, dass ein bestimmtes Vault existiert.
So hat sich für mich das Verständnis für das gesamte Design verändert. Dieser Token kann sich nur zwischen drei fest definierten Punkten bewegen, die direkt in der Integration festgelegt sind—nichts darüber hinaus. Ich habe geprüft, wie sich das von typischen „Wrapped“-Assets unterscheidet, und die Lücke ist total: kein offener Markt, keine uneingeschränkte Bewegung, kein Handel auf irgendeinem Sekundärmarkt.
Ich habe eine Weile über diesen Unterschied nachgedacht. Ein normaler „Wrapped“-Token entfaltet seinen Nutzen dadurch, dass er sich ohne Einschränkungen zwischen Wallets und Plattformen bewegen kann. Babylon hat diesen Weg hier bewusst blockiert und sich für ein härteres Design entschieden, speziell damit der Token niemals zu einer handelbaren Ersatzlösung für das echte Asset werden kann.
Diese Begrenzung ist es, die die Self-Custody tatsächlich auf mechanischer Ebene erzwingt—nicht nur als Versprechen, das irgendwo schriftlich steht. Es wäre bei weitem einfacher gewesen, vaultBTC wie jedes andere Asset funktionieren zu lassen.
Ich habe immer noch niemanden gesehen, der gefragt hat, was mit der Komponierbarkeit passiert, sobald ein Token so eng gesperrt ist. Das fühlt sich wie die nächste wirklich relevante Frage an.
@BabylonLabs_io #baby $BABY
MICHAEL MOORE
·
--
Ehrlich gesagt habe ich bei einer Zahl aufgehört, die sich noch immer fast unrealistisch anfühlt.
Neuntausend Satoshis.
Im Oktober 2025, zwei Monate nachdem das Whitepaper „Trustless Bitcoin Vaults“ veröffentlicht wurde, postete David Tse das erste reale Experiment von seinem eigenen Konto. Kein Testnetz. Keine Simulation. Eine echte Bitcoin-Transaktion und eine passende Ethereum-Transaktion, beide in öffentlichen Blockexplorern, sodass jeder sie überprüfen kann.
Neuntausend Satoshis, die in einem Vault gesperrt waren. Genau ein USDC-Kredit auf Morpho. Native Bitcoin, das nie die Bitcoin-Kette verließ, nie wrapped wurde, nie durch einen Custodian ging.
Ich habe beide Transaktionslinks selbst nachgesehen. Diese kleine Summe war das erste Mal, dass natives BTC als Kreditkollateral auf Ethereum nutzbar wurde – ohne die üblichen Trade-offs beim Vertrauen.
Was immer wieder zu mir zurückkommt, ist der Abstand zwischen diesem Moment und dem, wo TBV heute steht. Der gleiche Mechanismus läuft derzeit auf dem Aave V4 public testnet und sitzt außerdem hinter einer geplanten GoMining-Integration, die von bis zu eintausend BTC spricht.
Dieses erste Experiment war bewusst winzig. Die aktuelle Arbeit zielt ganz klar auf etwas deutlich Größeres. Ob die ursprünglichen Annahmen zum Vertrauen standhalten, wenn die Größe von einem Dollar auf ein bedeutendes Niveau steigt, ist der Teil, den ich in der Öffentlichkeit noch nicht vollständig unter Stressbedingungen gesehen habe.
@BabylonLabs_io #baby $BABY
Neuntausend Satoshis.
Im Oktober 2025, zwei Monate nachdem das Whitepaper „Trustless Bitcoin Vaults“ veröffentlicht wurde, postete David Tse das erste reale Experiment von seinem eigenen Konto. Kein Testnetz. Keine Simulation. Eine echte Bitcoin-Transaktion und eine passende Ethereum-Transaktion, beide in öffentlichen Blockexplorern, sodass jeder sie überprüfen kann.
Neuntausend Satoshis, die in einem Vault gesperrt waren. Genau ein USDC-Kredit auf Morpho. Native Bitcoin, das nie die Bitcoin-Kette verließ, nie wrapped wurde, nie durch einen Custodian ging.
Ich habe beide Transaktionslinks selbst nachgesehen. Diese kleine Summe war das erste Mal, dass natives BTC als Kreditkollateral auf Ethereum nutzbar wurde – ohne die üblichen Trade-offs beim Vertrauen.
Was immer wieder zu mir zurückkommt, ist der Abstand zwischen diesem Moment und dem, wo TBV heute steht. Der gleiche Mechanismus läuft derzeit auf dem Aave V4 public testnet und sitzt außerdem hinter einer geplanten GoMining-Integration, die von bis zu eintausend BTC spricht.
Dieses erste Experiment war bewusst winzig. Die aktuelle Arbeit zielt ganz klar auf etwas deutlich Größeres. Ob die ursprünglichen Annahmen zum Vertrauen standhalten, wenn die Größe von einem Dollar auf ein bedeutendes Niveau steigt, ist der Teil, den ich in der Öffentlichkeit noch nicht vollständig unter Stressbedingungen gesehen habe.
@BabylonLabs_io #baby $BABY
Verifiziert
Ehrlich gesagt habe ich bei einer Zahl aufgehört, die sich noch immer fast unrealistisch anfühlt.
Neuntausend Satoshis.
Im Oktober 2025, zwei Monate nachdem das Whitepaper „Trustless Bitcoin Vaults“ veröffentlicht wurde, postete David Tse das erste reale Experiment von seinem eigenen Konto. Kein Testnetz. Keine Simulation. Eine echte Bitcoin-Transaktion und eine passende Ethereum-Transaktion, beide in öffentlichen Blockexplorern, sodass jeder sie überprüfen kann.
Neuntausend Satoshis, die in einem Vault gesperrt waren. Genau ein USDC-Kredit auf Morpho. Native Bitcoin, das nie die Bitcoin-Kette verließ, nie wrapped wurde, nie durch einen Custodian ging.
Ich habe beide Transaktionslinks selbst nachgesehen. Diese kleine Summe war das erste Mal, dass natives BTC als Kreditkollateral auf Ethereum nutzbar wurde – ohne die üblichen Trade-offs beim Vertrauen.
Was immer wieder zu mir zurückkommt, ist der Abstand zwischen diesem Moment und dem, wo TBV heute steht. Der gleiche Mechanismus läuft derzeit auf dem Aave V4 public testnet und sitzt außerdem hinter einer geplanten GoMining-Integration, die von bis zu eintausend BTC spricht.
Dieses erste Experiment war bewusst winzig. Die aktuelle Arbeit zielt ganz klar auf etwas deutlich Größeres. Ob die ursprünglichen Annahmen zum Vertrauen standhalten, wenn die Größe von einem Dollar auf ein bedeutendes Niveau steigt, ist der Teil, den ich in der Öffentlichkeit noch nicht vollständig unter Stressbedingungen gesehen habe.
@BabylonLabs_io #baby $BABY
Neuntausend Satoshis.
Im Oktober 2025, zwei Monate nachdem das Whitepaper „Trustless Bitcoin Vaults“ veröffentlicht wurde, postete David Tse das erste reale Experiment von seinem eigenen Konto. Kein Testnetz. Keine Simulation. Eine echte Bitcoin-Transaktion und eine passende Ethereum-Transaktion, beide in öffentlichen Blockexplorern, sodass jeder sie überprüfen kann.
Neuntausend Satoshis, die in einem Vault gesperrt waren. Genau ein USDC-Kredit auf Morpho. Native Bitcoin, das nie die Bitcoin-Kette verließ, nie wrapped wurde, nie durch einen Custodian ging.
Ich habe beide Transaktionslinks selbst nachgesehen. Diese kleine Summe war das erste Mal, dass natives BTC als Kreditkollateral auf Ethereum nutzbar wurde – ohne die üblichen Trade-offs beim Vertrauen.
Was immer wieder zu mir zurückkommt, ist der Abstand zwischen diesem Moment und dem, wo TBV heute steht. Der gleiche Mechanismus läuft derzeit auf dem Aave V4 public testnet und sitzt außerdem hinter einer geplanten GoMining-Integration, die von bis zu eintausend BTC spricht.
Dieses erste Experiment war bewusst winzig. Die aktuelle Arbeit zielt ganz klar auf etwas deutlich Größeres. Ob die ursprünglichen Annahmen zum Vertrauen standhalten, wenn die Größe von einem Dollar auf ein bedeutendes Niveau steigt, ist der Teil, den ich in der Öffentlichkeit noch nicht vollständig unter Stressbedingungen gesehen habe.
@BabylonLabs_io #baby $BABY
EINE UHR IST FIXIERT.
DIE ANDERE LÄUFT NICHT MAL SCHON.
DIE ANDERE LÄUFT NICHT MAL SCHON.
MICHAEL MOORE
·
--
Ich habe mir die eigene Governance-Geschichte von Babylon angesehen, und ein Detail hat, wie ich fortan jedes Unlock-Datum lese, alles verändert.
Im September 2025 trug das Foundation-Forum von Babylon einen Vorschlag vor, die BABY-Inflation von 8 % auf 5,5 % zu senken und die Belohnungen zugunsten eines neuen BTC-BABY-Co-Staking-Designs aufzuteilen. Seitdem ist er angenommen. Was mich dabei besonders stutzig machte, war die Zeile, mit der das Team es öffentlich einordnete: Das wurde als das Erste von mehreren tokenomischen Anpassungen gerahmt, die ausdrücklich geplant seien, weil Trustless Bitcoin Vaults gerade in Vorbereitung waren.
Diese Einordnung hat mich danach suchen lassen, wie TBV selbst in $BABY zurückwirken soll. Laut Babylons Vault-First-Roadmap ist vorgesehen, dass die aus DeFi-Integrationen, Zinsgebühren und Liquidationsprämien generierten Einnahmen programmgesteuert BABY kaufen und verbrennen.
Das TBV-Whitepaper beschreibt das direkt: Der/Die Gewinner des Bieterverfahrens erhält BTC, und das aufgewendete BABY wird verbrannt – ohne dass ein diskretionärer Treasury-Schritt erforderlich wäre.
In der Zusammenfassung des Founders Call betonte das Team, dass Wertschöpfung an erster Stelle steht: Die Tokenomics seien so gestaltet, dass sie die tatsächliche Nutzung erfassen, statt sie künstlich herzustellen.
An genau dieser Formulierung bleibe ich hängen.
Laut Babylons eigenen Docs umfasst der kombinierte Pool aus Team, Advisor und Early Investor insgesamt 4,9 Milliarden BABY, die seit dem 10. Mai 2026 in gleichen monatlichen Tranchen freigegeben werden. Auf 36 Monate verteilt, ergibt das die nächste Tranche – fällig am 10. August 2026 – bei rund 136,11 Millionen $BABY , im Fahrplan bleibend, unabhängig von allem anderen.
Der Burn-Mechanismus hängt von echtem TBV-Transaktionsvolumen ab, das sich noch immer in der Testnet-Phase bildet. Das Unlock wartet nicht darauf, dass diese Zahl existiert.
Welcher Zeitmesser holt den anderen zuerst ein?
#baby @BabylonLabs_io #baby
Im September 2025 trug das Foundation-Forum von Babylon einen Vorschlag vor, die BABY-Inflation von 8 % auf 5,5 % zu senken und die Belohnungen zugunsten eines neuen BTC-BABY-Co-Staking-Designs aufzuteilen. Seitdem ist er angenommen. Was mich dabei besonders stutzig machte, war die Zeile, mit der das Team es öffentlich einordnete: Das wurde als das Erste von mehreren tokenomischen Anpassungen gerahmt, die ausdrücklich geplant seien, weil Trustless Bitcoin Vaults gerade in Vorbereitung waren.
Diese Einordnung hat mich danach suchen lassen, wie TBV selbst in $BABY zurückwirken soll. Laut Babylons Vault-First-Roadmap ist vorgesehen, dass die aus DeFi-Integrationen, Zinsgebühren und Liquidationsprämien generierten Einnahmen programmgesteuert BABY kaufen und verbrennen.
Das TBV-Whitepaper beschreibt das direkt: Der/Die Gewinner des Bieterverfahrens erhält BTC, und das aufgewendete BABY wird verbrannt – ohne dass ein diskretionärer Treasury-Schritt erforderlich wäre.
In der Zusammenfassung des Founders Call betonte das Team, dass Wertschöpfung an erster Stelle steht: Die Tokenomics seien so gestaltet, dass sie die tatsächliche Nutzung erfassen, statt sie künstlich herzustellen.
An genau dieser Formulierung bleibe ich hängen.
Laut Babylons eigenen Docs umfasst der kombinierte Pool aus Team, Advisor und Early Investor insgesamt 4,9 Milliarden BABY, die seit dem 10. Mai 2026 in gleichen monatlichen Tranchen freigegeben werden. Auf 36 Monate verteilt, ergibt das die nächste Tranche – fällig am 10. August 2026 – bei rund 136,11 Millionen $BABY , im Fahrplan bleibend, unabhängig von allem anderen.
Der Burn-Mechanismus hängt von echtem TBV-Transaktionsvolumen ab, das sich noch immer in der Testnet-Phase bildet. Das Unlock wartet nicht darauf, dass diese Zahl existiert.
Welcher Zeitmesser holt den anderen zuerst ein?
#baby @BabylonLabs_io #baby
Teilweise korrekt
Ich habe mir die eigene Governance-Geschichte von Babylon angesehen, und ein Detail hat, wie ich fortan jedes Unlock-Datum lese, alles verändert.
Im September 2025 trug das Foundation-Forum von Babylon einen Vorschlag vor, die BABY-Inflation von 8 % auf 5,5 % zu senken und die Belohnungen zugunsten eines neuen BTC-BABY-Co-Staking-Designs aufzuteilen. Seitdem ist er angenommen. Was mich dabei besonders stutzig machte, war die Zeile, mit der das Team es öffentlich einordnete: Das wurde als das Erste von mehreren tokenomischen Anpassungen gerahmt, die ausdrücklich geplant seien, weil Trustless Bitcoin Vaults gerade in Vorbereitung waren.
Diese Einordnung hat mich danach suchen lassen, wie TBV selbst in $BABY zurückwirken soll. Laut Babylons Vault-First-Roadmap ist vorgesehen, dass die aus DeFi-Integrationen, Zinsgebühren und Liquidationsprämien generierten Einnahmen programmgesteuert BABY kaufen und verbrennen.
Das TBV-Whitepaper beschreibt das direkt: Der/Die Gewinner des Bieterverfahrens erhält BTC, und das aufgewendete BABY wird verbrannt – ohne dass ein diskretionärer Treasury-Schritt erforderlich wäre.
In der Zusammenfassung des Founders Call betonte das Team, dass Wertschöpfung an erster Stelle steht: Die Tokenomics seien so gestaltet, dass sie die tatsächliche Nutzung erfassen, statt sie künstlich herzustellen.
An genau dieser Formulierung bleibe ich hängen.
Laut Babylons eigenen Docs umfasst der kombinierte Pool aus Team, Advisor und Early Investor insgesamt 4,9 Milliarden BABY, die seit dem 10. Mai 2026 in gleichen monatlichen Tranchen freigegeben werden. Auf 36 Monate verteilt, ergibt das die nächste Tranche – fällig am 10. August 2026 – bei rund 136,11 Millionen $BABY , im Fahrplan bleibend, unabhängig von allem anderen.
Der Burn-Mechanismus hängt von echtem TBV-Transaktionsvolumen ab, das sich noch immer in der Testnet-Phase bildet. Das Unlock wartet nicht darauf, dass diese Zahl existiert.
Welcher Zeitmesser holt den anderen zuerst ein?
#baby @BabylonLabs_io #baby
Im September 2025 trug das Foundation-Forum von Babylon einen Vorschlag vor, die BABY-Inflation von 8 % auf 5,5 % zu senken und die Belohnungen zugunsten eines neuen BTC-BABY-Co-Staking-Designs aufzuteilen. Seitdem ist er angenommen. Was mich dabei besonders stutzig machte, war die Zeile, mit der das Team es öffentlich einordnete: Das wurde als das Erste von mehreren tokenomischen Anpassungen gerahmt, die ausdrücklich geplant seien, weil Trustless Bitcoin Vaults gerade in Vorbereitung waren.
Diese Einordnung hat mich danach suchen lassen, wie TBV selbst in $BABY zurückwirken soll. Laut Babylons Vault-First-Roadmap ist vorgesehen, dass die aus DeFi-Integrationen, Zinsgebühren und Liquidationsprämien generierten Einnahmen programmgesteuert BABY kaufen und verbrennen.
Das TBV-Whitepaper beschreibt das direkt: Der/Die Gewinner des Bieterverfahrens erhält BTC, und das aufgewendete BABY wird verbrannt – ohne dass ein diskretionärer Treasury-Schritt erforderlich wäre.
In der Zusammenfassung des Founders Call betonte das Team, dass Wertschöpfung an erster Stelle steht: Die Tokenomics seien so gestaltet, dass sie die tatsächliche Nutzung erfassen, statt sie künstlich herzustellen.
An genau dieser Formulierung bleibe ich hängen.
Laut Babylons eigenen Docs umfasst der kombinierte Pool aus Team, Advisor und Early Investor insgesamt 4,9 Milliarden BABY, die seit dem 10. Mai 2026 in gleichen monatlichen Tranchen freigegeben werden. Auf 36 Monate verteilt, ergibt das die nächste Tranche – fällig am 10. August 2026 – bei rund 136,11 Millionen $BABY , im Fahrplan bleibend, unabhängig von allem anderen.
Der Burn-Mechanismus hängt von echtem TBV-Transaktionsvolumen ab, das sich noch immer in der Testnet-Phase bildet. Das Unlock wartet nicht darauf, dass diese Zahl existiert.
Welcher Zeitmesser holt den anderen zuerst ein?
#baby @BabylonLabs_io #baby
MICHAEL MOORE
·
--
KEIN TREUHÄNDER. KEIN KOMITEE. NUR DU.
Hey, ich suchte nach der externen Gruppe, die das Challenge-Fenster von TBV für unzulässige Ansprüche überwacht. Gibt es nicht.
Babylons offizieller Temp Check, der am 25. Mai 2026 im Aave-Governance-Forum eingereicht wurde, beschreibt, was passiert, wenn jemand versucht, einen TBV-Vault mit einem ungültigen Beweis einzulösen. Dieser Anspruch kann während eines festgelegten Zeitfensters angefochten werden. Was mir dabei aufgefallen ist, ist, wer diese Anfechtung überhaupt erheben darf.
Der Einleger selbst kann jederzeit als sein eigener Herausforderer auftreten. Nicht nur als Backup-Option. Kein Ausweichfall, wenn eine bestimmte Gruppe nicht auftaucht. Das ist die Standardeinstellung, von Anfang an in das Design eingebaut.
Die meisten Systeme, die Bitcoin mit DeFi verbinden, setzen für genau diesen Job auf eine delegierte Autorität: eine Föderation, ein Multisig oder eine Reihe von Signierern mit Ermessensbefugnissen. Laut demselben Dokument existiert hier nichts davon. Kein Treuhänder hält einen Schlüssel. Kein Komitee hat eine Stimme über den BTC.
Dieses Fehlen hängt direkt mit dem zusammen, was Self-Custody in diesem Kontext tatsächlich bedeutet. Deine eigenen Schlüssel zu halten ist die eine Hälfte davon. Persönlich deinen eigenen Anspruch zu verteidigen, ohne sich auf die Ehrlichkeit oder Verfügbarkeit von irgendjemand anderem verlassen zu müssen, ist die andere Hälfte, die die meisten Erklärungen vollständig auslassen.
Ich beobachte aber weiterhin die praktische Seite davon. Als dein eigener Herausforderer zu handeln bedeutet, dass jemand das Zeitfenster tatsächlich überwachen muss, während ein Anspruch verarbeitet wird. Ob dafür spezielle Software nötig ist oder ob es über etwas Einfacheres funktioniert, wurde öffentlich nicht näher ausgeführt.
Die eigentliche Konsequenz ist jedoch klar. Wer in TBV einzahlt und sein eigenes Vault niemals überprüft, entscheidet sich stillschweigend wieder für dieselbe Abhängigkeit, die dieses Design gerade zu entfernen gebaut wurde.
$BABY #baby @BabylonLabs_io
Hey, ich suchte nach der externen Gruppe, die das Challenge-Fenster von TBV für unzulässige Ansprüche überwacht. Gibt es nicht.
Babylons offizieller Temp Check, der am 25. Mai 2026 im Aave-Governance-Forum eingereicht wurde, beschreibt, was passiert, wenn jemand versucht, einen TBV-Vault mit einem ungültigen Beweis einzulösen. Dieser Anspruch kann während eines festgelegten Zeitfensters angefochten werden. Was mir dabei aufgefallen ist, ist, wer diese Anfechtung überhaupt erheben darf.
Der Einleger selbst kann jederzeit als sein eigener Herausforderer auftreten. Nicht nur als Backup-Option. Kein Ausweichfall, wenn eine bestimmte Gruppe nicht auftaucht. Das ist die Standardeinstellung, von Anfang an in das Design eingebaut.
Die meisten Systeme, die Bitcoin mit DeFi verbinden, setzen für genau diesen Job auf eine delegierte Autorität: eine Föderation, ein Multisig oder eine Reihe von Signierern mit Ermessensbefugnissen. Laut demselben Dokument existiert hier nichts davon. Kein Treuhänder hält einen Schlüssel. Kein Komitee hat eine Stimme über den BTC.
Dieses Fehlen hängt direkt mit dem zusammen, was Self-Custody in diesem Kontext tatsächlich bedeutet. Deine eigenen Schlüssel zu halten ist die eine Hälfte davon. Persönlich deinen eigenen Anspruch zu verteidigen, ohne sich auf die Ehrlichkeit oder Verfügbarkeit von irgendjemand anderem verlassen zu müssen, ist die andere Hälfte, die die meisten Erklärungen vollständig auslassen.
Ich beobachte aber weiterhin die praktische Seite davon. Als dein eigener Herausforderer zu handeln bedeutet, dass jemand das Zeitfenster tatsächlich überwachen muss, während ein Anspruch verarbeitet wird. Ob dafür spezielle Software nötig ist oder ob es über etwas Einfacheres funktioniert, wurde öffentlich nicht näher ausgeführt.
Die eigentliche Konsequenz ist jedoch klar. Wer in TBV einzahlt und sein eigenes Vault niemals überprüft, entscheidet sich stillschweigend wieder für dieselbe Abhängigkeit, die dieses Design gerade zu entfernen gebaut wurde.
$BABY #baby @BabylonLabs_io
Verifiziert
KEIN TREUHÄNDER. KEIN KOMITEE. NUR DU.
Hey, ich suchte nach der externen Gruppe, die das Challenge-Fenster von TBV für unzulässige Ansprüche überwacht. Gibt es nicht.
Babylons offizieller Temp Check, der am 25. Mai 2026 im Aave-Governance-Forum eingereicht wurde, beschreibt, was passiert, wenn jemand versucht, einen TBV-Vault mit einem ungültigen Beweis einzulösen. Dieser Anspruch kann während eines festgelegten Zeitfensters angefochten werden. Was mir dabei aufgefallen ist, ist, wer diese Anfechtung überhaupt erheben darf.
Der Einleger selbst kann jederzeit als sein eigener Herausforderer auftreten. Nicht nur als Backup-Option. Kein Ausweichfall, wenn eine bestimmte Gruppe nicht auftaucht. Das ist die Standardeinstellung, von Anfang an in das Design eingebaut.
Die meisten Systeme, die Bitcoin mit DeFi verbinden, setzen für genau diesen Job auf eine delegierte Autorität: eine Föderation, ein Multisig oder eine Reihe von Signierern mit Ermessensbefugnissen. Laut demselben Dokument existiert hier nichts davon. Kein Treuhänder hält einen Schlüssel. Kein Komitee hat eine Stimme über den BTC.
Dieses Fehlen hängt direkt mit dem zusammen, was Self-Custody in diesem Kontext tatsächlich bedeutet. Deine eigenen Schlüssel zu halten ist die eine Hälfte davon. Persönlich deinen eigenen Anspruch zu verteidigen, ohne sich auf die Ehrlichkeit oder Verfügbarkeit von irgendjemand anderem verlassen zu müssen, ist die andere Hälfte, die die meisten Erklärungen vollständig auslassen.
Ich beobachte aber weiterhin die praktische Seite davon. Als dein eigener Herausforderer zu handeln bedeutet, dass jemand das Zeitfenster tatsächlich überwachen muss, während ein Anspruch verarbeitet wird. Ob dafür spezielle Software nötig ist oder ob es über etwas Einfacheres funktioniert, wurde öffentlich nicht näher ausgeführt.
Die eigentliche Konsequenz ist jedoch klar. Wer in TBV einzahlt und sein eigenes Vault niemals überprüft, entscheidet sich stillschweigend wieder für dieselbe Abhängigkeit, die dieses Design gerade zu entfernen gebaut wurde.
$BABY #baby @BabylonLabs_io
Hey, ich suchte nach der externen Gruppe, die das Challenge-Fenster von TBV für unzulässige Ansprüche überwacht. Gibt es nicht.
Babylons offizieller Temp Check, der am 25. Mai 2026 im Aave-Governance-Forum eingereicht wurde, beschreibt, was passiert, wenn jemand versucht, einen TBV-Vault mit einem ungültigen Beweis einzulösen. Dieser Anspruch kann während eines festgelegten Zeitfensters angefochten werden. Was mir dabei aufgefallen ist, ist, wer diese Anfechtung überhaupt erheben darf.
Der Einleger selbst kann jederzeit als sein eigener Herausforderer auftreten. Nicht nur als Backup-Option. Kein Ausweichfall, wenn eine bestimmte Gruppe nicht auftaucht. Das ist die Standardeinstellung, von Anfang an in das Design eingebaut.
Die meisten Systeme, die Bitcoin mit DeFi verbinden, setzen für genau diesen Job auf eine delegierte Autorität: eine Föderation, ein Multisig oder eine Reihe von Signierern mit Ermessensbefugnissen. Laut demselben Dokument existiert hier nichts davon. Kein Treuhänder hält einen Schlüssel. Kein Komitee hat eine Stimme über den BTC.
Dieses Fehlen hängt direkt mit dem zusammen, was Self-Custody in diesem Kontext tatsächlich bedeutet. Deine eigenen Schlüssel zu halten ist die eine Hälfte davon. Persönlich deinen eigenen Anspruch zu verteidigen, ohne sich auf die Ehrlichkeit oder Verfügbarkeit von irgendjemand anderem verlassen zu müssen, ist die andere Hälfte, die die meisten Erklärungen vollständig auslassen.
Ich beobachte aber weiterhin die praktische Seite davon. Als dein eigener Herausforderer zu handeln bedeutet, dass jemand das Zeitfenster tatsächlich überwachen muss, während ein Anspruch verarbeitet wird. Ob dafür spezielle Software nötig ist oder ob es über etwas Einfacheres funktioniert, wurde öffentlich nicht näher ausgeführt.
Die eigentliche Konsequenz ist jedoch klar. Wer in TBV einzahlt und sein eigenes Vault niemals überprüft, entscheidet sich stillschweigend wieder für dieselbe Abhängigkeit, die dieses Design gerade zu entfernen gebaut wurde.
$BABY #baby @BabylonLabs_io
........... @BabylonLabs_io
MICHAEL MOORE
·
--
Hören Sie, ich habe etwas in Babylons Ledger-Ankündigung vom 10. März 2026 bemerkt, das in den meisten Berichten völlig übersehen wurde.
Jede Überschrift, die ich gesehen habe, konzentrierte sich auf die 8-Millionen-Geräteanzahl. Ich dachte die ganze Zeit darüber nach, was diese Geräte eigentlich tun, sobald ein Tresor eingerichtet ist.
Wenn jemand einen TBV erstellt, werden die Regeln dauerhaft festgeschrieben: Claimant-Adresse, Zielprotokoll, Freigabebedingungen. Ich kann all das nach der Erstellung nicht mehr zurückgehen und ändern. Das ist die Verpflichtung.
Ohne Ledger’s Clear Signing würde ich diese Parameter über einen Browser festlegen und darauf vertrauen, dass die Oberfläche mir anzeigt, worauf ich mich einlasse. Mit Clear Signing erscheint alles, was ich genehmige, vor meiner Unterschrift in Klartext auf meinem Hardware-Bildschirm. Die Verifizierung und das dauerhafte Festschreiben sind dabei dieselbe Handlung.
Das Versprechen zur Selbstverwahrung in TBV lautet, dass mein BTC meine Kontrolle niemals verlässt. Clear Signing erweitert diese Logik auf die Einrichtung selbst. Ich kann genau lesen, worauf ich mich festlege – auf einem Gerät, das ich in der Hand halte –, bevor es dauerhaft wird.
Babylons Blog vom 10. März nennt das Rollout H2 2026 für diese Integration. Dieses Zeitfenster ist jetzt geöffnet.
Was ich öffentlich nicht gefunden habe, ist, ob Clear Signing die vollständige Tresorerstellung abdeckt oder nur nach der Einrichtung durchgeführte Aktionen. Diese Detailtiefe zum Umfang wurde noch nicht adressiert.
$BABY @BabylonLabs_io #baby
Jede Überschrift, die ich gesehen habe, konzentrierte sich auf die 8-Millionen-Geräteanzahl. Ich dachte die ganze Zeit darüber nach, was diese Geräte eigentlich tun, sobald ein Tresor eingerichtet ist.
Wenn jemand einen TBV erstellt, werden die Regeln dauerhaft festgeschrieben: Claimant-Adresse, Zielprotokoll, Freigabebedingungen. Ich kann all das nach der Erstellung nicht mehr zurückgehen und ändern. Das ist die Verpflichtung.
Ohne Ledger’s Clear Signing würde ich diese Parameter über einen Browser festlegen und darauf vertrauen, dass die Oberfläche mir anzeigt, worauf ich mich einlasse. Mit Clear Signing erscheint alles, was ich genehmige, vor meiner Unterschrift in Klartext auf meinem Hardware-Bildschirm. Die Verifizierung und das dauerhafte Festschreiben sind dabei dieselbe Handlung.
Das Versprechen zur Selbstverwahrung in TBV lautet, dass mein BTC meine Kontrolle niemals verlässt. Clear Signing erweitert diese Logik auf die Einrichtung selbst. Ich kann genau lesen, worauf ich mich festlege – auf einem Gerät, das ich in der Hand halte –, bevor es dauerhaft wird.
Babylons Blog vom 10. März nennt das Rollout H2 2026 für diese Integration. Dieses Zeitfenster ist jetzt geöffnet.
Was ich öffentlich nicht gefunden habe, ist, ob Clear Signing die vollständige Tresorerstellung abdeckt oder nur nach der Einrichtung durchgeführte Aktionen. Diese Detailtiefe zum Umfang wurde noch nicht adressiert.
$BABY @BabylonLabs_io #baby
Verifiziert
Hören Sie, ich habe etwas in Babylons Ledger-Ankündigung vom 10. März 2026 bemerkt, das in den meisten Berichten völlig übersehen wurde.
Jede Überschrift, die ich gesehen habe, konzentrierte sich auf die 8-Millionen-Geräteanzahl. Ich dachte die ganze Zeit darüber nach, was diese Geräte eigentlich tun, sobald ein Tresor eingerichtet ist.
Wenn jemand einen TBV erstellt, werden die Regeln dauerhaft festgeschrieben: Claimant-Adresse, Zielprotokoll, Freigabebedingungen. Ich kann all das nach der Erstellung nicht mehr zurückgehen und ändern. Das ist die Verpflichtung.
Ohne Ledger’s Clear Signing würde ich diese Parameter über einen Browser festlegen und darauf vertrauen, dass die Oberfläche mir anzeigt, worauf ich mich einlasse. Mit Clear Signing erscheint alles, was ich genehmige, vor meiner Unterschrift in Klartext auf meinem Hardware-Bildschirm. Die Verifizierung und das dauerhafte Festschreiben sind dabei dieselbe Handlung.
Das Versprechen zur Selbstverwahrung in TBV lautet, dass mein BTC meine Kontrolle niemals verlässt. Clear Signing erweitert diese Logik auf die Einrichtung selbst. Ich kann genau lesen, worauf ich mich festlege – auf einem Gerät, das ich in der Hand halte –, bevor es dauerhaft wird.
Babylons Blog vom 10. März nennt das Rollout H2 2026 für diese Integration. Dieses Zeitfenster ist jetzt geöffnet.
Was ich öffentlich nicht gefunden habe, ist, ob Clear Signing die vollständige Tresorerstellung abdeckt oder nur nach der Einrichtung durchgeführte Aktionen. Diese Detailtiefe zum Umfang wurde noch nicht adressiert.
$BABY @BabylonLabs_io #baby
Jede Überschrift, die ich gesehen habe, konzentrierte sich auf die 8-Millionen-Geräteanzahl. Ich dachte die ganze Zeit darüber nach, was diese Geräte eigentlich tun, sobald ein Tresor eingerichtet ist.
Wenn jemand einen TBV erstellt, werden die Regeln dauerhaft festgeschrieben: Claimant-Adresse, Zielprotokoll, Freigabebedingungen. Ich kann all das nach der Erstellung nicht mehr zurückgehen und ändern. Das ist die Verpflichtung.
Ohne Ledger’s Clear Signing würde ich diese Parameter über einen Browser festlegen und darauf vertrauen, dass die Oberfläche mir anzeigt, worauf ich mich einlasse. Mit Clear Signing erscheint alles, was ich genehmige, vor meiner Unterschrift in Klartext auf meinem Hardware-Bildschirm. Die Verifizierung und das dauerhafte Festschreiben sind dabei dieselbe Handlung.
Das Versprechen zur Selbstverwahrung in TBV lautet, dass mein BTC meine Kontrolle niemals verlässt. Clear Signing erweitert diese Logik auf die Einrichtung selbst. Ich kann genau lesen, worauf ich mich festlege – auf einem Gerät, das ich in der Hand halte –, bevor es dauerhaft wird.
Babylons Blog vom 10. März nennt das Rollout H2 2026 für diese Integration. Dieses Zeitfenster ist jetzt geöffnet.
Was ich öffentlich nicht gefunden habe, ist, ob Clear Signing die vollständige Tresorerstellung abdeckt oder nur nach der Einrichtung durchgeführte Aktionen. Diese Detailtiefe zum Umfang wurde noch nicht adressiert.
$BABY @BabylonLabs_io #baby
...........
MICHAEL MOORE
·
--
Ich habe mir die tatsächliche Skriptstruktur @BabylonLabs_io uses angesehen, die Babylon auf Bitcoin verwendet, und eine bewusste Entscheidung darin taucht in keiner Ankündigung auf.
Diese Entscheidung bildet die Grundlage dafür, wie eine Staking-Transaktion aufgebaut wird. Babylon schaltet die standardmäßige Art, einen Taproot-Ausgang auszugeben, vollständig aus und ersetzt sie durch eine bestimmte mathematische Konstante, für die es keinen privaten Schlüssel gibt. Niemand besitzt sie. Nicht einmal das Team, das sie entwickelt hat.
Was das bedeutet: BTC, die in einer dieser Positionen gesperrt sind, können nur unter drei Bedingungen wieder freigegeben werden, die direkt ins Skript geschrieben sind. Es gibt keinen anderen Ausweg.
Die erste gibt die Mittel frei, nachdem die vereinbarte Sperrfrist endet, und erfordert nur die eigene Signatur des Stakers. Die zweite ermöglicht ein vorzeitiges Entbinden, aber nur mit demselben Schlüssel plus einer Schwelle eines Covenant-Komitees. Die dritte ist Slashing und verhält sich anders als beide.
Ich bin immer wieder bei dieser dritten Bedingung gelandet. Laut Babylons eigener Spezifikation muss ein Finality Provider zusammenarbeiten, um zu verhindern, dass sie eintritt, aber diese Zusammenarbeit ist nicht erforderlich, um sie auszulösen. Wenn sie doppelt signieren, erscheint ihr Schlüssel automatisch und die vorab signierte Transaktion führt sich von selbst aus.
Sie haben keine Möglichkeit, das zu stoppen.
Was mich überrascht hat, war, dass dafür nichts Neues erfunden werden musste. Babylon nutzt Taproot genau so, wie es die eigenen Entwickler von Bitcoin beabsichtigt haben.
Das, was ich immer noch beobachte, ist, wie sich die Covenant-Komitee-Ebene entwickelt. In ihrer eigenen Dokumentation wird erwähnt, dass man über die aktuelle Struktur hinausgehen möchte, sobald native Funktionalität direkt auf Bitcoin verfügbar ist.
#baby $BABY
Diese Entscheidung bildet die Grundlage dafür, wie eine Staking-Transaktion aufgebaut wird. Babylon schaltet die standardmäßige Art, einen Taproot-Ausgang auszugeben, vollständig aus und ersetzt sie durch eine bestimmte mathematische Konstante, für die es keinen privaten Schlüssel gibt. Niemand besitzt sie. Nicht einmal das Team, das sie entwickelt hat.
Was das bedeutet: BTC, die in einer dieser Positionen gesperrt sind, können nur unter drei Bedingungen wieder freigegeben werden, die direkt ins Skript geschrieben sind. Es gibt keinen anderen Ausweg.
Die erste gibt die Mittel frei, nachdem die vereinbarte Sperrfrist endet, und erfordert nur die eigene Signatur des Stakers. Die zweite ermöglicht ein vorzeitiges Entbinden, aber nur mit demselben Schlüssel plus einer Schwelle eines Covenant-Komitees. Die dritte ist Slashing und verhält sich anders als beide.
Ich bin immer wieder bei dieser dritten Bedingung gelandet. Laut Babylons eigener Spezifikation muss ein Finality Provider zusammenarbeiten, um zu verhindern, dass sie eintritt, aber diese Zusammenarbeit ist nicht erforderlich, um sie auszulösen. Wenn sie doppelt signieren, erscheint ihr Schlüssel automatisch und die vorab signierte Transaktion führt sich von selbst aus.
Sie haben keine Möglichkeit, das zu stoppen.
Was mich überrascht hat, war, dass dafür nichts Neues erfunden werden musste. Babylon nutzt Taproot genau so, wie es die eigenen Entwickler von Bitcoin beabsichtigt haben.
Das, was ich immer noch beobachte, ist, wie sich die Covenant-Komitee-Ebene entwickelt. In ihrer eigenen Dokumentation wird erwähnt, dass man über die aktuelle Struktur hinausgehen möchte, sobald native Funktionalität direkt auf Bitcoin verfügbar ist.
#baby $BABY
Verifiziert
Ich habe mir die tatsächliche Skriptstruktur @BabylonLabs_io uses angesehen, die Babylon auf Bitcoin verwendet, und eine bewusste Entscheidung darin taucht in keiner Ankündigung auf.
Diese Entscheidung bildet die Grundlage dafür, wie eine Staking-Transaktion aufgebaut wird. Babylon schaltet die standardmäßige Art, einen Taproot-Ausgang auszugeben, vollständig aus und ersetzt sie durch eine bestimmte mathematische Konstante, für die es keinen privaten Schlüssel gibt. Niemand besitzt sie. Nicht einmal das Team, das sie entwickelt hat.
Was das bedeutet: BTC, die in einer dieser Positionen gesperrt sind, können nur unter drei Bedingungen wieder freigegeben werden, die direkt ins Skript geschrieben sind. Es gibt keinen anderen Ausweg.
Die erste gibt die Mittel frei, nachdem die vereinbarte Sperrfrist endet, und erfordert nur die eigene Signatur des Stakers. Die zweite ermöglicht ein vorzeitiges Entbinden, aber nur mit demselben Schlüssel plus einer Schwelle eines Covenant-Komitees. Die dritte ist Slashing und verhält sich anders als beide.
Ich bin immer wieder bei dieser dritten Bedingung gelandet. Laut Babylons eigener Spezifikation muss ein Finality Provider zusammenarbeiten, um zu verhindern, dass sie eintritt, aber diese Zusammenarbeit ist nicht erforderlich, um sie auszulösen. Wenn sie doppelt signieren, erscheint ihr Schlüssel automatisch und die vorab signierte Transaktion führt sich von selbst aus.
Sie haben keine Möglichkeit, das zu stoppen.
Was mich überrascht hat, war, dass dafür nichts Neues erfunden werden musste. Babylon nutzt Taproot genau so, wie es die eigenen Entwickler von Bitcoin beabsichtigt haben.
Das, was ich immer noch beobachte, ist, wie sich die Covenant-Komitee-Ebene entwickelt. In ihrer eigenen Dokumentation wird erwähnt, dass man über die aktuelle Struktur hinausgehen möchte, sobald native Funktionalität direkt auf Bitcoin verfügbar ist.
#baby $BABY
Diese Entscheidung bildet die Grundlage dafür, wie eine Staking-Transaktion aufgebaut wird. Babylon schaltet die standardmäßige Art, einen Taproot-Ausgang auszugeben, vollständig aus und ersetzt sie durch eine bestimmte mathematische Konstante, für die es keinen privaten Schlüssel gibt. Niemand besitzt sie. Nicht einmal das Team, das sie entwickelt hat.
Was das bedeutet: BTC, die in einer dieser Positionen gesperrt sind, können nur unter drei Bedingungen wieder freigegeben werden, die direkt ins Skript geschrieben sind. Es gibt keinen anderen Ausweg.
Die erste gibt die Mittel frei, nachdem die vereinbarte Sperrfrist endet, und erfordert nur die eigene Signatur des Stakers. Die zweite ermöglicht ein vorzeitiges Entbinden, aber nur mit demselben Schlüssel plus einer Schwelle eines Covenant-Komitees. Die dritte ist Slashing und verhält sich anders als beide.
Ich bin immer wieder bei dieser dritten Bedingung gelandet. Laut Babylons eigener Spezifikation muss ein Finality Provider zusammenarbeiten, um zu verhindern, dass sie eintritt, aber diese Zusammenarbeit ist nicht erforderlich, um sie auszulösen. Wenn sie doppelt signieren, erscheint ihr Schlüssel automatisch und die vorab signierte Transaktion führt sich von selbst aus.
Sie haben keine Möglichkeit, das zu stoppen.
Was mich überrascht hat, war, dass dafür nichts Neues erfunden werden musste. Babylon nutzt Taproot genau so, wie es die eigenen Entwickler von Bitcoin beabsichtigt haben.
Das, was ich immer noch beobachte, ist, wie sich die Covenant-Komitee-Ebene entwickelt. In ihrer eigenen Dokumentation wird erwähnt, dass man über die aktuelle Struktur hinausgehen möchte, sobald native Funktionalität direkt auf Bitcoin verfügbar ist.
#baby $BABY
...........
MICHAEL MOORE
·
--
Ich habe eine Zeile in Babylons Blogbeitrag vom 25. Juni 2026 entdeckt, die mir die Sicht auf das gesamte Projekt verändert hat.
Sie war in der Partnerschaftsankündigung von Aegis versteckt. Gegen Ende: „Über das anfängliche Produkt hinaus zeigt diese Integration auch, wie Anwendungen mit TBV und Aave v4 aufbauen können.“
Dieser Satz ordnet die Dinge neu. TBV plus Aave V4 ist nicht ein einzelner Lending-Kanal. Es ist eine offene Schicht, auf der andere DeFi-Protokolle direkt aufbauen können.
Der Großteil der Diskussion bleibt bei der Aave-Kreditaufnahme-Funktion. Was ich jedoch interessanter fand, ist, dass die Architektur so entworfen wurde, dass sie wiederverwendbar ist – nicht von Anfang an an ein einziges Ergebnis gebunden.
Das Muster ist bereits sichtbar. Aegis baut Festzins-Kredit auf genau dieser gleichen Plattform, am 25. Juni 2026. GoMining hat ein Mining-Yield-Produkt mit derselben Infrastruktur strukturiert, am 5. Mai 2026.
Zwei völlig unterschiedliche Ergebnisse. Sieben Wochen auseinander.
Ich bin zurückgegangen, um zu bestätigen, dass „first“ beabsichtigt war. Babylons eigener X-Post, als Aave V4 live ging, sagte: „Der erste TBV Use Case ist native Bitcoin-Kreditaufnahme auf Aave v4.“ Das war absichtlich.
Der Vault First Roadmap von Oktober 2025 listete auf, wohin das schließlich führt: Lending, Stablecoins, PERP DEX. Die frühe Taktung deutet darauf hin, dass diese Liste nicht hypothetisch ist.
Was ich weiterhin beobachte, ist, ob diese Schicht weiterhin nur auf Ethereum beschränkt bleibt. Offizielle Doku sagt, dass das Vault-Protokoll für jede Blockchain funktioniert. Wie viele Chains tatsächlich integrieren, ist noch offen.
$BABY #baby @BabylonLabs_io
Sie war in der Partnerschaftsankündigung von Aegis versteckt. Gegen Ende: „Über das anfängliche Produkt hinaus zeigt diese Integration auch, wie Anwendungen mit TBV und Aave v4 aufbauen können.“
Dieser Satz ordnet die Dinge neu. TBV plus Aave V4 ist nicht ein einzelner Lending-Kanal. Es ist eine offene Schicht, auf der andere DeFi-Protokolle direkt aufbauen können.
Der Großteil der Diskussion bleibt bei der Aave-Kreditaufnahme-Funktion. Was ich jedoch interessanter fand, ist, dass die Architektur so entworfen wurde, dass sie wiederverwendbar ist – nicht von Anfang an an ein einziges Ergebnis gebunden.
Das Muster ist bereits sichtbar. Aegis baut Festzins-Kredit auf genau dieser gleichen Plattform, am 25. Juni 2026. GoMining hat ein Mining-Yield-Produkt mit derselben Infrastruktur strukturiert, am 5. Mai 2026.
Zwei völlig unterschiedliche Ergebnisse. Sieben Wochen auseinander.
Ich bin zurückgegangen, um zu bestätigen, dass „first“ beabsichtigt war. Babylons eigener X-Post, als Aave V4 live ging, sagte: „Der erste TBV Use Case ist native Bitcoin-Kreditaufnahme auf Aave v4.“ Das war absichtlich.
Der Vault First Roadmap von Oktober 2025 listete auf, wohin das schließlich führt: Lending, Stablecoins, PERP DEX. Die frühe Taktung deutet darauf hin, dass diese Liste nicht hypothetisch ist.
Was ich weiterhin beobachte, ist, ob diese Schicht weiterhin nur auf Ethereum beschränkt bleibt. Offizielle Doku sagt, dass das Vault-Protokoll für jede Blockchain funktioniert. Wie viele Chains tatsächlich integrieren, ist noch offen.
$BABY #baby @BabylonLabs_io
Anmelden und weiter Inhalte entdecken