Non-Custodial Bridge

A non-custodial bridge does not hold user funds. Instead, it relies on cryptographic proofs or decentralized networks to validate and relay transactions. Key security models include:

• Light Client & Relays: Light clients verify block headers from the source chain on the destination chain.
• Optimistic Verification: A challenge period allows watchers to dispute invalid state transitions.
• Multi-Party Computation (MPC): A decentralized network of signers collectively authorizes transfers, with no single party holding the full key. This contrasts with custodial bridges, where users must trust a central entity with their assets.

This feature enables peer-to-peer, non-custodial swaps without intermediaries. It uses Hashed Timelock Contracts (HTLCs) on both chains:

• A user locks Asset A on Chain 1 with a cryptographic secret hash.
• A counterparty locks Asset B on Chain 2, which can only be claimed by revealing the same secret.
• The original user reveals the secret to claim Asset B, which simultaneously allows the counterparty to claim Asset A. If the swap isn't completed within a set timeframe, funds are automatically refunded. This mechanism is foundational for decentralized exchange (DEX) bridges.

Instead of locking assets in a central vault, non-custodial bridges often use decentralized liquidity pools. Common models are:

• Lock & Mint: Assets are locked on the source chain, and a wrapped representation is minted on the destination chain (e.g., wBTC).
• Liquidity Pool (LP) Based: Users swap assets directly via pools on both chains using protocols like Thorchain or Stargate. Liquidity is provided by decentralized LPs, and bridges route users to the best pool.
• Atomic Swap P2P: As described in the HTLC card, this model requires no pooled liquidity at all, just a willing counterparty.

The validation of cross-chain messages is performed by a permissionless or permissioned network of nodes, not a single operator. Examples include:

• Relayer Networks: Off-chain relayers monitor events and submit Merkle proofs (e.g., Axelar, Wormhole with Guardian network).
• ZK Light Clients: Zero-knowledge proofs verify the state of one chain on another with minimal computational overhead (an emerging design).
• Economic Security: Validators or relayers are economically incentivized to act honestly and are slashed for malicious behavior, aligning security with the underlying blockchain's consensus.

The defining user experience feature is that users never cede control of their private keys. The bridge is a messaging protocol, not a bank. This means:

• Users sign transactions only on their origin chain to initiate a transfer.
• The bridge protocol creates a verifiable claim or proof for the destination chain.
• The user (or their wallet) presents this proof on the destination chain to receive funds. Failure of the bridge protocol does not necessarily mean loss of funds, as they may remain recoverable on the source chain, depending on the implementation.

Modern non-custodial bridges are evolving into generic message passing systems, not just asset bridges. They enable:

• Arbitrary Data Transfer: Smart contract calls, governance votes, or NFT metadata can be sent cross-chain.
• Cross-Chain DeFi Composability: A protocol on Ethereum can trigger a liquidation or harvest rewards on Avalanche via a bridge message.
• Unified Development Experience: SDKs (like Axelar's GMP or LayerZero's Endpoint) allow developers to build native cross-chain applications where logic is executed on the optimal chain.

Bridges must reliably attest to events on one chain for another. The security model of this validation is critical:

• Light Clients & Relays: Use cryptographic proofs (e.g., Merkle proofs) but rely on the security of the source chain's consensus.
• Multi-Party Computation (MPC) / Multi-Sig: A committee of signers must reach a threshold to approve transactions. This concentrates risk on the committee's honesty and key management.
• Fraud Proofs / Optimistic Models: Introduce a challenge period where transactions can be disputed, relying on watchdogs to be active and properly incentivized.

Attackers may exploit the bridge's tokenomics and incentive structures:

• Liquidity Pool Manipulation: An attacker could drain a bridge's liquidity pool on the destination chain through a flash loan or oracle manipulation, making wrapped assets worthless.
• Validator Bribing: In MPC or proof-of-stake validator models, an attacker could bribe or coerce enough participants to sign a fraudulent transaction, a risk known as bribery or grinding attacks.
• Race Conditions: Competing transactions (e.g., during a governance attack) can create arbitrage opportunities or leave funds in an undefined state.

Many "non-custodial" bridges retain admin keys or multi-sig controls for emergency upgrades or pauses. This creates a centralization vector:

• A malicious or compromised admin could upgrade the contract to steal funds.
• The threat of a governance takeover could force a malicious upgrade.
• Time-locked upgrades with transparent governance reduce but do not eliminate this risk. Users must audit not just the current code, but the upgrade process and the entities controlling it.

Bridges must correctly interpret and relay data (e.g., token amounts, recipient addresses) between heterogeneous chains. Risks include:

