$BABY $UAI $COTI #baby @BabylonLabs_io

At first I assumed the covenant committee was a bootstrap step, something Babylon would retire once its own roadmap matured, the same way most young protocols promise to decentralize on their own timeline. The documentation says something quieter and stranger than that.
The committee exists because Bitcoin itself has no native way to enforce covenants, no opcode that can force a UTXO to spend only through pre-agreed rules. So Babylon built a 6-of-9 multisig to emulate that missing function, watching staking requests, co-signing unbonding and slashing, standing in for a capability Bitcoin Script simply doesn't have yet. That part is honest engineering around a real gap, and the trust assumption is genuinely lighter than a normal custodial multisig, existential honesty instead of majority honesty, one honest signer is enough to stop theft.
What stopped me was the exit condition. Babylon's own documentation doesn't say the committee retires once governance matures, or once a certain TVL threshold is hit, or once some internal milestone ships. It says the committee stays until covenant functionality becomes available natively on Bitcoin, through opcodes like OP-CAT or OP-CTV that Bitcoin Core hasn't adopted and has no committed timeline to adopt. The retirement date isn't on Babylon's roadmap. It's sitting inside a different protocol's governance process, one Babylon has no vote in and no ability to accelerate.
So the trust didn't disappear when Babylon called this a Bitcoin-secured system. It moved one layer further away, off a multisig with a defined membership and onto a Bitcoin soft fork that may or may not ship this decade. Six of nine known signers is at least a trust assumption you can name. A pending opcode upgrade with no deadline is a trust assumption you can only wait on.

The covenant committee stays until Bitcoin adds covenant opcodes. No Babylon timeline controls it.
Your take? 👀