Bridge
A bridge carries messages or asset representations between blockchains by verifying a source-chain event and authorizing a corresponding destination-chain action.
Category: RiskWarning cross category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
Blockchains do not natively share one state, so applications need an explicit verification and settlement mechanism to communicate or move usable value across networks.
Traditional-finance analogy
Cross-system settlement link and depositary is the closest comparison recorded for this concept.
Where the analogy stops
- A bridge must reconcile independent consensus and finality systems, and its verifier may be a light client, proof system, validator set, custodian, or other trust mechanism.
- Destination tokens are new ledger positions or claims; assets do not literally move between isolated chains, and backing can fail independently of the source asset.
Main actors
- ActorSender and destination recipient
- ActorSource and destination bridge contracts
- ActorRelayer, validator, light client, oracle, or proof verifier
- ActorLiquidity provider, custodian, guardian, or governance authority when present
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetSource assets locked, burned, or supplied as liquidity
- AssetDestination assets minted, released, or supplied as liquidity
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimDestination asset representation backed by bridge accounting
- ClaimCross-chain message authorization awaiting or proving settlement
A bridge verifies something that happened on one blockchain and authorizes a related message, mint, burn, lock, or release on another.
Why it exists
Section titled “Why it exists”Separate blockchains cannot natively read each other’s state. Users and applications nevertheless want to use assets or instructions across networks. A bridge supplies a verification and settlement rule for that boundary. It does not teleport an asset: it changes accounting on each side and may create a new destination claim.
Traditional-finance analogy
Section titled “Traditional-finance analogy”A cross-system settlement link or depositary is a useful analogy. The analogy stops because a bridge must reconcile independent consensus systems and can be controlled by a light client, proof system, validator set, oracle, custodian, multisignature, or hybrid verifier. Destination representations can immediately compose with permissionless contracts, spreading a verification error before a human reconciliation process could intervene.
Actors, assets, and claims
Section titled “Actors, assets, and claims”| Bridge role | Asset or claim effect | Trust question |
|---|---|---|
| User | Locks, burns, sends, or receives | Which chain and token representation is intended? |
| Source contract or custodian | Holds or accounts for source value | Can backing be released without a valid destination action? |
| Relayer | Carries message data | Can omission delay service, and can bad data pass verification? |
| Verifier | Decides whether the source event is acceptable | What proof, quorum, key set, or oracle is trusted? |
| Destination contract or liquidity provider | Mints, releases, or swaps destination value | Does issued value reconcile with source backing or liquidity? |
| Governance or guardian | Changes, pauses, or recovers the system | Can emergency authority bypass normal verification? |
A lock-and-mint design leaves the original asset on the source chain and issues a destination representation. That token is a direct asset at the destination ledger layer and a redeemable claim on bridge backing. Burn-and-mint and liquidity-network designs use different balance sheets; the token symbol does not identify the model.
Mechanism and flows
Section titled “Mechanism and flows”- A source action locks or burns an asset, supplies liquidity, or emits a message.
- The system waits for its declared source finality condition.
- A relayer supplies data, proof, or attestations to the destination.
- The destination verifier authenticates source, sender, payload, destination, nonce, and finality under the chosen trust model.
- The destination mints, releases, swaps, or calls a contract exactly once.
- The reverse path later burns or returns the representation and unlocks, mints, or releases value under its own rules.
Capital flow follows locked assets and liquidity. Claim flow follows minted representations and pending messages. Information flow carries proofs and attestations. Return flow can pay liquidity providers or operators from user fees or incentives; bridging itself does not create yield. Control flow follows verifier quorums, custody keys, rate limits, upgrades, and pauses. Risk flow can move from either chain or verifier into every protocol accepting the destination asset.
State and loss allocation
Section titled “State and loss allocation”| Event | Source-side state | Destination-side state | Required reconciliation |
|---|---|---|---|
| Outbound request | Asset locked, burned, or debited | Message pending | One source event maps to at most one destination action |
| Accepted message | Backing or liquidity remains accountable | Asset minted or released | Issued value matches the bridge model |
| Return request | Representation burned or liquidity debited | Source release pending | Consumed destination claim cannot be reused |
| Verification failure | Source may remain valid | Destination action must not occur | User enters an explicit retry, refund, or recovery state |
| Backing shortfall | Available source value is too low | Destination claims may remain | Loss is surfaced and allocated, not hidden by nominal price |
Fee payers fund legitimate operator or liquidity-provider return. Token incentives are new issuance, not bridge-generated productivity. A forged message, compromised verifier, finality mismatch, custodian loss, or liquidity shortfall can leave destination holders, pools, lenders, a reserve, insurer, or governance backstop absorbing loss.
Beginner lens
Section titled “Beginner lens”When an asset “moves” to another chain, ask what happened to the original and what exactly the new token promises. The destination balance can be a wrapper whose value depends on a bridge even if its ticker resembles the source asset.
Practitioner lens
Section titled “Practitioner lens”Identify the model, source and destination contracts, verifier, finality rule, custody, supply reconciliation, limits, fees, liquidity, upgrade authority, pause behavior, monitoring, and recovery. Price and depth on the destination do not prove source backing is available for redemption.
Engineer or auditor lens
Section titled “Engineer or auditor lens”Ethereum’s bridge documentation groups designs by how they move assets or messages and warns that each adds trust assumptions. Specific systems vary widely: a light-client bridge validates consensus evidence differently from a multisignature or liquidity network. Review the deployed version and both chains rather than generalizing from the word “bridge.”
Security review notes
Section titled “Security review notes”Bind every message to its source chain, sender, destination, payload, nonce, and finality condition. Enforce one-time execution and supply reconciliation. Test reorganization, duplicate, delayed, conflicting, malformed, paused, and upgrade states. Bound verifier, guardian, custodian, and recovery authority. These are review requirements, not proof that a particular bridge satisfies them.
Common misunderstandings
Section titled “Common misunderstandings”- “The same asset exists on both chains.” The ledgers hold separate positions connected by bridge rules.
- “More validators automatically means safer.” Independence, thresholds, key custody, software, upgrades, and incentives matter.
- “A valid source transaction guarantees redemption.” Destination verification, liquidity, backing, liveness, and governance can still fail.
Prerequisites and learn next
Section titled “Prerequisites and learn next”Read blockchain, smart contracts, and settlement and finality first. Continue with wrapped assets and bridge risk to inspect the destination claim and its failure propagation.
Sources
Section titled “Sources”- Ethereum.org, Blockchain bridges — bridge categories, asset-transfer patterns, and trust boundaries (accessed 2026-08-09).
- The supplied DeFi seed, sections 10, 12, and 14 — composability, bridge learning, and system-analysis questions.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Every accepted message binds the intended source, sender, destination, payload, nonce, and finality rule and executes at most once
Minted or released destination value reconciles with locked, burned, or liquidity-provided source value under the stated model
Conflicting, delayed, reorganized, or unverifiable source events enter explicit pending or recovery states
Verifier thresholds, custody, rate limits, upgrades, pauses, and emergency powers cannot silently exceed their disclosed authority
Knowledge check
Quiz
Answer in your own words, then open the model answer.
What must reconcile in a lock-and-mint bridge?
Model answer
Destination supply must remain accountable to source assets that are validly locked and available under the bridge's stated conversion and recovery rules.