When you bridge tokens from Ethereum to BNB Chain or from Arbitrum to Optimism, multiple security layers operate simultaneously to ensure the safety of your transaction. This post explains the verification process step by step, the corresponding security mechanisms, and the protocols that implement them in practice.
Part 1: The Three Verification Steps of a Bridge Transaction
Every bridge transaction must answer three fundamental questions:
- Step 1 – Prove DATA: Does the lock/burn transaction exist on the source chain?
- Step 2 – Prove CONSENSUS: Was the block containing that transaction accepted by the network consensus?
- Step 3 – EXECUTE ACTION: After verification, execute mint/unlock on the destination chain
The reason why all three steps are required:
- Step 1 proves the transaction exists but does not prove the block is valid.
- Step 2 proves the block was accepted by the network.
- Step 3 executes only after both are verified.
Step 1 – Proving Transaction Existence (Merkle Proof)
Instead of transmitting the entire block data to the destination chain, bridges use Merkle Trees to prove that a transaction exists within a block using only a small amount of data.
How it works:
- A block header contains a value called the Merkle Root — this is the aggregated “fingerprint” of all transactions within the block.
- To prove that transaction X exists, only a small array of hashes (called a Merkle Proof) needs to be provided.
- The destination chain performs the calculation and verification:
hash(hash(X + sibling1) + sibling2) == Root?
If true → the transaction is valid. - Efficiency: A block with 10,000 transactions typically requires only about 13 hashes to prove inclusion — giving a cost of O(log N).
Important limitation:
A Merkle Proof only proves that “the transaction exists in a block with Root R.”
It does not prove that the block itself is valid or accepted by the network.
That is why Step 2 is mandatory. Without it, an attacker could create a fake block with a valid Merkle Root and mint unlimited tokens.
Step 2 – Verifying Consensus
This is the most critical step and the point where bridge protocols differ significantly.
The key question is: Who tells the destination chain that “the block with Merkle Root R has been accepted by the source chain’s network consensus”?
| Method | Mechanism | Trust Assumption | Trustless |
| ZK Light Client | Validator signatures proven via ZK proofs | Mathematics (soundness) | ✅ |
| IBC Light Client | Chains run each other’s light client | Security of both chains | ✅ |
| Oracle Network | Oracle nodes agree on block headers | Majority of oracle nodes honest | ❌ |
| Multisig/MPC | M-of-N validators sign messages | Validators remain honest | ❌ |
| Optimistic | Assume valid, watchers can dispute | At least one honest watcher online | ❌ |
Step 3 – Execution via Smart Contract
Once Steps 1 and 2 are verified, the smart contract on the destination chain executes the action.
Common models include:
- Lock & Mint: Tokens are locked on the source chain and wrapped tokens are minted on the destination chain. Risk: centralized vault becomes a target for attacks.
- Burn & Mint: Tokens are burned on the source chain and newly minted on the destination chain. Total supply remains unchanged and there is no central vault risk (OFT model).
- Lock & Unlock: Liquidity already exists on both chains and tokens are unlocked accordingly (Liquidity Network model).
Part 2 – Security Mechanisms in Detail
ZK Light Client
A ZK Light Client uses mathematical proofs to verify that the block header of the source chain is valid and has been signed by validators. The verifier contract on the destination chain only needs to verify the proof, without relying on any third party.
- Trust assumption: ZK proof soundness & Source chain consensus
- Weakness: Circuit bugs may cause irreversible damage; not yet supported by all chains
Oracle Network
A decentralized oracle network reaches consensus on the state of the source chain and provides that information to the bridge. It is not fully trustless, but it has been battle-tested with billions of dollars in TVL.
- Trust assumption: Majority of oracle nodes remain honest.
- Weakness: Still relies on human-operated infrastructure.
Multisig / MPC
M-of-N validators sign and confirm messages. It’s the simplest approach to implement, but historically it has also been the most common attack vector.
- Trust assumption: The M-of-N validators remain honest and their keys are not compromised.
- Weakness: The Ronin Bridge lost $625M (5 out of 9 validator keys were compromised); Wormhole lost $320M due to a smart contract bug.
Optimistic Verification
Assume every message is valid by default. During a challenge period, watchers can submit a fraud proof to dispute it. If no dispute is raised, the message is accepted.
- Trust assumption: At least one honest watcher must remain online throughout the challenge period.
- Weakness: Relies on liveness assumption; Nomad lost $190M due to a logic bug in the fraud proof mechanism.
IBC – Cosmos Standard
Each chain in the Cosmos ecosystem runs a light client of its counterpart chains and verifies block headers directly. This approach requires no third party and is fully trustless, but it only works with chains that have fast finality.
- Trust assumption: The security relies on the two participating chains themselves, with no need for a third-party validator set.
- Weakness: It only supports Tendermint/CometBFT-based chains and does not work natively with Ethereum or Bitcoin.
Liquidity Network – The fastest user experience
The destination chain releases funds to the user immediately, and then waits for the official bridge to settle and reimburse the liquidity provider. This is why these bridges are extremely fast.
- Trust assumption: The smart contract functions correctly and the liquidity providers (LPs) have sufficient liquidity.
- Weakness: Exposure to LP risk, fragmented liquidity, and slippage when transaction volume is large.
Part 3 – Real Bridge Protocols
CCIP (Chainlink)
CCIP is Chainlink’s bridge protocol, which uses the Chainlink DON (Decentralized Oracle Network) combined with an independent Risk Management Network to monitor and detect anomalies.
- Classification: External Verification — Oracle Network
- Security Layer 2: Chainlink DON + Independent Risk Management Network
- Token Model: Lock & Mint or Burn & Mint (depending on configuration)
- Trust Assumption: Majority of Chainlink node operators are honest
- Speed: ~15–20 minutes (waiting for Ethereum finality)
- Permissionless: No — requires Chainlink support
- Best suited for: Enterprise use cases, large TVL DeFi protocols, traditional financial institutions
- Real-world examples: Aave, Synthetix, SWIFT proof of concept
LayerZero & OFT (Omnichain Fungible Token)
OFT is a token standard developed by LayerZero. Bridging OFT tokens uses LayerZero’s architecture with independent Oracle and Relayer components. Both parties would need to collude in order to carry out an attack, which significantly increases the difficulty compared to a simple multisig-based model.
- Classification: External Verification — Oracle + Relayer
- Security Layer 2: Ultra Light Node: Oracle sends block headers, Relayer submits proofs separately
- Token Model: Burn & Mint (no centralized vault — a major advantage)
- Trust Assumption: Oracle and Relayer do not collude with each other
- Permissionless: Yes — developers can deploy the OFT contract themselves
- Best suited for: Tokens that want to be native omnichain without requiring wrapped tokens
- Real-world examples: JOE (Trader Joe), STG (Stargate), many DeFi tokens
Hyperlane
Hyperlane is a bridge framework with a unique modular architecture that completely separates message transmission from the security mechanism. Developers can choose and deploy an Interchain Security Module (ISM) that best fits their security requirements.
| Selected ISM | Security Type | Trust Assumption |
| Multisig ISM (default) | External Verification | Validator set is honest |
| Optimistic ISM | Native Verification | At least one watcher is online |
| ZK ISM | Native Verification | Soundness of the ZK proof |
| Aggregation ISM | Combination of multiple ISMs | Depends on configuration |
- Strongest Advantage: Fully permissionless — anyone can deploy it on a new chain
- Main Risk: Security depends entirely on the ISM chosen by the deployer
- Speed: Depends on the ISM — ranging from a few minutes to several hours
- Best suited for: New app chains or teams that want full control over the security model
- Real-world examples: Eclipse, Neutron, Ancient8
ZK Bridge (Succinct, zkBridge, Polyhedra)
A ZK Bridge directly proves the consensus of the source chain using a ZK proof. In theory, this is the most secure approach, as it does not require trusting any third party.
- Classification: Native Verification — ZK Light Client
- Security Layer 2: ZK proof of validator signatures (BLS aggregation for Ethereum)
- Token Model: Depends on design — commonly Lock & Mint
- Trust Assumption: Soundness of the ZK system — purely mathematical
- Speed: 15 minutes – 1 hour (bottleneck: chain finality + proving time)
- Permissionless? – Yes (in theory)
- Best suited for: Use cases requiring maximum security and willing to accept higher latency
- Current status: Rapidly developing; hardware acceleration is reducing proving time
Conclusion
There is no perfect solution. Each approach is a trade-off between security, speed, cost, and technical complexity.
Key takeaways:
- Merkle Tree solves the “prove data” problem — proving that a transaction exists within a block.
- ZK / Oracle / IBC solve the “prove consensus” problem — proving that the block itself has been validated and accepted by the network.
- Both layers are mandatory. Missing either one creates a serious security vulnerability.
- OFT (Burn & Mint) removes the risk of a centralized vault, but it still depends on the Oracle + Relayer architecture.
- Hyperlane is the most flexible: the same framework can have different security models depending on the selected ISM.
- ZK Bridges represent the future, but they are currently slow and expensive, though improvements are happening rapidly.
The golden rule when evaluating a bridge:
Ask three questions:
- Who provides the block header?
- Do you have to trust them?
- If they collude or get hacked, how much can you lose?
The answers to these questions will reveal how secure the bridge actually is.
