Bridge

The most common use case, allowing users to lock or burn tokens on a source chain and mint or unlock equivalent tokens on a destination chain. This enables liquidity movement between ecosystems.

• Wrapped Assets: Creates representations like Wrapped Bitcoin (WBTC) on Ethereum.
• Liquidity Provision: Supplies assets to DeFi protocols on other chains.
• Arbitrage: Exploits price differences for the same asset across different networks.

Bridges facilitate the secure transmission of arbitrary data and smart contract calls between blockchains. This is the foundation for advanced interoperability.

• Contract Calls: A dApp on Chain A can trigger a function on a contract deployed on Chain B.
• State Synchronization: Updates the state of an application (e.g., NFT ownership, game progress) across multiple chains.
• Governance: Allows voting on a governance proposal to execute actions on a separate chain.

Decentralized applications built natively to operate across multiple blockchains, using bridges as their communication layer.

• Decentralized Exchanges (DEXs): Aggregate liquidity from multiple chains for trading (e.g., Thorchain).
• Lending Protocols: Allow collateral to be posted on one chain to borrow assets on another.
• NFT Marketplaces: Enable minting, trading, and displaying NFTs across different ecosystems.

Bridges connect Layer 1 blockchains to their Layer 2 scaling solutions, facilitating the secure movement of assets and data to optimize for speed and cost.

• Deposit Bridges: Move assets from Ethereum Mainnet to an Optimistic Rollup (e.g., Arbitrum, Optimism) or a ZK-Rollup (e.g., zkSync).
• Withdrawal Bridges: Return assets from the L2 back to the L1, often involving a challenge period for fraud proofs.
• State Verification: Relays proof of L2 state transitions to the L1 for security.

Bridges are categorized by their underlying trust assumptions, which define their security and decentralization properties.

• Trusted (Custodial): Rely on a centralized federation or multi-sig to hold assets. Faster but introduces custodial risk.
• Trust-Minimized (Native): Use the underlying chains' consensus (e.g., light clients, validity proofs). Most secure but complex to build.
• Optimistic: Assume validity but include a fraud-proof challenge period. Balances security and efficiency.

Bridges are high-value targets and introduce unique risks that users and developers must evaluate.

• Smart Contract Risk: Bugs in bridge contracts can lead to catastrophic fund loss.
• Validator/Custodian Risk: Compromise of the bridge's validating entity.
• Liquidity Risk: Insufficient liquidity on the destination chain can cause failed transactions or slippage.
• Technology Risk: Consensus failures or network outages on connected chains.

The fundamental security model of a bridge dictates its risk profile. Custodial bridges rely on a central entity or multi-signature wallet to hold user funds, creating a single point of failure vulnerable to external hacking or internal collusion. Trust-minimized bridges use cryptographic proofs (like light clients or optimistic verification) to validate cross-chain transactions without a central custodian, but their complex smart contract logic can still contain bugs. The choice represents a trade-off between a known custodian risk and the novel risks of unaudited code.

The core logic governing asset locking, minting, and message verification is encoded in smart contracts, which are prime targets for exploits. Common vulnerabilities include:

• Logic flaws in cross-chain message validation.
• Reentrancy attacks on bridge contracts holding liquidity.
• Oracle manipulation feeding incorrect price or state data to the bridge.
• Upgradeability risks where admin keys are compromised, allowing malicious code deployment. High-profile bridge hacks, such as the Wormhole and Ronin Bridge incidents, often stem from these contract-level weaknesses.

Bridges relying on external validators or relayers are vulnerable to consensus-level attacks. In a Proof-of-Authority (PoA) or multi-sig model, an attacker must compromise a majority (or threshold) of the designated signers to forge fraudulent transactions. This can occur through:

• Key compromise of individual validators.
• Sybil attacks where an attacker controls multiple validator identities.
• Collusion among the validator set. The security of these bridges is only as strong as the honesty and operational security of their validator set.

Bridges must manage liquidity pools on both the source and destination chains. Key risks include:

• Liquidity fragmentation: A bridge may not have sufficient liquidity to process a large withdrawal, causing delays or failed transactions.
• Wrapped asset depeg: The value of a bridged asset (e.g., wBTC) depends on the bridge's solvency and proper 1:1 backing; a hack can cause the asset to trade at a discount.
• Centralized liquidity providers: If a bridge's liquidity is provided by a few large entities, their withdrawal can cripple the bridge's functionality.

This attack involves spoofing a message from the source chain to fraudulently mint assets on the destination chain. It can be executed by:

• Exploiting a light client to submit a fraudulent block header or Merkle proof.
• Compromising the relay network that transmits messages between chains.
• Launching a 51% attack on the source chain to reorganize history and double-spend locked assets. Mitigations include using fraud proofs, optimistic verification periods, and diverse, decentralized relayers.

Beyond protocol-level risks, users face significant threats at the application layer:

• Phishing websites mimicking legitimate bridge interfaces to steal private keys and approvals.
• Malicious token approvals where users inadvertently grant unlimited spending power to a malicious contract.
• Transaction malleability where parameters are altered mid-transaction.
• Frontend denial-of-service (DoS) attacks preventing access to the bridge interface during critical market movements. User education and rigorous interface security are essential defenses.