Between 2021 and 2024, cross-chain bridges lost over $2.5 billion to exploits. Ronin, Wormhole, Nomad, Harmony — the list keeps growing. Every post-mortem names a different bug. A signature verification error here, an infinite mint there. But underneath the surface-level explanations, there's a pattern.
The pattern is trust. Specifically, the wrong kind of trust placed in the wrong place.
How most bridges work — and why it creates risk
The basic model for most bridges is straightforward: you lock tokens on Chain A, and a relayer or validator set confirms that lock and mints corresponding tokens on Chain B. Simple in theory. The security entirely depends on what happens in the middle — the verification step.
Most bridges use one of three models for that verification:
- Trusted relayers: A set of known entities confirm the transaction. Security equals how much you trust those relayers.
- Multi-sig validators: A threshold of validators sign off. Security equals how many validators are needed and how hard their keys are to compromise.
- Light client verification: The destination chain verifies a proof of the source chain's state. Security equals the cryptographic strength of the proof.
Most of the bridges that got hacked used the first two models. The Ronin bridge used 9 validators with a 5-of-9 threshold. Attackers compromised 5 private keys. Game over. $625 million gone.
The structural flaw
When trust is concentrated — in a relayer set, in a multisig, in any off-chain entity — you have a target. A well-resourced attacker can work toward compromising that target over time. The larger the TVL in the bridge, the more valuable the target becomes. You're essentially creating a vault and hanging a sign on it.
The fundamental problem isn't the specific bug in each exploit. It's that the security model concentrated trust in a small number of controllable entities. That's a design choice, and it's one that didn't survive contact with a motivated adversary.
Light client verification avoids this problem in principle. You don't trust anyone — you verify the source chain's state directly using cryptographic proofs. There's no human or entity to compromise. The security derives from math, not from who holds the keys.
Why most bridges didn't use light clients
Simple: it's expensive. Verifying a full light client proof on-chain requires significant computation, which costs gas. In 2021, this wasn't economically viable for most bridges. It was cheaper — and faster to ship — to use a trusted relayer model.
That tradeoff made sense when bridge TVL was small. It stopped making sense once bridges were holding billions in assets. The economic incentive to attack a relayer-based bridge with $1B TVL is enormous. The economic incentive to attack a cryptographic proof is zero — you can't attack math.
Zero-knowledge proofs change the equation
ZK proofs have made light client verification practical. The computational cost of verifying a ZK proof on-chain is substantially lower than verifying a full light client header chain. More importantly, ZK proofs can be generated off-chain and verified on-chain cheaply — the work is done off-chain, and the chain only sees the proof.
This is the model the Defimec bridge uses. Every transfer generates a ZK proof of the source transaction state. The destination chain verifies the proof before releasing funds. No relayer holds assets at any point. No validator key can be compromised to drain the bridge.
The remaining risks
Switching to ZK proofs doesn't eliminate all risk. It eliminates the trust concentration risk. Other categories remain:
| Risk Category | Description | Mitigation |
|---|---|---|
| Smart contract bugs | Logic errors in the bridge contracts themselves | Formal verification + independent audits |
| ZK circuit bugs | Errors in the proof generation circuit | Separate audit of the circuit logic |
| Chain reorganizations | Source chain reorg that invalidates a confirmed transaction | Finality thresholds before proof generation |
| Oracle manipulation | Manipulated price or state feeds used in bridge logic | Decentralized oracles with outlier rejection |
We address the first two with a combination of formal verification using Lean 4 for the core contract logic and circuit audits from two independent security firms. The third we handle by waiting for sufficient block confirmations (6 on Ethereum, chain-specific elsewhere) before generating proofs. The fourth we mitigate by not relying on price oracles in the critical transfer path.
What to look for when evaluating a bridge
If you're evaluating bridge infrastructure, these are the questions that actually distinguish safe from unsafe designs:
- Does the bridge rely on trusted relayers or validators at any point in the transfer flow?
- Are the smart contracts formally verified, not just audited?
- Are audit reports publicly available? When were they last conducted?
- What is the finality threshold before funds are released on the destination chain?
- What happens to in-flight transactions if the bridge goes offline?
If you can't get clear answers to all five, that's informative.
The bridge exploit era isn't over — there will be more hacks of vulnerable bridges. The designs that avoided them share a common characteristic: they don't ask you to trust anyone. They give you something verifiable instead.
