Lesson 1 — What is a bridge? Trust models and the bridge trilemma

Question

You hold 1 ETH on Ethereum and want it on Optimism. The chains share consensus rules but not state — there is no native transfer that crosses chains. A bridge fills the gap, but every bridge picks a trust model. $2 B+ in bridge hacks since 2021 (Ronin / Wormhole / Nomad / Poly / Orbit) say the trust model is the architecture.

Principle (minimum model)

• A bridge is a protocol that moves value or messages between chains that can't directly verify each other. Lock-mint / burn-mint / atomic-swap are different mechanisms; the trust model is the axis that matters.
• The bridge trilemma. Trust-minimised + low cost + fast. Pick at most two. Light clients = trust-minimised + fast, expensive. Multi-sig = cheap + fast, trusted. Optimistic = trust-minimised + cheap, slow.
• Five trust models, in order of decreasing trust. (1) Custodial bridge (Binance Bridge — wraps a CEX). (2) Multi-sig bridge (Wormhole — N-of-M validators). (3) Optimistic bridge (Nomad — challenge window). (4) Light-client bridge (Helios / IBC — cryptographic proof). (5) Atomic swap (HTLC — no third party at all).
• $2 B+ in bridge hacks since 2021. Ronin ($625 M, key compromise) / Wormhole ($325 M, signature verification bug) / Nomad ($190 M, replay attack) / Poly ($600 M, role check bypass) / Orbit ($82 M, governance). The pattern: trust-anchor compromise dominates.
• The trilemma forces a choice. Light clients are gold-standard but expensive on-chain. Optimistic challenge windows are cheap but slow (7 days for OP). Multi-sigs are fast and cheap but the validator set is the attack surface.
• Reth's role. Reth nodes can run a light-client bridge contract; the SDK can host a light-client verifier on-chain. The "build a minimal bridge" lesson (L6) implements this.

Worked example + steps

What is a bridge? Trust models and the bridge trilemma

$2B+ has been stolen from bridges in the last five years. Not from obscure DeFi corners — from the highest-TVL bridges run by the biggest teams in the industry: Ronin ($625M), Wormhole ($325M), Poly Network ($611M, returned), Nomad ($190M). Every cross-chain architecture decision is downstream of one question: what do you have to trust for state on chain A to move state on chain B, and what attacks remain once you've minimized that trust?

A bridge is the system that answers it. The whole field of cross-chain infrastructure is variations on how much trust and what residual attacks.

1. The bridge primitive — value vs. message

People talk about "asset bridges" and "message bridges" as if they're separate things. They're not. An asset bridge is a message bridge plus a token contract on each side. All cross-chain infrastructure is fundamentally message-passing — the asset case just adds conventions on top.

For Tempo↔Solana settlement (mppsol): message bridge. The "asset" is a payment receipt, not a token. For OP↔Ethereum: message bridge with native token convention (ETH deposit/withdrawal). For BTC↔EVM (wrapped BTC): asset bridge.

2. The trust spectrum

Every bridge sits somewhere on a single axis: what do you have to trust? The worst end is a committee of humans. The best end is math.

External trust (worst)                                  Internal trust (best)
  ↓                                                              ↓
[Multisig] → [Optimistic with challenges] → [PoS bridge] → [Light client] → [ZK light client]

The best bridge from a trust standpoint is a ZK light client of the source chain on the destination chain. The worst is a multisig — you're trusting humans not to collude.

Multisig keys can be stolen (Ronin: $625M, attacker got 5 of 9 keys via spear-phishing). The signers themselves can collude (no enforcement). The signing infrastructure can be compromised (Wormhole: bug in signature verification, not key theft, but proves how brittle multisig infra is).

A light client doesn't have these failure modes — it verifies headers against the source chain's consensus rules. The only way to fool it is to fool the source chain itself.

3. The bridge trilemma

You cannot have all three of:

• Trustlessness — no external trust assumptions
• Generality — supports arbitrary chains
• Extensibility — easy to add new chains

Trustless + general → expensive to add chains (each pair needs a light client implementation). This is the IBC/Cosmos model. Trustless + extensible → only works for similar chains. This is the OP Stack approach (L2s sharing one bridge interface). General + extensible → not trustless. This is Wormhole/LayerZero — they support many chains and add new ones easily, but trust a multisig or DVN set.

For Tempo (a Paradigm L1) bridging to Ethereum: trustless + bespoke = light client of Tempo on Ethereum, and vice versa. Eventually ZK light client.

For Tempo bridging to Solana: trustless is currently impossible (cross-VM, different consensus, different cryptography). You need a multisig or PoS model. Chainlink CCIP is the production answer here.

4. The bridge attack hall of fame

Real attacks, sorted by amount stolen, with the root cause:

2 of 5 are outright key compromises (Ronin, Orbit) — and the other three are bugs in cross-chain trust/verification logic rather than core asset logic. Either way: the failure mode is the bridge's trust apparatus, not the underlying token contracts.

The takeaway: multisig bridges are operationally dangerous, not just theoretically suboptimal. Even with audited code, the keys themselves are the attack surface.

5. What this means for your projects

Tempo↔Ethereum (Telos, Soltempo)

• Today: Chainlink CCIP — best production option, multi-network DON
• 2-3 years: Light client of Tempo on Ethereum (and vice versa)
• 5+ years: ZK light client if proving costs come down

Tempo↔Solana (mppsol)

• Today: CCIP (since it now supports Solana 2026)
• Future: ZK light client — hardest because EVM↔non-EVM with different cryptography
• Workaround: settle through Ethereum as intermediate (longer, but light-client verifiable both legs)

Hyperliquid↔Ethereum

• Today: Hyperliquid bridge (custom multisig)
• Hyperliquid's own roadmap is unclear on trust model improvements; they prioritize speed

6. The verification cost tradeoff

For each trust model, the cost split between prover (whoever writes the bridge claim) and verifier (whoever checks it):

For payment-rail bridges (Tempo): frequency is high (every merchant settlement). ZK light client is the right asymptote — high prover cost amortized over many verifications.

7. Reading list

• a16z bridge taxonomy — the trust model framework
• Chainlink CCIP whitepaper — DON-based bridge design
• Helios — Rust Ethereum light client (you'll read this next lesson)

8. Practice

For each chain pair, identify the realistic trust model today:

1. Ethereum mainnet ↔ Optimism (canonical bridge)
2. Ethereum mainnet ↔ Polygon PoS
3. Solana ↔ Wormhole assets on Ethereum
4. Tempo ↔ Ethereum (per public info)
5. Bitcoin ↔ any EVM chain

Final check: in one sentence, why is "trust model" the dimension to optimize when designing a bridge — even more than speed or cost? If your answer doesn't reference attack history or the bridge trilemma, re-read §3 and §4.

Summary (3 lines)

• Bridges fill the gap between chains that can't verify each other directly. Trust model = the architecture; mechanism (lock-mint / burn-mint / atomic-swap) is downstream.
• Bridge trilemma: trust-minimised + cheap + fast → pick two. Five trust models ranked by trust: custodial → multi-sig → optimistic → light client → atomic swap.
• $2 B+ in bridge hacks since 2021 — trust-anchor compromise dominates the pattern. Next lesson reads the gold-standard primitive (light clients) in detail.