Bridge designs — lock-mint, light client, optimistic, ZK, burn-mint

1. TL;DR

A bridge lets value or a message cross from one blockchain to another that has no shared validator set, and every design boils down to a choice of who — or what — is trusted to say “this happened on chain A” to chain B. The main families are custodial/multisig lock-mint, external validator networks (Wormhole’s guardians), light clients that verify headers directly, optimistic bridges that assume honesty unless challenged, ZK light clients that verify a succinct proof, and native burn-and-mint issuance (Circle’s CCTP) that avoids wrapped assets entirely. None of these is strictly safer than the others in the abstract — as Gnosis founder Martin Köppelmann observed, most historical bridge hacks were smart-contract bugs, not the trust-model failures the taxonomy is usually blamed for (ethresear.ch, 2023-01).

2. Explain it simply

Analogy

Moving money between two countries with no shared bank is a trust problem before it’s a technical one: you can hand cash to a courier company with offices in both places and trust their staff (a multisig custodian), you can trust a large panel of independent notaries who all watch the same newspaper and co-sign a certificate (a guardian network), you can have your own bank read the foreign country’s public ledger of transactions directly (a light client), you can let the transfer go through by default and only investigate if someone raises a complaint within a week (an optimistic bridge), or — simplest of all — you can have one issuer who destroys your dollars at the border and hands you the same amount of a note it prints as valid in both countries (burn-and-mint).

ELI5

When you move a token from one blockchain to another, there is no single computer both chains agree on, so something has to tell the destination chain “yes, this really happened on the source chain.” Different bridges pick different tellers: a small group of trusted people, a bigger group of independent watchers who all sign off, a program that reads the source chain’s records directly, or a system that just trusts everyone by default and punishes cheaters after the fact. If the destination token is a copy created just to represent the locked original, it’s called wrapped; if the same underlying token is destroyed on one side and freshly issued on the other, nothing is wrapped at all.

Step-by-step walkthrough

Scenario: Priya bridges 10,000 USDC from Ethereum to Solana using Circle’s Cross-Chain Transfer Protocol (CCTP), a native burn-and-mint design.

1. Before (state: Ethereum 10,000 USDC, Solana 0 USDC). Priya holds 10,000 USDC in her Ethereum wallet and nothing on Solana.
2. Burn. She calls depositForBurn on Ethereum’s CCTP contract, specifying the amount, Solana as the destination domain, and her Solana address. The contract burns her 10,000 USDC on Ethereum and emits a message containing a nonce.
3. Attestation. Circle’s off-chain attestation service observes the burn event, waits for the required number of block confirmations, and signs an attestation over the message. Circle offers two speeds: Fast Transfer (~8–20 seconds, backed by a Circle-provided allowance that absorbs finality risk) and Standard Transfer (15–19 minutes on Ethereum/L2s, waiting for full source-chain finality) (as of 2026-08, Circle docs).
4. Mint. Priya (or a relayer acting on her behalf) submits the burn message plus Circle’s attestation to Solana’s CCTP program, which calls receiveMessage.
5. After (state: Ethereum 0 USDC, Solana 10,000 USDC). The Solana program verifies the attestation and mints 10,000 native USDC directly to Priya’s Solana wallet. Total USDC supply across both chains is unchanged — one unit was destroyed exactly where another was created, so there is no wrapped token, no locked-liquidity pool, and no dependency on Solana validators trusting Ethereum’s.

Common misconceptions

