What does a bridge actually trust?
OpenZeppelin's review of TxFlow's Bridge2 contract, a custodial USDC bridge between Arbitrum and TxFlow L1, is the clearest statement of the problem we have reported. The audit covered two Solidity files and found eleven issues, none critical or high. The report then set out what the design assumes rather than proves: that no more than a third of validator power is compromised; that lockers can pause within the dispute window before finalisation; that separating hot and cold wallets allows recovery from a hot key compromise; that the L1 manages the validator set correctly; and that the Arbitrum sequencer stays honest.
One low-severity finding, a validator count overflow, was closed as an L1 trust assumption rather than a code responsibility. That is a defensible call, and it shows what a narrow scope means: the contracts were sound against their assumptions, and whether the assumptions hold was a question the audit was not asked.
Which defects do bridge audits keep finding?
| Finding | Where | Why it matters on a bridge |
|---|---|---|
| Validator-set update without replay protection; each resubmission reset the dispute period | TxFlow Bridge2, medium | Finality can be pushed back indefinitely without forging anything |
| Deposits accepted while paused; permit front-running on deposits | TxFlow Bridge2, low | Controls that look closed are not |
| Compliance freeze bypassed through cross-chain mints, burns and allowances granted before the freeze | StableGold, high | A freeze on one path is a gate, not a freeze |
| Unverified link between coreIndex and token; a compromised OApp able to inflate transfer amounts | Across V5, low — four of seven lows still open | Unlikely paths are the ones an attacker gets to choose |
| Signed transaction summary binding neither expiration nor reference block | Miden, medium | Reads as academic until someone builds a bridge on top |
Why does severity understate bridge risk?
Severity ratings describe likelihood as much as impact, and on a bridge the conditions that make an unlikely path likely are exactly what an attacker controls. The Across V5 review is instructive for what stayed open: of nineteen issues, twelve were closed and one partially, two raised by the client itself remained unresolved, and four of seven low-severity findings were still open. The low-severity list included an unverified link between a core index and a token that could misdirect funds.
Denial-of-finality bugs are underweighted for a related reason. In the TxFlow case a replayed validator-set update moved no money; it only reset the dispute period, again and again. Nothing is stolen, so nothing looks urgent, yet a bridge that cannot finalise is a bridge whose users cannot get their funds out.
What does the word bridge mean in a central bank design?
The same word covers very different trust models. In the ECB's options for bringing central bank money on chain, bridging or synchronisation means reserves stay in the existing real-time gross settlement system and an interoperability layer links it to DLT platforms by hash and trigger. The Eurosystem's Pontes project, launched on 21 September 2026, combines a bridge to TARGET2 with a Eurosystem DLT platform. Here the bridge connects to an operator everyone already trusts; in crypto, the bridge is often the operator.
What happens to bridges after a theft?
They become the exit. In the first three hours after the $387 million theft from Bitget on 24 September, the funds left in 23 transfers onto four chains: 49.7% to Ethereum, 40.8% to XRP, 7.6% to Zcash and 1.8% to Tron. The stolen XRP went through a cross-chain liquidity protocol and came out as bitcoin. Such protocols link no accounts across the two sides, but every swap leaves a record, and the work is matching deposits to payouts. Chainalysis describes compressing more than 20 hours of manual bridge reconciliation to under 10 minutes with automation.
What should you check before using or integrating a bridge?
- The list of trust assumptions, read as the risk register rather than as a footnote.
- Who can pause, and whether they can act inside the dispute window.
- Replay protection on every governance and validator-set message, not only on transfers.
- Whether freezes and compliance checks also apply to cross-chain mints and burns.
- How many findings remain open, and which of them the team raised itself.
- What each signature commits to: expiry, chain and reference block.
Questions
- Does a clean audit mean a bridge is safe?
- No. A bridge audit checks the code against stated assumptions. In the TxFlow review the contracts were sound, but the design assumed that no more than a third of validator power is compromised and that the Arbitrum sequencer stays honest — conditions the audit was not asked to test.
- What is a denial-of-finality bug?
- A flaw that delays or blocks a bridge from finalising transfers without stealing anything. In one reviewed bridge, a validator-set update could be resubmitted and each resubmission reset the dispute period, pushing finality back indefinitely.
- Why are bridges used to launder stolen funds?
- Cross-chain liquidity protocols let someone deposit one asset on one chain and receive another elsewhere with no account linking the two sides. Each swap still leaves a record, so tracing becomes a reconciliation problem, which Chainalysis automated after the Bitget theft.