Ein Inhaber unterzeichnet eine BABY-Delegation, sieht, dass die Transaktion bestätigt wird, und nimmt natürlich an, dass der Einsatz aktiv ist.
Ich habe diese Bestätigung anfangs genauso verstanden.
Babylons epochisiertes Staking-Mechanismus gibt dem Ganzen eine engere Bedeutung.
Die Delegation wird sofort anerkannt, aber sie gelangt in eine verzögerte Ausführungswarteschlange. Die Validator-Power ändert sich nicht, bis die aktuelle Epoch endet und die in der Warteschlange befindlichen Staking-Nachrichten gemeinsam verarbeitet werden.
Diese Grenze erreicht man alle 360 Blöcke, ungefähr eine Stunde bei einer Blockzeit von 10 Sekunden.
Bis dahin bleibt das BABY liquide.
Das erzeugt einen ungewöhnlichen Zwischenstatus. Die Staking-Anweisung existiert zwar on-chain, aber die Token werden nicht gesperrt und die Belohnungen haben noch nicht begonnen. Wenn der Inhaber diesen Kontostand überträgt oder ausgibt, bevor die Epoch endet, kann die bestätigte Anfrage fehlschlagen, wenn die Ausführung schließlich eintrifft.
Die erste Bestätigung ist also kein Beweis für eine aktive Delegation.
Sie ist eher mit einem angenommenen Auftrag zu vergleichen, der noch auf die Abwicklung wartet.
Für einen Inhaber verändert das, wie das grüne Häkchen zu lesen ist. Es bestätigt, dass Babylon die Anweisung erhalten hat. Es bestätigt noch nicht, dass der Validator Stimmrechte gewonnen hat oder dass das Kapital ins Staking eingezahlt wurde.
Ich denke, diese Unterscheidung ist nützlich, weil eine Transaktionsbestätigung sich normalerweise endgültig anfühlt. Hier trennt das Protokoll bewusst die Annahme der Nachricht von der Zustandsaktivierung, sodass Validator-Änderungen gemeinsam an einer deterministischen Grenze erfolgen.
BABY-Staking hat daher zwei Zeitpunkte, die es wert sind, im Blick zu behalten.
Der Inhaber sendet jetzt.
Das Protokoll macht es bei Epoch-Ende wirklich.
@BabylonLabs_io $BABY #baby
Ich habe diese Bestätigung anfangs genauso verstanden.
Babylons epochisiertes Staking-Mechanismus gibt dem Ganzen eine engere Bedeutung.
Die Delegation wird sofort anerkannt, aber sie gelangt in eine verzögerte Ausführungswarteschlange. Die Validator-Power ändert sich nicht, bis die aktuelle Epoch endet und die in der Warteschlange befindlichen Staking-Nachrichten gemeinsam verarbeitet werden.
Diese Grenze erreicht man alle 360 Blöcke, ungefähr eine Stunde bei einer Blockzeit von 10 Sekunden.
Bis dahin bleibt das BABY liquide.
Das erzeugt einen ungewöhnlichen Zwischenstatus. Die Staking-Anweisung existiert zwar on-chain, aber die Token werden nicht gesperrt und die Belohnungen haben noch nicht begonnen. Wenn der Inhaber diesen Kontostand überträgt oder ausgibt, bevor die Epoch endet, kann die bestätigte Anfrage fehlschlagen, wenn die Ausführung schließlich eintrifft.
Die erste Bestätigung ist also kein Beweis für eine aktive Delegation.
Sie ist eher mit einem angenommenen Auftrag zu vergleichen, der noch auf die Abwicklung wartet.
Für einen Inhaber verändert das, wie das grüne Häkchen zu lesen ist. Es bestätigt, dass Babylon die Anweisung erhalten hat. Es bestätigt noch nicht, dass der Validator Stimmrechte gewonnen hat oder dass das Kapital ins Staking eingezahlt wurde.
Ich denke, diese Unterscheidung ist nützlich, weil eine Transaktionsbestätigung sich normalerweise endgültig anfühlt. Hier trennt das Protokoll bewusst die Annahme der Nachricht von der Zustandsaktivierung, sodass Validator-Änderungen gemeinsam an einer deterministischen Grenze erfolgen.
BABY-Staking hat daher zwei Zeitpunkte, die es wert sind, im Blick zu behalten.
Der Inhaber sendet jetzt.
Das Protokoll macht es bei Epoch-Ende wirklich.
@BabylonLabs_io $BABY #baby