• Myth: Bridging is just a cross-chain swap. Reality: No atomic exchange happens between two chains simultaneously — a bridge always does lock/burn on one side and mint/release on the other, with a window in between where you depend entirely on the attestor doing its job honestly.
• Myth: More signers automatically means a safer bridge. Reality: What matters is the threshold relative to the cost of corrupting it — Wormhole’s 13-of-19 guardian threshold has been targeted repeatedly not because 19 is a small number, but because the value flowing through the bridge can exceed what it costs to compromise 13 signers or exploit a bug in how their signatures are checked.
• Myth: All bridges create a “wrapped” version of the asset. Reality: Burn-and-mint designs like CCTP never wrap anything — the same native USDC is destroyed on one chain and reissued on the other by the token’s own issuer.
• Myth: A light-client bridge has no trust assumptions because it “just reads the chain.” Reality: It inherits the source chain’s own consensus assumptions (e.g., what if 51% of that chain’s validators equivocate) plus trust in whoever operates the client or reports headers to it.
• Myth: Optimistic bridges are always slow. Reality: Only the fraud-proof challenge window is slow; the risk it protects against — a forged message being accepted — is what a lock-mint or guardian bridge instead prices into who gets to sign.

If you only remember one thing

A bridge’s real security is never captured by its label (light client, optimistic, multisig) — it’s who can produce a false attestation, and what it costs them to do it.

3. How it works

Every bridge answers the same question — “how does the destination chain learn what happened on the source chain?” — with one of a small number of trust models.

Custodial / multisig lock-mint. A $k$-of-$n$ multisig (or a single custodian) holds the locked source-chain asset and signs mint instructions on the destination chain. Security reduces to the cost of compromising $k$ of the $n$ keys — whether by theft, bribery, or coercion — versus the value locked. Ronin’s bridge (see /cross-chain/bridge-hacks/) used exactly this model with a 5-of-9 threshold.

External validator / guardian network. Wormhole generalizes the multisig into a permissioned network of 19 “guardians” who independently observe source-chain events and sign a Verifiable Action Approval (VAA); the destination chain accepts a VAA once 13 of 19 signatures are present. This is structurally a multisig with a larger signer set, but it is still a new trust assumption disjoint from either chain’s own validators.

Light client / header-relay bridges. Rather than trusting a separate committee, the destination chain runs (or verifies) a light client of the source chain’s own consensus, checking block headers directly. Köppelmann’s Hashi proposal frames this as a “header storage contract” pattern: any existing bridge can be repurposed as a “header oracle,” and once several independent oracles agree on a header, applications build Merkle proofs on top with minimal added governance (ethresear.ch/t/14725, 2023-01). Security reduces almost entirely to the source chain’s own consensus plus whichever oracle(s) you trust for the header.

Optimistic bridges. Messages are accepted as valid by default; a bonded “watcher” can submit a fraud proof within a challenge window (~30 minutes for Nomad) to reject an invalid message and slash whoever submitted it. Security requires only one honest watcher, but withdrawals aren’t final until the window closes.

ZK light clients. A succinct proof of the source chain’s consensus or state transition is verified cheaply on the destination chain, replacing a large signature check with one proof verification — no separate committee needed, the direction Hashi’s thread points to with zk-based header proofs (e.g., between Gnosis Chain and Ethereum).

Native burn-and-mint. CCTP has no committee trust model at all: Circle, USDC’s issuer, burns on the source chain and mints on the destination once its own attestation service signs off. No wrapped asset, no locked-liquidity pool to drain, no committee to corrupt — but a single centralized attestor whose keys, uptime, and willingness to censor become the entire trust assumption.

Byzantine fault tolerance is subtler than “51%.” Responding to a Vitalik Buterin critique that bridges lack proper BFT, seunlanlege lays out two failure modes for light-client bridges under PoS: a genuine 51% attack, where the source chain’s own majority finalizes two competing chains at the same height (fatal for any light client, since both forks are individually “valid”); and an eclipse attack, where a malicious minority gossips a fraudulent finalized header only to isolated light clients while behaving honestly toward the rest of the network (ethresear.ch/t/13841, 2022-10). The mitigation is light clients actively participating in the p2p swarm to detect conflicting headers, rather than trusting a single relayer.