• Oracle Manipulation: If a bridge uses an oracle for price feeds or state verification, compromising that oracle can lead to incorrect settlements.
• Calldata Spoofing: An attacker could craft a transaction that is valid on the source chain but has a maliciously different interpretation on the destination chain.
• Replay Attacks: A valid message from the source chain could be replayed multiple times on the destination chain if nonces or other replay protection fails.

Bridge operations can fail due to underlying blockchain conditions, leading to financial loss or stuck funds:

• Destination Chain Congestion: A user's transaction to claim bridged assets might fail if gas prices spike, potentially leaving funds in a reclaimable but inaccessible state.
• Chain Reorganizations (Reorgs): If a source chain reorgs after a bridge transaction is relayed but before it's finalized on the destination, it could create invalid transactions or double-spend scenarios.
• Liveness Failures: If relayers or validators go offline, the bridge halts, freezing all transfers until service is restored.

Bridges act as critical pipes for liquidity aggregation, allowing DEXs and other protocols to source liquidity from across the ecosystem.

• DEX Aggregators: Platforms like 1inch and LI.FI use multiple bridges to find the optimal route and bridge for a cross-chain swap, minimizing cost and slippage.
• Shared Liquidity Pools: Bridges can connect isolated liquidity pools, creating larger, more efficient markets.
• Layer 2 Withdrawals: Bridges are the primary mechanism for moving assets from an Optimistic Rollup like Optimism back to Ethereum L1, though these are often called canonical bridges.

The application dictates the required security model. Key models include:

• Optimistic: Relies on a fraud-proof window (e.g., 7 days) where watchers can challenge invalid state transitions. Used by canonical rollup bridges.
• Light Client / Relayer: Uses cryptographic proofs (e.g., Merkle proofs) verified on-chain. More trust-minimized but computationally expensive.
• Multi-Party Computation (MPC): A decentralized network of nodes collectively manages funds, requiring a threshold of signatures.
• Liquidity Network: Uses atomic swaps or hashed timelock contracts (HTLCs) for peer-to-peer, trustless swaps, but requires readily available liquidity.

Prominent non-custodial bridges illustrate different technical approaches:

• Wormhole: A generic message-passing protocol that uses a network of Guardian nodes for attestation.
• LayerZero: An omnichain interoperability protocol that uses an Oracle and Relayer for lightweight message verification.
• Hop Protocol: Specializes in fast transfers between Layer 2s and Ethereum using bonded liquidity providers and Automated Market Makers (AMMs).
• Connext: A liquidity network bridge focused on fast, low-value transfers using atomic swaps.

A peer-to-peer exchange of cryptocurrencies between two parties on different blockchains without an intermediary. It uses hash timelock contracts (HTLCs) to ensure the swap either completes entirely or is refunded, forming the cryptographic basis for many non-custodial bridges.

• Mechanism: Both parties lock funds into a contract with a cryptographic secret.
• Trustless: No third party holds user assets.
• Example: Swapping BTC for ETH directly between user wallets.

A smart contract holding locked tokens that facilitate asset swaps and bridging. In a non-custodial bridge, these pools exist on both the source and destination chains, allowing users to deposit an asset on one chain and mint a representation on another.

• Function: Provides the liquidity for bridged assets like wrapped tokens.
• Key Model: Used in liquidity network bridges (e.g., Hop, Connext).
• Risk: Users face smart contract risk and impermanent loss for providers.

A token on one blockchain that represents a native asset from another chain, pegged 1:1 to its value. It is the primary output asset of most non-custodial bridges.

• Creation: Locking native asset (e.g., BTC) on the source chain mints a wrapped version (e.g., WBTC on Ethereum).
• Custody: The underlying collateral is held by a decentralized custodian or smart contract.
• Utility: Enables cross-chain DeFi participation (e.g., using BTC in Ethereum-based lending).

A decentralized set of nodes or validators that listen for events on one blockchain and submit transactions to another. They are the message-passing layer in many non-custodial bridges.

• Role: Transfers bridging messages or proofs between chains.
• Incentive: Operators are often incentivized with protocol fees.
• Security: Relies on cryptographic fraud proofs or optimistic verification to prevent invalid state transitions.

A core smart contract primitive that enables conditional, time-bound transfers. It is fundamental to atomic swaps and many non-custodial bridge designs.

• Condition: The receiver must provide a cryptographic preimage to a published hash to claim funds.
• Fallback: If not claimed within a set timeframe, the sender can reclaim the funds.
• Use Case: Secures the cross-chain commitment in a trustless manner.

The official, native bridge provided by a blockchain's core development team to connect to another chain (often a Layer 2 to its Layer 1). While often non-custodial, it represents a single point of failure in the protocol's security model.

• Examples: Arbitrum's L1<>L2 bridge, Polygon's PoS bridge.
• Contrast: Differs from third-party bridges built by independent projects.
• Consideration: Often has higher trust assumptions in the underlying chain's validators.