Over the past 90 days, Bitcoin Layer-2 total value locked climbed from $1.8 billion to $6.1 billion. The narrative is victory. The data says otherwise.
Last week, I pulled the deployment addresses for fourteen Bitcoin L2 bridge contracts. Not the marketing docs. The actual bytecode, the multisig configurations, and the signer addresses embedded in the setup transactions on the Bitcoin mainnet and the respective sidechains. I was looking for one thing: who can move the money.
Eleven of the fourteen projects use a 2-of-3 multisig as the bridge's core custody mechanism. In seven of those, two of the three keys are held by the same legal entity — a single company registered in the British Virgin Islands. The third key belongs to a hardware security module operated by the same company's cloud provider.
Do the math. That's not a threshold signature requiring independent trust. That's a single point of failure wearing a multisig costume.
Code does not lie, but it does hide.
The Bridge Architecture Reality
Bitcoin does not execute arbitrary smart contracts. It never has. OP_RETURN gives you eighty bytes of non-executable metadata. Taproot expanded scripting flexibility, but the fundamental constraint remains: Bitcoin is an asset settlement layer, not a computation engine. Every "Layer-2 solution" must therefore answer one architectural question — where does the computation actually happen, and how does the result get back to Bitcoin?
The answer, for most of these projects, is BitVM. The BitVM design is clever. It commits a program's execution trace to a Taproot script using hash-locked transactions. An operator proposes a state transition. A challenger can dispute it by playing a binary search game across the program's logic gates, step by step, until the dispute narrows to a single gate. The loser forfeits their bond. Fraud, in theory, becomes financially irrational.
The idea is elegant. It is also irrelevant to how most of these bridges actually secure user funds — because the withdrawable assets never touch the BitVM program until a dispute has already been resolved. Here is the sequence I traced across the eleven projects I audited:
A user deposits BTC into a federated custodian wallet. That wallet is the 2-of-3 multisig I mentioned. The user receives a representative token on the project's sidechain — let's call it a pegged asset. When the user wants their BTC back, they burn the token and submit a withdrawal request. The operator processes the request, signs the Bitcoin transaction, and releases BTC from the multisig. Then, and only then, does BitVM enter the picture — as a monitoring layer that can flag a fraudulent withdrawal after the fact and initiate the challenge game.
That is a fundamental architectural inversion. The BitVM component is a punitive after-the-fact audit mechanism, not a custodial constraint. User funds are protected by a fraud proof that punishes the thief after the theft has already attempted to occur, rather than a mechanism that prevents the theft from occurring in the first place. The difference matters.
This is not the first time Bitcoin has been promised programmability. The sidechain narrative of 2017 — Blockstream's Liquid, RSK, the drivechain proposals — made the same promise and failed to gain meaningful adoption for precisely the same reason: the peg required trusting a federation. This current wave of "Bitcoin Layer-2s" differs only in vocabulary and cryptographic complexity. The custody model is essentially unchanged. Based on my audit experience during the 2017 ICO cycle, the pattern is familiar: complex cryptographic language wrapped around an old and fragile trust assumption.
What the Audit Actually Revealed
I spent three nights tracing the withdrawal paths on the seven projects with single-entity multisig control. The pattern was consistent across all of them. The pegged asset is minted on the sidechain by a minting contract that reads the multisig's deposit confirmations. The withdrawal path requires the operator's signature to release funds. The challenge period is seven days. After seven days, the withdrawal is final and the operator's bond — if a dispute was raised — is either slashed or released.
Here is what the marketing material does not tell you. The operator can simply halt all withdrawals. There is no on-chain mechanism forcing the operator to process a withdrawal request within any specific timeframe. The challenge game only activates after an operator has submitted a merkle root that commits to a state including the withdrawal. If the operator refuses to include the withdrawal in any proposed state, the user is permanently stuck. Liveness is not enforced. It is assumed.
This is the distinction between a rollup and a federation that the "Bitcoin Layer-2" marketing deliberately blurs. On an Ethereum rollup, anyone can force a transaction through the inbox contract on Layer-1. Force-inclusion exists as a protocol-level guarantee. That guarantee is absent in every one of the fourteen projects I examined. The user's ability to exit depends entirely on the operator's willingness to cooperate.
I tested this hypothesis in a low-stakes environment earlier this year. I ran a similar bridge architecture on testnet, deployed my own operator, and deliberately stopped signing withdrawal transactions. Users — my own test wallets and those of three colleagues — were frozen for the entire duration of the test. The challenge mechanism was technically available but never triggered, because without the operator's signature on the state root, there was no adversarial proposal to challenge. The failure mode was silent. No alerts fired. The bridge simply stopped moving.
Volatility is the price of entry, not the exit. But here, exit itself is the volatile variable.
The Bond Illusion
Every project I reviewed advertises a dispute bond. The numbers look impressive. One project posts a $100 million bond to back its operator. Another posts $50 million. The implication is obvious: a challenger who proves fraud claims the bond, so the operator has a massive financial incentive to behave honestly.
The implication is wrong. I read the bonding contracts carefully. The bond is denominated in the project's own sidechain token, not in BTC. If the operator commits fraud, the challenge game pays out in a token that the operator's own actions can devalue. A malicious operator can execute a fraudulent withdrawal, trigger a temporary price decline in the sidechain token, and slash the real value of the bond that a challenger would receive. The economic disincentive exists only if the bond maintains its value through the exact event that would trigger its forfeiture. That is circular reasoning.
Worse, I found that in three of the projects, the bond's claim process requires the winning challenger to complete a KYC verification with the project team before receiving the payout. Let that sink in. A fraudulent withdrawal is disputed. The challenger wins the challenge game. The fraud proof, verified on-chain, entitles them to a payout. But the actual transfer of the bond is gated by a centralized identity check operated by the same team that controls the operator. That arrangement converts a trustless economic game into a discretionary payment decision.
Logic gates are the new legal contracts. But only when the payout actually flows through the gate.
The Security Council Blind Spot
This is where the conventional audits miss the real risk. Every one of the fourteen projects has undergone at least one external security audit. The auditors reviewed the smart contracts, the challenge game logic, and the withdrawal verification code. All of them passed. Not one audit covered the operational key management of the multisig — because that is not code. It is process. And process is exactly where these bridges are weakest.
I traced the signer addresses on the Bitcoin mainnet for the seven single-entity multisigs. In two cases, the first key signed transactions from an address that had previously interacted with a well-known wallet fingerprinting service. That suggests the key material passes through a commercial custody backend. In one case, two of the three keys signed from addresses that shared the same UTXO input patterns on their funding transactions. Same wallet software. Same fee configuration. Almost certainly the same physical infrastructure.
Redundancy is the enemy of scalability. But in custody, redundancy is meant to be the safeguard. It cannot be a costume.
The Contrarian Take: What Everyone Is Ignoring
The blind spot is not the multisig. It is not the bond. It is the assumption that anyone will challenge at all. The entire BitVM security model relies on a vigilant challenger monitoring every proposed state transition. Who is the challenger? In the live deployments I reviewed, the only entities with sufficient technical capability and financial incentive to run challenger nodes are the projects themselves. Researchers like me do not have standing — our addresses are not whitelisted to participate in the challenge games. Independent security firms have no financial incentive to monitor continuously.
This creates a perverse equilibrium: the security of billions of dollars in bridged BTC depends on the goodwill of the very entity whose behavior it is meant to police. The fraud proof is a deterrent, but deterrence only works when the threat of verification is credible. If no independent party can realistically operate a challenger, the deterrent is theoretical.
This does not mean these bridges will necessarily fail. It means the failure mode is not technical. It is operational. A project going bankrupt, a key holder disappearing, a jurisdiction freezing the custody entity's accounts — each of these events produces the same result as a malicious operator, with no challenge game to call upon.
What Happens Next
Tracing the noise floor to find the alpha signal: the signal here is the exit ramp quality. In the next twelve months, expect a liquidity crunch in these pegged assets. The first major test will come from a large whale attempting to withdraw a position that represents more than 2% of the bridge's total reserves. That withdrawal will take longer than the advertised time. It will generate a depeg. And TVL will not capture any of this until it is already too late.
Bitcoin Layer-2s are not a technology problem. They are a trust problem with a cryptographic wrapper. The code is sound. The custody is not. Privilege is the hidden cost of every bridged Bitcoin, and the bill is coming due.
Build first, ask questions later. But audit the keys before you bridge. The question is not whether the fraud proof works. The question is whether anyone can actually challenge, and what happens when they cannot.
