ich habe gerade geprüft, wie lange native BTC tatsächlich braucht, um über @BabylonLabs_io and aktiv zu werden, und dachte, die Antwort wäre einfach eine Bitcoin-Bestätigungsnummer.
30 Blöcke.
einfach genug.
dann ist mir die Bedingung aufgefallen, die direkt danach steht.
@BabylonLabs_io n sagt, dass 30 BTC-Blockbestätigungen erforderlich sind, damit ein Stake aktiv wird, unter der Annahme, dass der ausgewählte Finality Provider bereits aktiv ist und zufällige Werte (randomness) mit einem Zeitstempel versehen hat.
das war der Teil, der den Satz für mich verändert hat.
Bitcoin-Bestätigungen zeigen, dass die Staking-Transaktion tief genug „begraben“ ist.
Sie zeigen jedoch nicht, dass der Finality Provider operativ bereit ist, die an ihn delegierte Voting Power zu nutzen.
Und der Finality Provider erhält das BTC nicht.
Das BTC bleibt in einem Bitcoin-Staking-Script gesperrt, während die Voting Power dem ausgewählten Provider zugewiesen wird. Um Finality-Votes abzugeben, braucht dieser Provider Voting Power sowie öffentliche Randomness, die vorab fest zugesagt und BTC-zeitgestempelt wurde.
So kann eine Staking-Transaktion 30 Bestätigungen erreichen, während die Aktivierung noch auf den Status des ausgewählten Finality Providers und die Bereitschaft der Randomness wartet.
Ich hatte meinen Kaffee schon vor sich hin auskühlen lassen, während ich über die zwei unterschiedlichen „Türen“ nachdachte, die in einem einzigen ausstehenden Status versteckt sind.
Eine Tür ist die Bitcoin-Bestätigungstiefe.
die andere ist die Bereitschaft des Finality Providers.
Daran ändert sich nichts in Bezug auf Custody.
Der Staker bleibt weiterhin Controller und Begünstigter des Bitcoin-Stakes, und der Unbonding-Pfad des Protokolls erfordert nicht die Zustimmung des Finality Providers.
Und die Aktivierung sollte auch nicht in garantierte Erträge „abgeflacht“ werden.
Babylon’s Operator-Docs verknüpfen die Berechtigung für Rewards mit der tatsächlichen Teilnahme am Finality-Voting. Ein Provider muss aktiv sein und Finality-Votes abgeben, damit sich Rewards ansammeln können.
Diese Trennung ergibt Sinn.
Babylon sollte delegiertes Bitcoin nicht als operativen Sicherheitsnachweis zählen, bis der Provider tatsächlich abstimmen kann.
Aber Nutzer brauchen wahrscheinlich beide Bedingungen klar angezeigt: 30 Bestätigungen allein garantieren nicht, dass ein Stake aktiv ist, und eine aktive Delegation garantiert keine kontinuierlichen Rewards, wenn der Provider aufhört zu voten.
#baby $BABY $COTI
30 Blöcke.
einfach genug.
dann ist mir die Bedingung aufgefallen, die direkt danach steht.
@BabylonLabs_io n sagt, dass 30 BTC-Blockbestätigungen erforderlich sind, damit ein Stake aktiv wird, unter der Annahme, dass der ausgewählte Finality Provider bereits aktiv ist und zufällige Werte (randomness) mit einem Zeitstempel versehen hat.
das war der Teil, der den Satz für mich verändert hat.
Bitcoin-Bestätigungen zeigen, dass die Staking-Transaktion tief genug „begraben“ ist.
Sie zeigen jedoch nicht, dass der Finality Provider operativ bereit ist, die an ihn delegierte Voting Power zu nutzen.
Und der Finality Provider erhält das BTC nicht.
Das BTC bleibt in einem Bitcoin-Staking-Script gesperrt, während die Voting Power dem ausgewählten Provider zugewiesen wird. Um Finality-Votes abzugeben, braucht dieser Provider Voting Power sowie öffentliche Randomness, die vorab fest zugesagt und BTC-zeitgestempelt wurde.
So kann eine Staking-Transaktion 30 Bestätigungen erreichen, während die Aktivierung noch auf den Status des ausgewählten Finality Providers und die Bereitschaft der Randomness wartet.
Ich hatte meinen Kaffee schon vor sich hin auskühlen lassen, während ich über die zwei unterschiedlichen „Türen“ nachdachte, die in einem einzigen ausstehenden Status versteckt sind.
Eine Tür ist die Bitcoin-Bestätigungstiefe.
die andere ist die Bereitschaft des Finality Providers.
Daran ändert sich nichts in Bezug auf Custody.
Der Staker bleibt weiterhin Controller und Begünstigter des Bitcoin-Stakes, und der Unbonding-Pfad des Protokolls erfordert nicht die Zustimmung des Finality Providers.
Und die Aktivierung sollte auch nicht in garantierte Erträge „abgeflacht“ werden.
Babylon’s Operator-Docs verknüpfen die Berechtigung für Rewards mit der tatsächlichen Teilnahme am Finality-Voting. Ein Provider muss aktiv sein und Finality-Votes abgeben, damit sich Rewards ansammeln können.
Diese Trennung ergibt Sinn.
Babylon sollte delegiertes Bitcoin nicht als operativen Sicherheitsnachweis zählen, bis der Provider tatsächlich abstimmen kann.
Aber Nutzer brauchen wahrscheinlich beide Bedingungen klar angezeigt: 30 Bestätigungen allein garantieren nicht, dass ein Stake aktiv ist, und eine aktive Delegation garantiert keine kontinuierlichen Rewards, wenn der Provider aufhört zu voten.
#baby $BABY $COTI