Ich habe darüber nachgedacht, was passiert, wenn eine BTC-Stake länger ausdauert als die Entscheidungen, die am ersten Tag getroffen wurden.

Babylons Delegations-Erweiterung wirkte anfangs wie eine einfache Wartungsfunktion. Ein Staker kann die Timelock verlängern oder Finality Provider hinzufügen, ohne den vollständigen Unbonding-Zyklus abzuschließen und die Teilnahme zu unterbrechen.

Der Ablauf ist durchdachter, als er klingt.

Die Erweiterung wird zuerst in Babylon Genesis über stakingExpansionRegistrationBabylonTransaction registriert. Nachdem die Delegation den Status VERIFIED erreicht hat, sammelt der Staker Covenant-Expansion-Signaturen ein und sendet die signierte Transaktion an Bitcoin.

Diese Kontinuität ist hilfreich, insbesondere wenn das Warten durch einen vollständigen Exit und eine erneute Teilnahme unnötige Ausfallzeit erzeugen würde.

Doch das Design bewahrt auch die Historie. Jeder Finality Provider aus dem vorherigen Stake muss in der erweiterten Delegation verbleiben. Die aktuelle TypeScript-Bibliothek verlangt zudem, dass der Staking-Betrag unverändert bleibt; zusätzliche UTXOs können Gebühren abdecken, aber die Position nicht vergrößern.

Expansion ist also kein sauberer Neu-Write. Eher ist es, einen Vertrag zu erweitern, während seine früheren Klauseln mitgeführt werden.

Die Stärke ist unterbrechungssichere BTC-Sicherheit. Der Preis dafür ist wachsende Pfadabhängigkeit über Parameterversionen, Covenant-Signaturen und alte Delegationsentscheidungen hinweg.

Wird Babylon die Stake-Erweiterung eines Tages vollständig flexibel machen, oder ist das Erhalten dieser Historie Teil des Sicherheitsmodells?

$BABY

#baby $BABY @BabylonLabs_io