A rough cost model. For a $k$-of-$n$ signer-based bridge, define per-signer compromise cost $c$ and securable value $V$. If corruption is roughly independent across signers, attacker budget $C_{\text{attack}} \approx k \cdot c$, and the bridge is unsafe whenever $V > C_{\text{attack}}$. Bonded/slashed models replace $c$ with forfeited stake $s$, so $C_{\text{attack}} \ge k \cdot s$ — but this framework only prices intentional corruption, not a verification bug, which is how most real losses have happened (see /cross-chain/bridge-hacks/).

4. Worked numeric example

Continuing Priya’s CCTP transfer from §2, with the two transfer modes Circle documents (as of 2026-08):

Step	Fast Transfer	Standard Transfer
Burn confirmed on Ethereum	~1 block	full chain finality
Attestation available	seconds	after finality
Total time to mint on Solana	~8–20 seconds	~15–19 minutes
Amount received	10,000 USDC minus network fee	10,000 USDC minus network fee

Because CCTP is burn-and-mint, there is no slippage or liquidity-pool depth to worry about: Priya receives (minus a small fee) exactly the 10,000 USDC she burned, regardless of size, since minting isn’t constrained by “wrapped inventory” on Solana. Contrast a lock-mint bridge secured by a $k$-of-$n$ guardian network: using Wormhole’s real parameters ($n=19$, $k=13$), if compromising one guardian costs an illustrative $2M, the naive budget to forge a VAA is $13 \times \text{\textdollar}2\text{M} = \text{\textdollar}26\text{M}$ — a number that says nothing about an implementation bug letting an attacker skip forging signatures entirely, which is what happened to Wormhole in 2022 (see /cross-chain/bridge-hacks/). CCTP replaces the signer-corruption budget question with one question: do you trust Circle’s attestation service and its pause powers?

5. Where it’s used

Ethereum

• Wormhole / Portal Bridge — 19-guardian external validator network producing VAAs; connects Ethereum to 30+ chains including Solana. wormhole.com
• Circle CCTP — native USDC burn-and-mint between Ethereum, its L2s, and non-EVM chains including Solana; no wrapped USDC, no locked collateral pool. developers.circle.com/cctp
• Hashi — Gnosis-led header-oracle aggregator that lets multiple existing bridges act as independent “header oracles” for the same message, aiming for additive rather than substitute security. github.com/gnosis/hashi
• Nomad — historical optimistic bridge (fraud-proof challenge window); ceased meaningful operation after its August 2022 exploit (see /cross-chain/bridge-hacks/).
• deBridge — validator-network bridge with an intent-like fast-fill layer; see /cross-chain/intent-solvers/ for the fast-bridge trust models it builds on.

Solana

• Wormhole / Portal — Solana was one of Wormhole’s original supported chains; the same 19-guardian attestation model applies symmetrically in both directions. wormhole.com
• Circle CCTP — Solana is a first-class CCTP domain; USDC burned on Solana or any EVM chain mints natively on the other side through the same attestation service. developers.circle.com/cctp
• deBridge — supports Solana as a destination/source chain using its validator + fast-relayer design.
• n/a — no Solana-native light-client bridge in sources. Verifying another chain’s consensus directly inside a Solana program is not documented in the fetched material; Solana-side bridges in these sources are guardian-network or burn-mint designs, not header-relay light clients.

6. Risks, attacks, and incidents

• Guardian/multisig key compromise or forged signatures. The dominant real-world failure mode: an attacker steals or coerces enough keys, or — more often — exploits a bug that lets them mint without valid signatures at all. Wormhole (Feb 2022, $326M), Ronin (Mar 2022, $625M), and Multichain (Jul 2023, ~$125M) are covered in /cross-chain/bridge-hacks/.
• Optimistic bridge validation bugs. A single implementation error (a trusted Merkle root initialized to zero, in Nomad’s case) turns “assume honest unless challenged” into “assume anything is valid.” See /cross-chain/bridge-hacks/.
• Light-client eclipse attacks. A malicious minority of nodes can feed a fabricated finalized header to a poorly-connected light client, without needing majority control of consensus (ethresear.ch/t/13841, 2022-10).
• Centralized-issuer risk in burn-and-mint bridges. CCTP removes committee-corruption risk but concentrates trust in Circle: the attestation service can be paused, and USDC carries issuer-level freeze/blacklist powers regardless of chain.
• Governance and upgrade risk. Any bridge with an upgradeable contract or a “conflict resolution” role (Hashi includes one for disagreeing oracles) reintroduces a small trusted party even in an otherwise minimized design.

