Ich denke immer wieder darüber nach, wie in einer Werbung für ein Heimsicherheitssystem nie der Typ erwähnt wird, der den Ersatzschlüssel hat.
Genau das stört mich an Babylons Bitcoin-Staking-Pitch. Kein Custodian, keine Bridge, BTC verlässt die Kette nie – und das ist ein echtes technisches Plus. Aber es beantwortet eine Frage, die inzwischen niemanden mehr wirklich beschäftigt. Die entscheidende Frage ist: Wer betreibt den Finality Provider, den du gerade delegiert hast, und was passiert, wenn sie einen Fehler machen?
Je mehr ich mir das angeschaut habe, desto seltsamer wurden die Slashing-Zahlen. Babylons Doku nennt 0,1 %, ich habe ältere Ausarbeitungen gesehen, die 33 % anführen, und in einigen Community-Posts werden 5 % herumgeworfen. Das ist kein Rundungsfehler – das sind drei verschiedene Risikoprofile für dasselbe Produkt.
Und selbst wenn die Slashing-Historie direkt dort auf einem Explorer steht, ist das nicht dasselbe wie jemand, der sie überprüft, bevor man einen FP auswählt. Die Leute nehmen einfach den, der ganz oben auf der Liste steht, oder den mit der auffälligsten APY.
Wirkt weniger wie ein spezifischer Fehler von Babylon und mehr wie die Standard-„Restaking“-Strategie, bei der die Vertrauensannahme eine Ebene nach unten verlagert wird – genau dorthin, wo Nutzer sie am wenigsten sehen können.
Ich bin wirklich neugierig, ob irgendjemand seinen FP tatsächlich geprüft hat, bevor er ihn delegiert hat, oder ob nach der Reihenfolge in der Liste ausgewählt wird?
#baby $BABY @BabylonLabs_io
Genau das stört mich an Babylons Bitcoin-Staking-Pitch. Kein Custodian, keine Bridge, BTC verlässt die Kette nie – und das ist ein echtes technisches Plus. Aber es beantwortet eine Frage, die inzwischen niemanden mehr wirklich beschäftigt. Die entscheidende Frage ist: Wer betreibt den Finality Provider, den du gerade delegiert hast, und was passiert, wenn sie einen Fehler machen?
Je mehr ich mir das angeschaut habe, desto seltsamer wurden die Slashing-Zahlen. Babylons Doku nennt 0,1 %, ich habe ältere Ausarbeitungen gesehen, die 33 % anführen, und in einigen Community-Posts werden 5 % herumgeworfen. Das ist kein Rundungsfehler – das sind drei verschiedene Risikoprofile für dasselbe Produkt.
Und selbst wenn die Slashing-Historie direkt dort auf einem Explorer steht, ist das nicht dasselbe wie jemand, der sie überprüft, bevor man einen FP auswählt. Die Leute nehmen einfach den, der ganz oben auf der Liste steht, oder den mit der auffälligsten APY.
Wirkt weniger wie ein spezifischer Fehler von Babylon und mehr wie die Standard-„Restaking“-Strategie, bei der die Vertrauensannahme eine Ebene nach unten verlagert wird – genau dorthin, wo Nutzer sie am wenigsten sehen können.
Ich bin wirklich neugierig, ob irgendjemand seinen FP tatsächlich geprüft hat, bevor er ihn delegiert hat, oder ob nach der Reihenfolge in der Liste ausgewählt wird?
#baby $BABY @BabylonLabs_io