Ich habe mir gerade den am 27. Juli aktualisierten Bug-Bounty-Rahmen von Babylon angesehen, und danach fühlte ich mich eher noch unsicherer.
Die höchste Belohnung beträgt 500.000 US-Dollar, 16 Vermögenswerte fallen in den Geltungsbereich – auf den ersten Blick scheint es also nicht an Investitionen in Sicherheit zu mangeln. Doch wenn man genauer hinschaut, werden die Risiken, die ein System tatsächlich in einen größeren Zwischenfall ziehen könnten, klar ausgeschlossen: zentrale Risiken, eine vorübergehende Einstellung der Relays zwischen Bitcoin und Babylon, mehr als ein Drittel böswillige Finality Provider, ein böswilliges Mehrheitsverhalten im Covenant-Komitee oder das Unvermögen, genügend Signaturen zusammenzubekommen, sowie zu niedrig gesetzte Parameter wie die Bestätigungstiefe.
Besonders auffällig ist außerdem, dass die Bounty-Regeln das Testen von Orakeln und von Smart Contracts Dritter verbieten.
Das steht in einem sehr klaren Widerspruch zu der Richtung, die <a>@BabylonLabs_io </a> in letzter Zeit vorangetrieben hat. Babylon hat bereits angekündigt, Trustless Bitcoin Vaults an Aave V4 und Aegis anzuschließen und im vierten Quartal native, mit BTC unterlegte Kredite mit festem Zinssatz auf den Markt zu bringen.
Die Produktkette würde so aussehen: Babylon betreibt die BTC-unterlegte Infrastruktur, Aave den Kreditmarkt, Aegis die Produkte mit festem Zinssatz – und nach außen hin müssten möglicherweise noch Wallets, das Frontend, Orakel und Clearing-Mechanismen angebunden werden.
Was Nutzer sehen, ist „native BTC, Self-Custody, ohne Bridge“ – was Angreifer sehen, sind jedoch die Verantwortungsnahtstellen zwischen mehreren Systemen.
Die dieses Jahr von OpenZeppelin offengelegten Sicherheitsprobleme bei Babylon konzentrieren sich genau auf solche Nahtstellen: abgelaufene Staking-Positionen behalten weiterhin Stimmrechte, Finality Provider umgehen die Inhaftierung, außergewöhnliche Co-Staking-Buchungen führen zu eingefrorenen Geldern und sogar zum Absturz von Validatoren. Offiziell wurde zwar rechtzeitig gefixt, aber das zeigt vielmehr, dass es sich nicht nur um ein theoretisches Risiko handelt.
Ich bezweifle nicht, ob Babylon Audits hat, sondern frage mich: Wenn sich laufend Geschäftslogik mit Komponenten Dritter überlagert, wer trägt dann die Verantwortung für Unfälle, die „zwischen den Komponenten“ passieren?
Sicherheit darf man nicht nur daran messen, ob in einem einzelnen Repository eine Schwachstelle steckt. Wenn es wirklich zu einem Vorfall kommt, kann am Ende oft jede Partei nachweisen, dass ihr Code in Ordnung ist – und trotzdem kann niemand garantieren, dass die Gelder der Nutzer wirklich sicher sind.
#baby $BABY @BabylonLabs_io
Die höchste Belohnung beträgt 500.000 US-Dollar, 16 Vermögenswerte fallen in den Geltungsbereich – auf den ersten Blick scheint es also nicht an Investitionen in Sicherheit zu mangeln. Doch wenn man genauer hinschaut, werden die Risiken, die ein System tatsächlich in einen größeren Zwischenfall ziehen könnten, klar ausgeschlossen: zentrale Risiken, eine vorübergehende Einstellung der Relays zwischen Bitcoin und Babylon, mehr als ein Drittel böswillige Finality Provider, ein böswilliges Mehrheitsverhalten im Covenant-Komitee oder das Unvermögen, genügend Signaturen zusammenzubekommen, sowie zu niedrig gesetzte Parameter wie die Bestätigungstiefe.
Besonders auffällig ist außerdem, dass die Bounty-Regeln das Testen von Orakeln und von Smart Contracts Dritter verbieten.
Das steht in einem sehr klaren Widerspruch zu der Richtung, die <a>@BabylonLabs_io </a> in letzter Zeit vorangetrieben hat. Babylon hat bereits angekündigt, Trustless Bitcoin Vaults an Aave V4 und Aegis anzuschließen und im vierten Quartal native, mit BTC unterlegte Kredite mit festem Zinssatz auf den Markt zu bringen.
Die Produktkette würde so aussehen: Babylon betreibt die BTC-unterlegte Infrastruktur, Aave den Kreditmarkt, Aegis die Produkte mit festem Zinssatz – und nach außen hin müssten möglicherweise noch Wallets, das Frontend, Orakel und Clearing-Mechanismen angebunden werden.
Was Nutzer sehen, ist „native BTC, Self-Custody, ohne Bridge“ – was Angreifer sehen, sind jedoch die Verantwortungsnahtstellen zwischen mehreren Systemen.
Die dieses Jahr von OpenZeppelin offengelegten Sicherheitsprobleme bei Babylon konzentrieren sich genau auf solche Nahtstellen: abgelaufene Staking-Positionen behalten weiterhin Stimmrechte, Finality Provider umgehen die Inhaftierung, außergewöhnliche Co-Staking-Buchungen führen zu eingefrorenen Geldern und sogar zum Absturz von Validatoren. Offiziell wurde zwar rechtzeitig gefixt, aber das zeigt vielmehr, dass es sich nicht nur um ein theoretisches Risiko handelt.
Ich bezweifle nicht, ob Babylon Audits hat, sondern frage mich: Wenn sich laufend Geschäftslogik mit Komponenten Dritter überlagert, wer trägt dann die Verantwortung für Unfälle, die „zwischen den Komponenten“ passieren?
Sicherheit darf man nicht nur daran messen, ob in einem einzelnen Repository eine Schwachstelle steckt. Wenn es wirklich zu einem Vorfall kommt, kann am Ende oft jede Partei nachweisen, dass ihr Code in Ordnung ist – und trotzdem kann niemand garantieren, dass die Gelder der Nutzer wirklich sicher sind.
#baby $BABY @BabylonLabs_io
