Ich habe den gemeinsamen Staking-Flow von Babylon noch einmal durchlaufen. Am unangenehmsten ist: Viele entscheidende Bedingungen merkt der Nutzer erst, wenn keine Belohnung ausgezahlt wurde.
Offiziell wird der Ablauf in zwei Schritte zusammengefasst: BTC wird an einen Finality Provider delegiert, und BABY delegiert anschließend an den Validator. In der Praxis muss der BTC jedoch von PENDING über VERIFIED bis schließlich in ACTIVE übergehen. Nur der ACTIVE-Status zählt als Belohnung. Außerdem müssen BTC und BABY dieselbe BABY-Adresse verwenden. Wenn die Adressen nicht übereinstimmen, wird die Belohnung beim gemeinsamen Staking direkt auf null gesetzt. Um die Belohnungs-Effizienz maximal auszuschöpfen, muss man außerdem im Kopf behalten: 1 BTC entspricht 20.000 BABY.
Das Problem ist, dass normale Nutzer „eingereicht“ oder „verifiziert“ sehen und leicht davon ausgehen, dass alles schon erledigt ist. Wo es genau hakt, warum es keine Belohnung gibt, ob der ausgewählte Finality Provider noch aktiv ist und ob die beiden Adressen überhaupt zueinander passen – das sollte die Seite direkt klar erklären. Die Nutzer sollten nicht in der Dokumentation herumstöbern und raten müssen.
Aktuell zeigt das Babylon-Panel an, dass etwa 51.342 BTC gestaked sind. Von 132 Finality Providern sind nur 36 aktiv. Die jährliche Rendite liegt im Bereich von 0,04 % bis 0,70 %. Die Größe ist bereits da, aber auf Nutzerseite wird immer noch durch eigenes Debugging versucht, das Problem zu finden.
Auch der Exit-Teil ist nicht so leicht, wie es auf den ersten Blick wirkt. In der offiziellen Doku zur BTC-Unstaking-Delegation steht, dass die minimale Wartezeit 301 Bitcoin-Blocks beträgt. Beim CLI-Fehlersuche kann es außerdem um Gas-Parameter, RPC- und GRPC-Konfiguration gehen. Wenn sich das nicht beheben lässt, soll man in den Discord gehen und um Hilfe bitten.
Ich zweifle an @BabylonLabs_io ziemlich direkt: Komplexität im Protokoll kann man verstehen – aber das Produkt darf die Komplexität nicht 1:1 an die Nutzer abgeben.
Was wirklich fehlt, sind Erklärungen zu den Zuständen, eine klare Fehlerlokalisierung und ein eindeutiger Behandlungsweg. Andernfalls wird das vermeintliche „Self Custody“ sehr schnell zu Folgendem: Alle Fragen, die man nicht versteht, trägt am Ende der Nutzer selbst.
#baby $BABY @BabylonLabs_io
Offiziell wird der Ablauf in zwei Schritte zusammengefasst: BTC wird an einen Finality Provider delegiert, und BABY delegiert anschließend an den Validator. In der Praxis muss der BTC jedoch von PENDING über VERIFIED bis schließlich in ACTIVE übergehen. Nur der ACTIVE-Status zählt als Belohnung. Außerdem müssen BTC und BABY dieselbe BABY-Adresse verwenden. Wenn die Adressen nicht übereinstimmen, wird die Belohnung beim gemeinsamen Staking direkt auf null gesetzt. Um die Belohnungs-Effizienz maximal auszuschöpfen, muss man außerdem im Kopf behalten: 1 BTC entspricht 20.000 BABY.
Das Problem ist, dass normale Nutzer „eingereicht“ oder „verifiziert“ sehen und leicht davon ausgehen, dass alles schon erledigt ist. Wo es genau hakt, warum es keine Belohnung gibt, ob der ausgewählte Finality Provider noch aktiv ist und ob die beiden Adressen überhaupt zueinander passen – das sollte die Seite direkt klar erklären. Die Nutzer sollten nicht in der Dokumentation herumstöbern und raten müssen.
Aktuell zeigt das Babylon-Panel an, dass etwa 51.342 BTC gestaked sind. Von 132 Finality Providern sind nur 36 aktiv. Die jährliche Rendite liegt im Bereich von 0,04 % bis 0,70 %. Die Größe ist bereits da, aber auf Nutzerseite wird immer noch durch eigenes Debugging versucht, das Problem zu finden.
Auch der Exit-Teil ist nicht so leicht, wie es auf den ersten Blick wirkt. In der offiziellen Doku zur BTC-Unstaking-Delegation steht, dass die minimale Wartezeit 301 Bitcoin-Blocks beträgt. Beim CLI-Fehlersuche kann es außerdem um Gas-Parameter, RPC- und GRPC-Konfiguration gehen. Wenn sich das nicht beheben lässt, soll man in den Discord gehen und um Hilfe bitten.
Ich zweifle an @BabylonLabs_io ziemlich direkt: Komplexität im Protokoll kann man verstehen – aber das Produkt darf die Komplexität nicht 1:1 an die Nutzer abgeben.
Was wirklich fehlt, sind Erklärungen zu den Zuständen, eine klare Fehlerlokalisierung und ein eindeutiger Behandlungsweg. Andernfalls wird das vermeintliche „Self Custody“ sehr schnell zu Folgendem: Alle Fragen, die man nicht versteht, trägt am Ende der Nutzer selbst.
#baby $BABY @BabylonLabs_io