7. Open problems

• Standardization. Köppelmann notes “absolutely most bridges have their own message formats,” and earlier attempts at an IBC-equivalent standard for EVM chains hadn’t succeeded (ethresear.ch/t/14725, 2023-01) — Hashi’s header abstraction is one proposed fix, adoption not established.
• Additive vs. substitutive security. Hashi’s goal is that “new bridge approaches can ideally increase the security of existing bridges instead of offering new tradeoffs” — whether aggregating imperfect bridges achieves this, versus adding another point of failure, is argued but not resolved.
• Governance minimization for header oracles. Reply author auryn argues governance can be eliminated by letting users choose their own oracle-trust threshold per query, rather than a protocol-level conflict-resolution body — both remain live options.
• Light-client cost vs. finality speed. ZK light clients promise light-client trust without an external committee, but proving cost and latency for large validator sets remain unresolved engineering problems.

8. Ethereum vs Solana

Aspect	Ethereum	Solana
Dominant bridge trust model	Guardian networks (Wormhole) and native burn-mint (CCTP) both prominent	Same two models; Solana is a first-class chain in both
Light-client bridges	Experimental (Hashi, zk light clients between L2s/Gnosis)	Not documented in sources
Finality assumption bridges lean on	Variable — 12s slot, ~13 min economic finality pre-Pectra-era, faster with newer finality gadgets	Sub-second slots; CCTP Fast Transfer exploits Solana’s quick confirmation for one leg
Where most historical losses occurred	Guardian/multisig signature and validation bugs (Wormhole, Ronin’s Ethereum-side contract, Nomad, Multichain)	Comparatively few Solana-side bridge losses in these sources; Wormhole’s Feb 2022 bug lived in its Solana program, not a Solana-consensus failure

Both ecosystems rely on the same handful of trust models rather than chain-specific ones — a Wormhole guardian signs for Solana exactly as it does for Ethereum, and CCTP burns and mints symmetrically. The practical difference is less about design philosophy than about which side of a given bridge has, historically, contained the exploited code.

9. Reference doc

The reference

Hashi — A principled approach to bridges — mkoeppelmann (Martin Köppelmann, Gnosis), 31 January 2023. ethresear.ch/t/14725

Summary of the reference

Köppelmann opens by observing that the bridge landscape is heterogeneous by necessity: some chain pairs have access to low-trust options like ZK light clients, but an application that needs to reach many chains often has to fall back to a higher-trust, broader-coverage option like a committee-based bridge (his example is Wormhole). He identifies two structural problems with the status quo. First, as new bridge designs appear, they tend to offer different security tradeoffs rather than strictly better ones — an application picking a newer bridge isn’t obviously safer, just differently exposed. Second, there is no standardization: almost every bridge defines its own message format, so switching from one bridge to another is a substantial engineering effort, and earlier attempts at a cross-chain messaging standard (an “IBC for EVM”) had not succeeded.

Hashi’s proposed fix operates at the lowest possible layer: the block header. A “header storage contract” on the destination chain records chainID → blocknumber → header, fed by any number of “header oracles” — and critically, any existing bridge that can pass an arbitrary message can trivially be converted into a header oracle by having a contract on the source chain forward a recent block header through it. Once a reliable set of headers is available, higher-level primitives — Merkle proofs of storage slots, of emitted events, or ZK proofs of arbitrary state — can be built generically on top, and application-specific bridges (token bridges, NFT bridges, cross-chain smart-contract-wallet control) become a thin layer above that.

