An overview of the core technical and operational elements that enable liquidity bridges to securely transfer assets across different blockchain networks.
LABS
What Are Liquidity Bridges and How Do They Work?
An architectural analysis of liquidity bridge mechanisms enabling asset movement across blockchain networks.
Chainscore © 2025
Fundamental Bridge Components
Lock-and-Mint Mechanism
Lock-and-Mint is the most common bridging method. When a user sends assets from the source chain, they are locked in a smart contract or custodian vault, and an equivalent wrapped representation is minted on the destination chain.
- Process: Assets are locked on Chain A, and a pegged token (e.g., wBTC) is minted on Chain B.
- Security: Relies on the security of the custodian or smart contract holding the original assets.
- Example: Wrapped Bitcoin (wBTC) on Ethereum, where real BTC is custodied, and ERC-20 wBTC is minted for DeFi use.
- User Impact: Enables Bitcoin holders to participate in Ethereum's DeFi ecosystem without selling their BTC.
Liquidity Pools
Liquidity pools are reserves of tokens on both sides of a bridge that facilitate instant swaps, often used in burn-and-mint or liquidity network models.
- Function: Users deposit tokens into a pool on the destination chain to provide liquidity for bridge users.
- Incentives: Liquidity providers earn fees from bridge transactions.
- Example: A bridge like Hop Protocol uses pools on Layer 2s (Optimism, Arbitrum) for fast transfers of stablecoins.
- Why it matters: Enables faster, cheaper transfers without waiting for finality periods, crucial for cross-chain DeFi.
Relayers & Oracles
Relayers and oracles are off-chain entities or networks that monitor blockchain events and transmit data or proofs between chains to trigger bridge operations.
- Role: They detect deposits on the source chain and submit proof to the destination chain's smart contract.
- Decentralization: Can be a network of nodes to avoid single points of failure.
- Example: Chainlink's Cross-Chain Interoperability Protocol (CCIP) uses decentralized oracle networks for secure message passing.
- User Benefit: Ensures bridge actions are executed accurately and securely, though their trust model is critical.
Smart Contracts
Smart contracts are the autonomous programs deployed on each connected blockchain that govern the logic, security, and execution of the bridge.
- Core Logic: Handle user deposits, asset locking/minting, proof verification, and fund releases.
- Upgradability: Some use proxy patterns for updates, which can introduce centralization risks.
- Example: The Polygon PoS bridge uses a set of contracts on Ethereum and Polygon to manage state sync and asset transfers.
- Importance: They are the immutable rulebook; any bug or vulnerability can lead to catastrophic fund loss, as seen in past hacks.
Consensus & Validators
Consensus mechanisms and validator sets are used in more decentralized bridges to achieve agreement on the state of transactions across chains, often through multi-signature schemes or Byzantine Fault Tolerance.
- Function: A committee of validators signs off on cross-chain transactions after verifying proofs.
- Security Model: Security scales with the number and honesty of validators; attacks can occur if a threshold is compromised.
- Example: The Axelar network uses a proof-of-stake validator set to secure general message passing between chains.
- For Users: Determines the trust assumption—whether you trust a few entities or a decentralized network.
Wrapped Assets
Wrapped assets are tokenized representations of a native asset from another chain, created by bridges to make assets compatible with the destination chain's ecosystem.
- Creation: Minted via lock-and-mint or via a liquidity pool model (burn-and-mint).
- Standards: Typically follow the destination chain's token standard (e.g., ERC-20 on Ethereum, SPL on Solana).
- Example: Wrapped ETH (wETH) on Avalanche, allowing Ethereum users to leverage Avalanche DeFi with their ETH.
- Significance: They are the fundamental building blocks for cross-chain composability, enabling assets to flow into new applications.
How a Bridge Transaction Executes
A step-by-step breakdown of the cross-chain asset transfer process using a liquidity bridge.
1
Initiation and Locking on Source Chain
The user initiates the transfer by locking their assets in a smart contract on the origin blockchain.
Detailed Instructions
The process begins when a user initiates a transfer on the source chain, such as Ethereum. The user must approve and send their assets (e.g., 1 ETH) to a designated, audited bridge smart contract (e.g., 0x1234...abcd on Ethereum). This contract acts as a custodian, locking or burning the original tokens to prevent double-spending. The user specifies the destination chain (e.g., Avalanche) and the recipient address.
- Sub-step 1: Connect Wallet: The user connects a Web3 wallet (like MetaMask) to the bridge's front-end interface.
- Sub-step 2: Approve Token Spend: The user signs a transaction to grant the bridge contract permission to spend their tokens, paying the necessary gas fee.
- Sub-step 3: Lock Assets: The user signs the main bridge transaction, sending the assets to the contract. A cryptographic proof of this deposit is generated.
Tip: Always verify the official contract address from the bridge's documentation to avoid scams. Transaction details, like the
txHash, should be saved for tracking.
2
Event Emission and Proof Generation
The source chain contract emits a verifiable event, and relayers or validators generate a cryptographic proof.
Detailed Instructions
Once the locking transaction is confirmed on the source chain, the bridge's smart contract emits a standardized event log. This log contains crucial data like the sender's address, amount, destination chain ID, and recipient. This event is observed by network participants known as relayers or validators. Their role is to construct a cryptographic proof—often a Merkle proof—that attests to the validity and inclusion of the deposit event in the source chain's state.
- Sub-step 1: Monitor Events: Relayers continuously monitor the bridge contract for
DepositorLockevents using tools like The Graph or direct node queries. - Sub-step 2: Generate Proof: For a Merkle-based bridge, the relayer generates a proof that the event is part of a block's Merkle Patricia Trie. The proof might be formatted as a JSON object containing sibling hashes.
- Sub-step 3: Relay Data: The relayer submits the raw event data and the generated proof to the destination chain, either directly or via an off-chain service.
Tip: The security model depends heavily on the honesty and decentralization of these validators. Some bridges use optimistic schemes with challenge periods.
3
Verification on Destination Chain
A smart contract on the destination chain validates the submitted proof and authorizes the minting of assets.
Detailed Instructions
On the destination chain (e.g., Avalanche), a corresponding bridge contract receives the proof and event data from the relayer. This contract contains verification logic—such as a light client or a signature from a trusted validator set—to check the proof's validity. This step ensures the locked event on the source chain is legitimate and final. Upon successful verification, the contract authorizes the minting of a representative token (a wrapped asset like wETH) on the destination chain.
- Sub-step 1: Proof Submission: The relayer calls a function like
verifyAndMint(bytes calldata _proof, bytes calldata _eventData)on the destination contract. - Sub-step 2: State Verification: The contract checks if the source block is finalized and verifies the Merkle proof against a stored block header root. For example:
soliditybool verified = merkleProof.verify(rootHash, leafHash); require(verified, "Invalid proof");
- Sub-step 3: Prevent Replay Attacks: The contract marks the unique event identifier (e.g.,
sourceTxHash) as processed to prevent the same proof from being used twice.
Tip: The gas cost for verification is typically paid by the relayer and may be reimbursed from bridge fees included in the initial transaction.
4
Asset Minting and Final Delivery
The wrapped tokens are minted to the user's specified address, completing the cross-chain transfer.
Detailed Instructions
After verification, the final step is the minting and distribution of assets. The destination chain's bridge contract mints an equivalent amount of the bridged token (e.g., 1 wETH on Avalanche) to the user's specified recipient address. If the bridge uses a liquidity pool model instead of minting, an equivalent amount of the native asset is withdrawn from a pool and sent to the user. This step updates the token's total supply on the destination chain and completes the user's balance transfer.
- Sub-step 1: Mint Tokens: The contract calls its internal
_mint(recipientAddress, amount)function for the wrapped token contract. - Sub-step 2: Emit Completion Event: The contract emits a
TransferCompletedevent, which front-ends can track to update UI status. - Sub-step 3: User Receives Assets: The user's wallet on the destination chain now reflects the new balance. The user can then interact with dApps on this chain using the bridged assets.
Tip: The entire process can take from a few minutes to several hours, depending on the source chain's finality and bridge design. Always check the bridge's explorer for transaction status.
Bridge Architecture Comparison
Comparison of technical architectures for cross-chain liquidity bridges.
| Architecture Type | Security Model | Finality Time | Example Bridge | Native Token Required |
|---|---|---|---|---|
Lock & Mint (Validated) | Trusted Validator Set | ~3-5 minutes | Multichain (formerly Anyswap) | Yes (MULTI) |
Liquidity Pool (Atomic Swap) | Decentralized (AMM-based) | ~2-3 minutes | Hop Protocol | No |
Light Client / Relayer | Cryptoeconomic (Fraud Proofs) | ~10-20 minutes | Nomad | Yes (NOMAD) |
Canonical Token (Wrapped) | Single Chain Security | Instant (on destination) | Polygon PoS Bridge | No |
Optimistic Verification | Challenge Period (7 days) | ~7 days + 10 min | Across Protocol | Yes (ACX) |
Hybrid (Liquidity + Mint) | Mixed (Validators + Liquidity) | ~5-10 minutes | Synapse Protocol | Yes (SYN) |
ZK Light Client | Zero-Knowledge Proofs | ~15-30 minutes | zkBridge (Polyhedra) | Yes (ZK) |
Technical Implementation Patterns
Understanding the Basics
A liquidity bridge is a protocol that allows you to move tokens from one blockchain to another. Think of it as a secure ferry that locks your tokens on the origin chain and mints equivalent, 'wrapped' tokens on the destination chain. This process is called locking and minting.
How It Works in Simple Steps
- Locking: You send your tokens (e.g., ETH on Ethereum) to a smart contract on the original chain. The bridge holds them securely in a vault.
- Minting: The bridge's system validates the transaction and then creates or 'mints' a corresponding token (e.g., WETH) on the target chain (like Polygon).
- Burning: To move tokens back, you burn the wrapped tokens on the destination chain, which signals the original chain's contract to release your original assets.
Real-World Example
Popular bridges like Polygon PoS Bridge and Arbitrum Bridge use this model. When you bridge USDC from Ethereum to Polygon, you lock USDC on Ethereum and receive USDC.e (bridged USDC) on Polygon to use in DeFi apps like QuickSwap.
Security Models and Attack Vectors
An overview of the security frameworks and common vulnerabilities associated with cross-chain liquidity bridges, which are critical infrastructure for transferring assets between blockchains.
Lock-and-Mint Bridges
Lock-and-Mint is the most common bridge model. It locks assets on the source chain and mints a wrapped representation on the destination chain.
- Asset Custody: Relies on a custodian or smart contract to securely hold the locked assets.
- Example: The Wrapped Bitcoin (WBTC) on Ethereum uses a multi-sig custodian.
- Attack Vector: A compromise of the custodian or minting authority can lead to total loss of funds, as seen in the Nomad Bridge hack where faulty logic allowed unauthorized minting.
Liquidity Pool Bridges
Liquidity Pool Bridges use pools of assets on both chains and atomic swaps to facilitate transfers without a central custodian.
- Decentralized Model: Relies on liquidity providers and automated market makers (AMMs).
- Example: ThorChain enables cross-chain swaps between native assets like Bitcoin and Ethereum.
- Attack Vector: These are vulnerable to economic attacks like arbitrage exploits, flash loan attacks to manipulate pool prices, and bugs in the AMM smart contract logic.
Multisig & MPC Validators
Multisig and MPC (Multi-Party Computation) are consensus mechanisms where a committee of validators signs off on bridge transactions.
- Security Assumption: Security depends on the honesty of a majority of validators.
- Example: The Polygon PoS bridge uses a set of Heimdall validators with a 2/3 majority threshold.
- Attack Vector: A validator collusion or compromise can approve fraudulent withdrawals. This was a factor in the Wormhole hack, where attackers forged guardian signatures.
Fraud Proofs & Optimistic Models
Optimistic Bridges assume transactions are valid but include a challenge period where fraud proofs can be submitted.
- Delayed Finality: Introduces a security delay (e.g., 7 days) to allow monitoring.
- Example: Optimism's native bridge to Ethereum uses this model for L2 withdrawals.
- Attack Vector: The primary risk is a liveness failure—if no one is monitoring or able to submit a proof in time, a fraudulent transaction can finalize. This shifts security to vigilant users.
Zero-Knowledge Proof Bridges
ZK Bridges use cryptographic zero-knowledge proofs to verify the state of another chain without trusting intermediaries.
- Trust Minimization: Provides strong cryptographic guarantees of transaction validity.
- Example: zkBridge projects use succinct proofs to verify Ethereum state on other chains.
- Attack Vector: While highly secure, risks include bugs in the complex cryptographic circuit code (trusted setup issues) and potential data availability problems if the proof input data is withheld.
Common Attack Vectors
Beyond model-specific flaws, bridges face several universal attack vectors that exploit their complex, interconnected nature.
- Smart Contract Vulnerabilities: Bugs in bridge contracts are a prime target, as in the $325M Wormhole exploit.
- Oracle Manipulation: Feeding incorrect price or state data to the bridge can drain liquidity pools.
- Supply Chain Attacks: Compromising a widely used software library or developer tool can affect multiple bridges simultaneously, leading to systemic risk.
SECTION-FAQ
Technical Questions About Bridge Operations
Further Reading and Reference Implementations
Ready to Start Building?
Let's bring your Web3 vision to life.
From concept to deployment, ChainScore helps you architect, build, and scale secure blockchain solutions.