What surprised me most while going back through Babylon's staking contract design was how much weight rests on the covenant committee, a detail that tends to get glossed over in the "trustless Bitcoin staking" framing.
Because Bitcoin Script can't natively express Babylon's staking, unbonding, and slashing conditions, the protocol relies on a fixed group of signers, currently a 6-of-9 multisig, to co-sign the relevant transactions. In practice this happens upfront: when a staker deposits, the committee pre-signs the unbonding and slashing paths using adaptor signatures, so the staker isn't waiting on the committee later to exit. That design choice does meaningfully reduce the liveness risk you'd expect from a standing multisig.
Still, the committee's existence means the system depends on a specific, governance-selected set of keys behaving honestly and staying available indefinitely, since every staking transaction ever created references their public keys at that point in time. Babylon's own materials note the plan to phase out the committee once Bitcoin gains native covenant support, which is itself an admission that this isn't the end state, just a working substitute for capabilities Bitcoin doesn't yet have. That's a reasonable engineering tradeoff, but it sits awkwardly next to marketing language that calls the system self-custodial without qualification.
I keep wondering how the protocol handles committee rotation for BTC already locked under the old key set, and whether that transition turns out to be simpler in theory than in practice.
$BABY @BabylonLabs_io #baby
#OilDropsAbout6% $COTI #Coti #ON #AKE $ESP
Because Bitcoin Script can't natively express Babylon's staking, unbonding, and slashing conditions, the protocol relies on a fixed group of signers, currently a 6-of-9 multisig, to co-sign the relevant transactions. In practice this happens upfront: when a staker deposits, the committee pre-signs the unbonding and slashing paths using adaptor signatures, so the staker isn't waiting on the committee later to exit. That design choice does meaningfully reduce the liveness risk you'd expect from a standing multisig.
Still, the committee's existence means the system depends on a specific, governance-selected set of keys behaving honestly and staying available indefinitely, since every staking transaction ever created references their public keys at that point in time. Babylon's own materials note the plan to phase out the committee once Bitcoin gains native covenant support, which is itself an admission that this isn't the end state, just a working substitute for capabilities Bitcoin doesn't yet have. That's a reasonable engineering tradeoff, but it sits awkwardly next to marketing language that calls the system self-custodial without qualification.
I keep wondering how the protocol handles committee rotation for BTC already locked under the old key set, and whether that transition turns out to be simpler in theory than in practice.
$BABY @BabylonLabs_io #baby
#OilDropsAbout6% $COTI #Coti #ON #AKE $ESP