Multisig Isn’t Enough for Bitcoin Bridges

A 2-of-3 multisig is the industry standard for Bitcoin bridges. This creates a single, high-value target where compromising two entities can drain the entire vault. The failure modes are additive, not multiplicative.

• Attack Surface: Compromise 2 of 3 signers via social engineering, legal coercion, or technical exploit.
• Historical Precedent: The Ronin Bridge hack ($625M) was a 5-of-9 multisig failure.
• Systemic Risk: A single bridge failure can trigger a cross-chain contagion event.

Multisig bridges force a brutal trade-off. Increasing signers for safety (e.g., 8-of-12) destroys liveness and user experience, creating its own risks.

• Liveness Risk: A single unresponsive or offline signer can freeze billions in user funds.
• Coordination Overhead: Achieving consensus among geographically dispersed entities adds latency and cost.
• Economic Mismatch: Signer incentives (fee revenue) are misaligned with the catastrophic tail risk they underwrite.

Bridges like Stacks or Rootstock use a federated peg, delegating Bitcoin's security to a separate PoS or multisig system. This creates a weaker security tier for wrapped BTC (e.g., xBTC, rBTC).

• Security Delegation: Bitcoin's 500+ EH/s secures only the base layer, not the bridge's custodial vault.
• Two-Token Model: Creates 'IOU' Bitcoin that trades at a persistent discount during crises.
• Regulatory Attack Vector: The federated signer set is a clear, licensable entity for regulators.

The endgame is light-client bridges that verify, not custody. Projects like Babylon (Bitcoin staking) and Chainway (proof-of-misbehavior) are pioneering ways to use Bitcoin's native script to enforce cross-chain state transitions.

• First-Principles Security: Leverages Bitcoin's consensus directly, eliminating trusted committees.
• Cryptoeconomic Slashing: Malicious actors lose bonded BTC, aligning incentives with the base chain.
• Protocol-Native: Moves the security primitive from an application-layer bridge to a Bitcoin L1 protocol.

A 5-of-9 multisig is not a security model; it's a social consensus waiting to be gamed. The failure of Ronin Bridge ($625M hack) and Wormhole ($325M hack) proves centralized validators are the weakest link.\n- Attack Surface: A single compromised signer can drain the entire vault.\n- Opaque Governance: Signer selection and slashing are often off-chain, non-transparent processes.

Replace trusted committees with cryptographic verification of the source chain's state. Projects like Babylon and Nomic are pioneering Bitcoin light clients that verify block headers and SPV proofs.\n- First-Principles Security: Inherits Bitcoin's >$1T consensus security, not a smaller multisig's.\n- Verifiable Slashing: Invalid state transitions can be challenged and slashed on the destination chain.

Make trust expensive. Operators must stake substantial bonds (e.g., $1M+ per node) that are slashed for malicious behavior. Combine with Threshold Signature Schemes (TSS) to eliminate single points of key compromise, as used by THORChain.\n- Skin in the Game: Economic penalties align operator incentives with user safety.\n- Dynamic Sets: Bond size determines validator set, creating a permissionless security market.

Decouple security from liquidity. Users express an intent ("swap 1 BTC for ETH"), and a solver network competes to fulfill it via the most secure, cheapest path—leveraging native transfers, light clients, or existing bridges like Across. Inspired by UniswapX and CowSwap.\n- No Direct Custody: Solvers, not the protocol, manage bridging assets.\n- Best Execution: Routes atomically through the most secure available bridge at that moment.

A 5-of-9 multisig is not a consensus mechanism; it's a trusted cartel. The security model collapses to the weakest signer, creating a single point of failure for $1B+ in bridged assets.\n- Key Risk 1: Social engineering and key compromise.\n- Key Risk 2: Legal coercion of centralized operators.\n- Key Risk 3: No slashing for malicious collusion.

Validators must have skin in the game. Pure multisigs have zero economic stake backing their signatures, making fraud costless. The solution is a bonded validator set with cryptoeconomic slashing.\n- Key Benefit 1: Malicious actions lead to direct, automatic value loss.\n- Key Benefit 2: Aligns validator incentives with bridge security.\n- Key Benefit 3: Enables permissionless participation and rotation.

You cannot port Ethereum's optimistic or zk-rollup designs directly. Bitcoin's limited scripting requires a sovereign watchtower network to validate off-chain state and contest fraud. Think Babylon for staking or Citrea for zk-rollups, not Arbitrum.\n- Key Insight 1: Bitcoin is a data availability and settlement layer.\n- Key Insight 2: Fraud proofs must be executed by a separate, incentivized network.\n- Key Insight 3: The bridge's security is the watchtower's security.

Wrapped BTC (WBTC) proves demand but sets a dangerous precedent with centralized, verified custodians. The next standard must be non-custodial and credibly neutral. This requires proving reserve solvency on-chain, not via attestations.\n- Key Problem 1: Centralized minters are regulatory targets.\n- Key Problem 2: Users trade Bitcoin's security for an IOU.\n- Key Solution: Use Bitcoin itself as the collateral vault via advanced scripts.

A bridge is a liability. The endgame is native Bitcoin utility—using it as staking collateral or a data root without wrapping. Protocols like Babylon (staking) and Botanix (EVM sidechain) are pioneering this. The bridge should be a transparent, minimized component.\n- Key Shift 1: From 'lock-mint' bridges to proof-of-stake leverage.\n- Key Shift 2: From wrapped assets to verified Bitcoin state.\n- Key Shift 3: Minimize the trusted bridge footprint.

Decouple the components: Data Availability (Bitcoin), State Verification (Watchtowers), Settlement (Bitcoin), Execution (External VM). This mirrors Celestia's modular thesis. Use the bridge for sovereign message passing, not asset custody.\n- Key Design 1: Separate fraud proof and data availability layers.\n- Key Design 2: Use light clients for header verification.\n- Key Design 3: Bridge security = cost of corrupting the verification layer.