The governance model is deliberately minimal: after a set of trusted header oracles is configured, governance has no active role at all as long as the oracles agree; it exists only to arbitrate the rare case where oracles disagree about a given block’s header. A reply thread pushes this further — auryn argues governance can be eliminated altogether by making trust-threshold selection a purely user-side choice (an M-of-N parameter the querying contract or user picks per call), rather than a protocol-level curated oracle set. The main acknowledged drawback of the whole approach is cost and latency: if $n$ oracles are required to agree, bridging time is bounded by the slowest of them, though the post notes that existing “liquidity protocols” (fast optimistic relayers like Hop) already solve the latency problem for value transfer and could consume Hashi’s header layer as their eventual source of truth.

Key quotes

“Those bridges might only be available for a subset of chains and an application that needs to bridge to several chains might need to use a bridge solution that has worse security assumptions but can serve a greater number of chains” (Preface)

“Historically many bridge hacks did not have their root cause in e.g. committees getting compromised but instead simply in smart contract bugs” (Preface, side note)

“New bridge approaches can ideally increase the security of existing bridges instead of offering new tradeoffs” (statement of goal 1)

“After setting up a set of trusted bridge oracles, a minimized governance would only act as a conflict resolution mechanism. If all oracles report the same header for a block number, governance has no rights.” (Block header based bridges)

“I actually think that governance can be completely eliminated in this system, which seems preferable.” (Reply #3, auryn)

How to read the original

Background needed: what a light client is, roughly how Merkle proofs authenticate storage slots or events against a known header, and a passing sense of what a token bridge does mechanically (lock/mint vs. burn/mint). Skip the deep GitHub PR thread near the end (the zk-proof-of-concept implementation details) on a first pass — it’s a worked demo, not part of the core argument. The hardest part to parse is the push-vs-pull design debate in replies #4–5: Köppelmann initially leans toward oracles “pushing” headers to the storage contract to minimize interactions and prevent an oracle from reporting two different headers for the same block, while auryn argues this should be an adapter-level implementation detail rather than a protocol-wide choice — the disagreement is really about where to draw the line between “protocol” and “adapter,” which matters for how easily new header sources can be added later.

What changed since

• Hashi shipped as actual code shortly after this post (github.com/gnosis/hashi), including early Wormhole and Gnosis AMB adapters, moving the proposal from concept to a maintained aggregator.
• The Ethereum Interop Layer (EIL) and synchronous-composability proposals (2025–2026) push a related but distinct idea — reducing trust not by aggregating headers but by having users execute directly on each chain themselves — see /cross-chain/cross-l2-interop/.
• CCTP’s growth as the default USDC-bridging path (Circle docs, as of 2026-08) has made native burn-and-mint the practical alternative many applications reach for instead of any header- or committee-based bridge, at least for the single asset it covers.

Secondary references

1. Circle, “Cross-Chain Transfer Protocol” docs — read if you want the concrete burn/mint flow and Fast vs Standard transfer timing used in §2 and §4.
2. seunlanlege, “Byzantine Fault Tolerant Bridges” (ethresear.ch, 2022-10) — read if you want the precise distinction between a 51% attack and an eclipse attack on a light-client bridge.
3. Wormhole docs, “Security” — read for the current guardian-set size and VAA threshold as officially documented.

10. Sources

• Hashi — A principled approach to bridges — mkoeppelmann — 2023-01-31 — https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725
• Byzantine Fault Tolerant Bridges — seunlanlege — 2022-10-04 — https://ethresear.ch/t/byzantine-fault-tolerant-bridges/13841
• Cross-Chain Transfer Protocol — Circle Docs — fetched 2026-08-29 — https://developers.circle.com/cctp
• Wormhole Developer Documentation — Wormhole — fetched 2026-08-30 — https://wormhole.com
• Explained: The Wormhole Hack (February 2022) — Halborn — fetched 2026-08-30 — https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022
• Explained: The Ronin Hack (March 2022) — Halborn — fetched 2026-08-30 — https://www.halborn.com/blog/post/explained-the-ronin-hack-march-2022