Just finished translating Babylon’s script implementation and the sections related to the whitepaper. What stands out most isn’t where the staking yield comes from, but the role of the Covenant Committee. A lot of people’s first reaction is: since the system repeatedly emphasizes user self-custody of BTC, why add another committee? It looks like a centralized patch forced onto the ideal of native staking.
But that’s not the case. Bitcoin Script’s capability boundaries are fixed: it can verify signatures, time locks, and path conditions, but it can’t—like Ethereum contracts—dynamically decide based on complex on-chain state things like “whether to slash, and how to slash.” Babylon wants to hard-wire PoS-like constraints and penalty logic onto BTC without changing Bitcoin consensus. So the only feasible approach is to use threshold signatures by the committee to gate key transaction paths, and confine Unbonding and Slashing within predefined rules. The committee doesn’t have the freedom to just move users’ funds; the normal exit process still goes through the timelock, and the assets ultimately return to the users. It’s more like a gatekeeper that enforces rules than a custodian.
This design does reduce traditional custody risk quite a lot, but trust doesn’t disappear—it just shifts from “who holds the private keys” to “where the committee’s permission boundaries are, whether operation is transparent, and whether later governance could bloat.” In the short term, TVL is certainly rising enthusiastically. What I care about more is whether this chain of trust will slowly thicken as the protocol evolves. If someday Bitcoin’s native covenant capabilities truly mature—so the system can absorb these restriction logics by itself—does this layered structure still need to exist?
This point is more worth watching than the locked amount. #baby @BabylonLabs_io $BABY
But that’s not the case. Bitcoin Script’s capability boundaries are fixed: it can verify signatures, time locks, and path conditions, but it can’t—like Ethereum contracts—dynamically decide based on complex on-chain state things like “whether to slash, and how to slash.” Babylon wants to hard-wire PoS-like constraints and penalty logic onto BTC without changing Bitcoin consensus. So the only feasible approach is to use threshold signatures by the committee to gate key transaction paths, and confine Unbonding and Slashing within predefined rules. The committee doesn’t have the freedom to just move users’ funds; the normal exit process still goes through the timelock, and the assets ultimately return to the users. It’s more like a gatekeeper that enforces rules than a custodian.
This design does reduce traditional custody risk quite a lot, but trust doesn’t disappear—it just shifts from “who holds the private keys” to “where the committee’s permission boundaries are, whether operation is transparent, and whether later governance could bloat.” In the short term, TVL is certainly rising enthusiastically. What I care about more is whether this chain of trust will slowly thicken as the protocol evolves. If someday Bitcoin’s native covenant capabilities truly mature—so the system can absorb these restriction logics by itself—does this layered structure still need to exist?
This point is more worth watching than the locked amount. #baby @BabylonLabs_io $BABY