Stopping Payouts is not the same as being able to redirect where BTC goes
In Trustless Bitcoin Vaults (TBV), the Security Council is easily misread as a multisig that controls BTC. The current public testnet uses five Bitcoin public keys with a 3-of-5 statutory quorum. The public keys are written into versioned off-chain protocol parameters for jointly signing CouncilNoPayout. It can prevent a Vault’s Payout, but it cannot send BTC to a new address designated by the Council.
The limitation comes from the Bitcoin spend graph that is fixed when the Vault is created. Depositors pre-sign the Payout and set the legitimate destination up front: a normal exit or self-claim returns to the depositor’s address under the existing conditions and does not require Council approval; the liquidation path goes to an already-authorized Application Vault Keeper address. The Council’s keys are not among these collection destinations, so even if the statutory quorum is reached, the Council only has the ability to block—not to redirect assets.
This is different from the No-Payout broadcast by a challenger in the normal dispute process: the latter is based on an invalid Claim being challenged and then being unable to provide a counter-proof. CouncilNoPayout is intended for extreme failures or special recoveries that the standard mechanism cannot handle. The pause on the Ethereum side is another layer: it can pause application actions, but it cannot rewrite already-existing Pre-PegIn refund and WOTS self-claim paths.
CouncilNoPayout changes my evaluation criteria. I no longer only ask whether there is a committee in the system; instead, I ask what outcomes it can make Bitcoin accept. Being able to stop spending still introduces availability and exit-latency risk; if it cannot create new destinations, then the worst-case consequence is limited to blocking rather than redirecting assets. If Council permissions are abused, legitimate Payouts may still be blocked. If the Council goes offline, emergency recovery capability also declines. You can’t write this design as zero risk.
@BabylonLabs_io defines the Security Council as a transitional security net, aiming to gradually retire its power as the protocol matures. What’s truly worth watching isn’t whether a multisig exists, but how far emergency privileges are constrained within the Bitcoin spending path. $BTC $ETH
$BABY
#baby
In Trustless Bitcoin Vaults (TBV), the Security Council is easily misread as a multisig that controls BTC. The current public testnet uses five Bitcoin public keys with a 3-of-5 statutory quorum. The public keys are written into versioned off-chain protocol parameters for jointly signing CouncilNoPayout. It can prevent a Vault’s Payout, but it cannot send BTC to a new address designated by the Council.
The limitation comes from the Bitcoin spend graph that is fixed when the Vault is created. Depositors pre-sign the Payout and set the legitimate destination up front: a normal exit or self-claim returns to the depositor’s address under the existing conditions and does not require Council approval; the liquidation path goes to an already-authorized Application Vault Keeper address. The Council’s keys are not among these collection destinations, so even if the statutory quorum is reached, the Council only has the ability to block—not to redirect assets.
This is different from the No-Payout broadcast by a challenger in the normal dispute process: the latter is based on an invalid Claim being challenged and then being unable to provide a counter-proof. CouncilNoPayout is intended for extreme failures or special recoveries that the standard mechanism cannot handle. The pause on the Ethereum side is another layer: it can pause application actions, but it cannot rewrite already-existing Pre-PegIn refund and WOTS self-claim paths.
CouncilNoPayout changes my evaluation criteria. I no longer only ask whether there is a committee in the system; instead, I ask what outcomes it can make Bitcoin accept. Being able to stop spending still introduces availability and exit-latency risk; if it cannot create new destinations, then the worst-case consequence is limited to blocking rather than redirecting assets. If Council permissions are abused, legitimate Payouts may still be blocked. If the Council goes offline, emergency recovery capability also declines. You can’t write this design as zero risk.
@BabylonLabs_io defines the Security Council as a transitional security net, aiming to gradually retire its power as the protocol matures. What’s truly worth watching isn’t whether a multisig exists, but how far emergency privileges are constrained within the Bitcoin spending path. $BTC $ETH
$BABY
#baby