Cross-Chain Bridges Explained: How They Actually Work

Cross-chain bridges are among the most important - and most misunderstood - pieces of blockchain infrastructure. This article explains, in technical terms, what a bridge actually does, the distinct mechanisms bridges use to move value, the messaging layer underneath them, the trust and security models that separate a safe bridge from a risky one, and how fees and settlement time arise. It is written to be an accurate reference, independent of any specific product.

Why bridges are necessary

Each blockchain is a self-contained state machine. Ethereum has no native ability to read Solana's state, and Robinhood Chain cannot directly observe a balance on Base. A blockchain only knows about transactions submitted to itself. That isolation is a security property - it is what lets each chain reach consensus independently - but it means an asset on one chain cannot, on its own, appear on another. A bridge is the infrastructure that coordinates state changes across two otherwise-isolated chains so that value can effectively move between them.

The critical insight is that a token never physically moves. A USDC balance on Ethereum is an entry in Ethereum's state; it cannot be teleported to Base. What a bridge does is make the asset unusable or reduced on the source chain and make an equivalent asset available on the destination chain, in a way both chains can agree on. Every bridge mechanism is a different answer to the question: how do we do that so the two sides stay consistent and no value is created or destroyed?

The two layers of every bridge

It helps to separate a bridge into two layers, because most security incidents happen in one of them specifically:

• The value layer: what happens to the asset on each chain - is it locked, burned, drawn from a pool, or fronted by a relayer? This determines what backs the asset you receive.
• The messaging layer: how the destination chain learns that the source-chain action actually happened. This is the trust core of the bridge - whoever controls the messaging can, in the worst case, forge a transfer.

A bridge can have a perfectly sound value layer and still be catastrophically insecure if its messaging layer can be spoofed. Most large bridge exploits have been failures of the messaging/verification layer, not the token mechanics.

The main value-layer mechanisms

Lock-and-mint (wrapped assets)

The classic mechanism. The bridge locks the real asset in a contract on the source chain and mints a wrapped representation (e.g. a bridged version of the token) on the destination chain. Burning the wrapped token on the destination chain unlocks the original on the source chain. The wrapped asset is only as trustworthy as the entity controlling the lock contract and the mint authority; if that authority is compromised, the wrapped token can be minted without backing. Many high-profile bridge hacks were lock-and-mint bridges whose mint authority was seized.

Burn-and-mint (native / canonical)

Instead of locking and wrapping, a burn-and-mint system burns the native token on the source chain and mints the same canonical token on the destination chain, with no wrapped placeholder. Circle's CCTP for USDC and LayerZero's OFT standard (used by assets such as USDT0) work this way. Because the destination asset is the canonical token rather than a wrapper, there is no fragmentation into many incompatible wrapped versions, and the issuer typically controls the mint under a defined attestation scheme.

Liquidity-pool bridges (lock-and-unlock)

Rather than minting, these bridges keep liquidity pools of the same asset on both chains. Your deposit is added to the source-chain pool and an equivalent amount is paid out of the destination-chain pool - so you receive the real native asset immediately, not a wrapper. Stargate is a well-known example. The trade-off is that transfers are limited by pool depth on the destination side and pay a fee to the liquidity providers, and pricing can move if a pool is imbalanced.

Intents and optimistic relayers

The newest and often fastest model. You express an intent ("I want X on the destination chain") and a relayer immediately fronts you the funds from its own capital on the destination chain, then later reclaims the amount from the source chain once the action is verified - often optimistically, with a challenge window. Across popularised this design. Because a relayer fronts destination liquidity, settlement to the user can be near-instant even though the underlying reconciliation takes longer.

The messaging layer and trust models

Whatever the value mechanism, the destination chain must be convinced the source-chain event happened. How that proof is produced defines the bridge's trust model:

• External validators / MPC: a set of off-chain signers attests to source events. Fast and general, but you trust that the signer set is honest and not compromised - the model behind several of the largest historical bridge losses.
• Optimistic verification: messages are assumed valid unless challenged within a window by a watcher who can prove fraud. Cheap and general, at the cost of a delay for full finality.
• Light clients / native verification: the destination chain verifies a cryptographic proof of the source chain's consensus directly. The strongest trust model (no external trusted party), but expensive and harder to build for every chain pair.
• Issuer attestation: for canonical burn-and-mint (e.g. CCTP), the asset issuer attests to the burn. You trust the issuer, which for a regulated stablecoin is an explicit, known party.

When people say one bridge is "more secure" than another, they almost always mean its messaging/verification model requires trusting fewer, or more accountable, parties.

Custodial vs non-custodial bridges

A non-custodial bridge never takes control of your funds: there is no deposit address you send to and no third party holding a balance on your behalf. Your own wallet signs a transaction that interacts directly with the bridge's smart contracts, and the protocol moves the value programmatically. A custodial bridge, by contrast, has you send funds to an address controlled by an operator who then releases them on the other side - which reintroduces exactly the counterparty risk that public blockchains exist to remove. Prefer non-custodial designs; verify that your wallet, not a deposit address, is the thing signing.

How bridge fees arise

A bridge transfer's cost is the sum of a few real components: gas to submit the transaction on the source chain; gas to execute delivery on the destination chain (often paid out of your transfer); the underlying protocol's own fee (liquidity-provider fees for pool bridges, relayer margin for intents); and any routing or interface fee. A well-designed interface shows the net amount you will receive after all of these before you sign, so the quoted receive amount - not a headline rate - is the number that matters.

Settlement time and finality

Speed depends on the mechanism and on source-chain finality. An intents-based route can pay you in seconds because a relayer fronts the funds; a pool or mint route waits for enough source-chain confirmations to be safe. A transfer that runs past its estimate is usually slow, not failed - cross-chain settlement has a long tail, especially across congested networks. The source transaction is verifiable on the source explorer immediately; the destination leg follows once the messaging layer confirms.

Common risks and how to verify a transfer

• Verify the destination address before signing - a bridge transfer cannot be recalled once submitted.
• Prefer non-custodial routes where your wallet signs and there is no deposit address.
• Compare the net receive amount, not the advertised rate.
• Confirm the source transaction on the source-chain explorer, and track the destination leg by transaction hash.
• Understand what you are receiving: a canonical native token, or a wrapped representation whose value depends on a mint authority.

Aggregators sit above all of this

Because no single mechanism or protocol is best for every asset and route, bridge aggregators compare multiple underlying bridges per transfer and route through the best one - abstracting the mechanism choice away from the user. The difference between an aggregator and a single bridge protocol is significant enough to warrant its own article; see the related link below.

How Titan Bridge applies this

Titan Bridge is a non-custodial bridge aggregator developed by Titan that automatically routes transfers across multiple bridge providers to optimise speed, cost, and reliability. In the terms above, Titan operates at the routing layer: it does not run its own value or messaging layer, but selects among established underlying protocols (via LI.FI, with Relay as a fallback) that do, and it is non-custodial - your wallet signs every transaction and no deposit address is involved. Verification of any Titan transfer can be done on the source and destination explorers by transaction hash, exactly as described above.