Verbrachte diese Aufgabe damit, in Babylons modulare Sicherheitsarchitektur einzutauchen — $BABY , #baby , @BabylonLabs_io — und das, was tatsächlich hängen geblieben ist, stand nicht in den Unterlagen. Es war ein GitHub-Fehlerhinweis, in den ich beim Prüfen des Costaking-Moduls gestolpert bin.
GHSA-4rmq-mc2c-r495. Eingereicht gegen x/costaking, den Teil, der angeblich BTC-Delegation und -Belohnungen in Echtzeit nachverfolgt. Dabei stellte sich heraus, dass, wenn ein Finality Provider aus der aktiven Menge ausfällt, exakt auf derselben Blockhöhe, auf der sich ein Delegator unbonded, das Modul diese Einlage weiterhin als aktiv zählt. Phantom-Einlage — die Belohnungen laufen weiter auf BTC, das bereits abgezogen wurde. CVSS 5.3, und laut der Hinweis-Seite ist bislang „keine Lösung verfügbar“, Stand heute.
Ich habe das kurz sacken lassen. Der „modulare“-Vorschlag bedeutet, dass jede Schicht für sich steht — und das Bitcoin-Timelock-Skript tut das tatsächlich, ohne dass man Vertrauen braucht. Aber die Buchhaltung auf der Cosmos-Seite darum herum scheint offenbar doch noch etwas zu benötigen. Hab nebenbei auch CoinGecko gecheckt — BABYs 24h-Volumen liegt bei rund 5,3 Mio. $ gegenüber einem Umlauf von 4B+ und ist über die Woche etwa um 3 % gefallen. Ruhig, für etwas mit Milliarden an gestaktem BTC darunter.
Kleiner CVSS-Score, enger Auslösefall. Hmm — könnte in der Praxis vielleicht nicht viel ausmachen. Aber es ist genau diese Lücke zwischen „modular“ und „wirklich modular“, die in keinem Thread je auftaucht. Lässt mich fragen, was sonst noch nicht angefasst wurde.