BABY macht Time-Lock-Staking: Was am dringendsten fehlt, ist eine Quittungs-/Kautionsurkunde
Gestern hatte ich $BABY geschrieben und gesagt, bei doppeltem Staking: Lass nicht zu, dass Nutzer, nachdem sie BTC verpfändet haben, noch raten müssen, ob die andere Seite genug hat.
Heute schau in den Vertrag noch eine Zeile mehr: Wenn Babylon Locking, Delegation und Zinsen komplett im Backend bündelt, fehlt dem Nutzer nicht wirklich ein Ein-Klick-Button, sondern eine Kautionsurkunde, die man für den Abgleich verwenden kann.
Native BTC-Staking: Nach außen wirkt es, als würde man einen komplexen Prozess in eine Blackbox verbergen.
Der Nutzer muss kein Skript selbst schreiben, keine Blockhöhe auswählen, keine Slashes beobachten – eine einzige Aussage reicht: Ich möchte, dass diese $BTC für die Sicherheit eingesetzt wird, ohne das Kapital anzufassen, ohne Cross-Chain, und wenn es abgelaufen ist, geht es genau auf dem ursprünglichen Weg zurück.
Den Rest – die schmutzige Arbeit – sollen Finality Provider und der Time-Lock-Skript erledigen.
Dieser Weg an sich ist nicht falsch.
Wie beim Mieten: Der Mieter muss keine Wasserleitung reparieren, keinen Schließzylinder wechseln oder sich mit dem Hausmeister wegen Kleinigkeiten streiten. Du gibst die Kaution an den Vermieter, bekommst den Schlüssel, ziehst ein – und die Erfahrung läuft rund.
Aber was beim Mieten am meisten stört, ist nicht, dass die Wohnung alt ist, sondern dass die Kautionsurkunde aussieht wie Gekritzel.
Bis zu welchem Datum läuft die Mietzeit? Was passiert zwischendurch, wenn der Vermieter wechselt? Wer legt die Hausgeldkosten vor? Wenn Möbel kaputtgehen: wird das von der Kaution abgezogen oder separat berechnet? Wenn man vorzeitig auszieht – ab wann beginnt dann diese Bestätigungsphase von 300 Blöcken?
Übertragen auf BTC-Staking ist genau das der Punkt, der mich heute bei @BabylonLabs_io am meisten beschäftigt.
Wenn Babylon das Deployen der Skripte, die Provider-Auswahl, die Slash-Überwachung und das Unbonding als schmutzige Arbeit im Backend erledigt, ist der Nutzen zweifellos nicht nur „wenige Klicks weniger“. Aber sobald der Prozess im Backend verschwindet, steckt eine Schicht Milchglas zwischen Nutzer und Kapital.
Dann sollte das System nicht einfach einen höheren APY geben, sondern eine nachvollziehbare Spur der Gelder.
Zum Beispiel: Bei welchem Finality Provider ist dieses BTC hinterlegt? Wie hoch ist die Entsperr-Blockhöhe des Time-Locks? Wie stark unterscheiden sich erwartete Erträge und tatsächlich eingegangene Beträge in Prozentpunkten? Wie werden beim Slash Kapital und Belohnungen aufgeteilt? Bleibt das Kapital in diesen zwei Unbonding-Tagen im Skript stecken oder läuft es über eine Übergangsadresse? Und: Ist die komplette Kette irgendwo von der Non-Custody-Linie abgewichen.
Diese Details müssen Nutzer nicht dazu zwingen, sich in ein Script-Audit einzuarbeiten.
Aber zumindest muss verständlich sein: Wie wird mein BTC eigentlich „vermietet“? An welcher Stelle knickt es ein? Und wem legt man am Ende die Kautionsurkunde zum Abgleich vor?
Darum denke ich, dass die Linie #baby nicht nur als „One-Click-Staking“ verstanden werden darf.
Ein-Klick ist nur der Einstieg – die Kautionsurkunde ist das Vertrauen.
Gestern hatte ich $BABY geschrieben und gesagt, bei doppeltem Staking: Lass nicht zu, dass Nutzer, nachdem sie BTC verpfändet haben, noch raten müssen, ob die andere Seite genug hat.
Heute schau in den Vertrag noch eine Zeile mehr: Wenn Babylon Locking, Delegation und Zinsen komplett im Backend bündelt, fehlt dem Nutzer nicht wirklich ein Ein-Klick-Button, sondern eine Kautionsurkunde, die man für den Abgleich verwenden kann.
Native BTC-Staking: Nach außen wirkt es, als würde man einen komplexen Prozess in eine Blackbox verbergen.
Der Nutzer muss kein Skript selbst schreiben, keine Blockhöhe auswählen, keine Slashes beobachten – eine einzige Aussage reicht: Ich möchte, dass diese $BTC für die Sicherheit eingesetzt wird, ohne das Kapital anzufassen, ohne Cross-Chain, und wenn es abgelaufen ist, geht es genau auf dem ursprünglichen Weg zurück.
Den Rest – die schmutzige Arbeit – sollen Finality Provider und der Time-Lock-Skript erledigen.
Dieser Weg an sich ist nicht falsch.
Wie beim Mieten: Der Mieter muss keine Wasserleitung reparieren, keinen Schließzylinder wechseln oder sich mit dem Hausmeister wegen Kleinigkeiten streiten. Du gibst die Kaution an den Vermieter, bekommst den Schlüssel, ziehst ein – und die Erfahrung läuft rund.
Aber was beim Mieten am meisten stört, ist nicht, dass die Wohnung alt ist, sondern dass die Kautionsurkunde aussieht wie Gekritzel.
Bis zu welchem Datum läuft die Mietzeit? Was passiert zwischendurch, wenn der Vermieter wechselt? Wer legt die Hausgeldkosten vor? Wenn Möbel kaputtgehen: wird das von der Kaution abgezogen oder separat berechnet? Wenn man vorzeitig auszieht – ab wann beginnt dann diese Bestätigungsphase von 300 Blöcken?
Übertragen auf BTC-Staking ist genau das der Punkt, der mich heute bei @BabylonLabs_io am meisten beschäftigt.
Wenn Babylon das Deployen der Skripte, die Provider-Auswahl, die Slash-Überwachung und das Unbonding als schmutzige Arbeit im Backend erledigt, ist der Nutzen zweifellos nicht nur „wenige Klicks weniger“. Aber sobald der Prozess im Backend verschwindet, steckt eine Schicht Milchglas zwischen Nutzer und Kapital.
Dann sollte das System nicht einfach einen höheren APY geben, sondern eine nachvollziehbare Spur der Gelder.
Zum Beispiel: Bei welchem Finality Provider ist dieses BTC hinterlegt? Wie hoch ist die Entsperr-Blockhöhe des Time-Locks? Wie stark unterscheiden sich erwartete Erträge und tatsächlich eingegangene Beträge in Prozentpunkten? Wie werden beim Slash Kapital und Belohnungen aufgeteilt? Bleibt das Kapital in diesen zwei Unbonding-Tagen im Skript stecken oder läuft es über eine Übergangsadresse? Und: Ist die komplette Kette irgendwo von der Non-Custody-Linie abgewichen.
Diese Details müssen Nutzer nicht dazu zwingen, sich in ein Script-Audit einzuarbeiten.
Aber zumindest muss verständlich sein: Wie wird mein BTC eigentlich „vermietet“? An welcher Stelle knickt es ein? Und wem legt man am Ende die Kautionsurkunde zum Abgleich vor?
Darum denke ich, dass die Linie #baby nicht nur als „One-Click-Staking“ verstanden werden darf.
Ein-Klick ist nur der Einstieg – die Kautionsurkunde ist das Vertrauen.