@BabylonLabs_io $BABY #baby
I assumed the risk ended when I pressed “Unbond.”
My stake was leaving the system, so I mentally treated the relationship with the Finality Provider as finished.
Bitcoin does not make that transition instantly.
Babylon’s unbonding transaction creates a new Bitcoin output with two remaining paths:
a timelocked exit for the staker;
a slashing path if the delegated Finality Provider double-signs during the unbonding period.
That second path changed how I understood the exit.
The BTC is no longer simply waiting to become spendable. It is still economically accountable for the provider it supported.
I can see the security logic.
If slashing protection disappeared the moment an exit was requested, a provider and its delegators could try to leave just before—or during—misconduct.
Keeping the slashing path alive closes that escape window.
But from the user’s perspective, the state deserves clearer language.
“Unbonding” sounds like the risk has already been detached.
Technically, it is closer to:
exit requested → still slashable → timelock completed → fully spendable
I would want the interface to show the exact block or estimated time when slashing exposure ends, not only when the unbonding transaction begins.
The button starts the exit.
It does not immediately end accountability.
In Babylon, leaving is a process—not a moment.
Should slashing continue during unbonding?
I assumed the risk ended when I pressed “Unbond.”
My stake was leaving the system, so I mentally treated the relationship with the Finality Provider as finished.
Bitcoin does not make that transition instantly.
Babylon’s unbonding transaction creates a new Bitcoin output with two remaining paths:
a timelocked exit for the staker;
a slashing path if the delegated Finality Provider double-signs during the unbonding period.
That second path changed how I understood the exit.
The BTC is no longer simply waiting to become spendable. It is still economically accountable for the provider it supported.
I can see the security logic.
If slashing protection disappeared the moment an exit was requested, a provider and its delegators could try to leave just before—or during—misconduct.
Keeping the slashing path alive closes that escape window.
But from the user’s perspective, the state deserves clearer language.
“Unbonding” sounds like the risk has already been detached.
Technically, it is closer to:
exit requested → still slashable → timelock completed → fully spendable
I would want the interface to show the exact block or estimated time when slashing exposure ends, not only when the unbonding transaction begins.
The button starts the exit.
It does not immediately end accountability.
In Babylon, leaving is a process—not a moment.
Should slashing continue during unbonding?
Until timelock ends
Stop at unbond request
Use a shorter window
Need more data
1 дн. осталось