Why Bitcoin Bridges Are Not Permissionless

Custodial control is the default. Most Bitcoin bridges, like Wrapped Bitcoin (WBTC) and Multichain, require users to trust a centralized entity to hold the BTC. This reintroduces the exact counterparty risk that Bitcoin's proof-of-work consensus was designed to eliminate.

Federated models dominate. Even 'decentralized' bridges like Threshold Network (tBTC) or Ren Protocol operate with a permissioned set of signers. The validator set is not open for anyone to join, creating a permissioned bottleneck for a permissionless asset.

Security mismatch is structural. The 9-signer federation for tBTC or the multisig council for a cross-chain protocol like LayerZero cannot match the economic security of Bitcoin's 1 million+ mining nodes. This creates a fragile, attackable layer.

Evidence: The collapse of the Multichain bridge, which held over $1.5B in assets, demonstrated the catastrophic failure mode of opaque, permissioned validator control. The bridge's security was a function of corporate integrity, not cryptographic proof.

Bitcoin lacks programmability. Its scripting language is intentionally limited, preventing the deployment of smart contracts that could autonomously verify state or custody assets. This forces bridges like Wrapped Bitcoin (WBTC) and tBTC to rely on centralized, permissioned federations or multi-signature schemes for custody and minting logic.

Native verification is impossible. Permissionless bridges on Ethereum or Solana use light clients or fraud proofs to verify the origin chain's state. Bitcoin's consensus mechanism and block structure make this computationally prohibitive, forcing projects like Stacks or Rootstock to use federated notaries or merge-mining, which reintroduce trust.

The security model is inverted. A truly trustless bridge anchors its security to the underlying chain. On Bitcoin, the bridge's security becomes the weakest link—the federation or custodian. This creates a systemic risk vector, as seen in the collapse of cross-chain protocols that over-leveraged wrapped assets.

Evidence: The $15.5B WBTC market cap is secured by a 9-of-15 multisig controlled by BitGo and partners. The most 'decentralized' alternative, tBTC v2, still requires a 100-of-250 operator set for its threshold ECDSA scheme, a trust model orders of magnitude weaker than Bitcoin's 10,000+ nodes.

ZK-Rollups require a trusted operator. A ZK-rollup on Bitcoin needs a centralized proposer to batch and order transactions before generating a proof. This creates a single point of failure and censorship, unlike Ethereum rollups where decentralized sequencer sets are emerging.

BitVM is a two-party challenge system. It enables complex computation off-chain but requires at least one honest participant in a 1-of-N trust model. This is not permissionless; it's a federated security model that scales poorly with participant count.

The bridge remains the bottleneck. Whether via a ZK-rollup's operator or a BitVM federation, moving assets to another chain requires a trusted custodian or multisig. This is identical to the security model of existing bridges like Multichain or Wormhole before their native token governance.

Evidence: The only functional Bitcoin L2, Rootstock, uses a federated peg with a 15-of-30 multisig. This demonstrates the current practical limit for Bitcoin-native scaling without altering its base-layer consensus.