# Blockchain bridges: verifying an event across separate systems

A blockchain bridge connects activity on separate chains by verifying or attesting to events and authorizing a corresponding action elsewhere. Some lock assets and mint a representation; others burn and mint or deliver existing liquidity. Security depends on the specific verification, custody and upgrade design.

Evidence: [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/); [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164); [Intent Architecture in Across](https://docs.across.to/guides/concepts/intents-architecture)

Canonical: https://degreesofsatoshi.com/encyclopedia/blockchain-bridges/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T15:08:18.373Z

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Separate states:** Each chain has its own transaction history and settlement conditions. ([Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/))
- **Models:** Lock/mint, burn/mint and liquidity delivery are different mechanisms. ([Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/))
- **Control:** Privileged roles can affect contract operations where implemented. ([Access control](https://docs.openzeppelin.com/contracts/5.x/access-control))

## The destination needs a reason to accept the event

Moving a token balance between independent ledgers is not a single ordinary transfer. A destination contract needs evidence or an authorized statement that an event occurred on the origin chain. The bridge determines who or what can provide that assurance.

An example message might mean that ten units were locked for a particular recipient. If the destination accepts a false or replayed message, its resulting token accounting can disagree with backing. Verification and replay protection are therefore part of the asset’s meaning.

Evidence: [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/); [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164)

## Follow the assets as well as the message

In a lock-and-mint design, origin assets remain locked and a destination representation is created. A return path can burn the representation and release the locked asset. A burn-and-mint design instead depends on authorized issuance across chains.

A liquidity-based transfer can pay the recipient from existing destination funds and settle the provider’s imbalance separately. Across’s documentation, checked October 2, 2026, describes relayers fronting destination capital before a separate reimbursement process. These models should not be combined into a universal description that every bridge simply moves the same coins.

Evidence: [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/); [Intent Architecture in Across](https://docs.across.to/guides/concepts/intents-architecture)

## Completion has several possible meanings

A wallet may show origin-chain inclusion before the bridge’s verification window finishes or the destination action executes. Source finality, message acceptance and recipient delivery are different milestones. Delays need to be interpreted against that bridge’s design. The rollup scenario in [Follow a Transaction](/tools/transaction-walkthrough/) separates local inclusion from settlement milestones.

Record verification parties or proof system, upgrade authority, pause powers, supported asset and exact exit path. Several bridges to the same chain can have materially different dependencies. Calling both endpoints secure does not establish the security of the connection between them.

Evidence: [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/); [Access control](https://docs.openzeppelin.com/contracts/5.x/access-control); [Intent Architecture in Across](https://docs.across.to/guides/concepts/intents-architecture); [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164)

## Questions

### Are bridged tokens identical to issuer-native tokens?

Not necessarily. A bridged representation can be backed by assets locked under a bridge, whereas a native burn-and-mint transfer extinguishes the source token and creates the issuer’s token on the destination. Circle’s CCTP provides the latter example for USDC. Compare the actual token contracts and exit paths.

Evidence: [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/); [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp)

## Claims and scope

### blockchain-bridges-quick-answer

A blockchain bridge connects activity on separate chains by verifying or attesting to events and authorizing a corresponding action elsewhere. Some lock assets and mint a representation; others burn and mint or deliver existing liquidity. Security depends on the specific verification, custody and upgrade design.

Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null}

### blockchain-bridges-fact-separate-states

Separate states: Each chain has its own transaction history and settlement conditions.

Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null}

### blockchain-bridges-fact-models

Models: Lock/mint, burn/mint and liquidity delivery are different mechanisms.

Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null}

### blockchain-bridges-fact-control

Control: Privileged roles can affect contract operations where implemented.

Scope: {"collection":"defi","dataAsOf":null,"blockHeight":null}

## Sources

- [Introduction to blockchain bridges](https://ethereum.org/developers/docs/bridges/) — ethereum.org contributors. Lock/mint, burn/mint and liquidity-based transfers have different trust assumptions. Locator: How do bridges work?; Bridge types; Risk with bridges. Retrieved: 2026-10-02.
- [Access control](https://docs.openzeppelin.com/contracts/5.x/access-control) — OpenZeppelin. Ownership, roles, administrator authority and timelock limitations. Locator: Ownership and Ownable; Role-Based Access Control; Delayed operation. Retrieved: 2026-10-02.
- [ERC-5164: Cross-Chain Execution](https://eips.ethereum.org/EIPS/eip-5164) — Ethereum Improvement Proposals. An interface specification showing unique message identifiers, origin validation and replay protection; implementation security is separate. Locator: MessageDispatcher; MessageExecutor; Security Considerations. Retrieved: 2026-10-02.
- [Intent Architecture in Across](https://docs.across.to/guides/concepts/intents-architecture) — Across Protocol. Relayers front destination capital and are reimbursed through a separate settlement process. Locator: Competitive Relayer Network; Settlement Layer; How Settlement Flows. Retrieved: 2026-10-02.
- [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp) — Circle. USDC is transferred by native burn-and-mint rather than a traditional bridge liquidity pool. Locator: Overview; CCTP for non-USDC assets. Retrieved: 2026-10-02.

## Revision history

- 2026-10-02: First publication after primary-source research and independent automated verification.
- 2026-10-02: Before first publication, independent review checked and revised: quickAnswerSourceIds, sections, faq, sources, related. Replaced mismatched introductory-page locator with the developer bridge reference, and independently read ERC-5164 message uniqueness/execution/security requirements, Across destination capital/settlement and Circle CCTP native burn-and-mint. Added source support for replay protection, separately reimbursed liquidity delivery and native-token comparison. ERC-5164 is labeled Last Call, not universal implementation proof. Across example is dated to actual check; no universal bridge duration/security guarantee is asserted. Related links reach native/bridged stablecoins and Ethereum layer2; the existing rollup tool distinguishes local inclusion from settlement and withdrawal milestones.

## Cite this entry

Degrees of Satoshi editorial project. “Blockchain bridges: verifying an event across separate systems.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/blockchain-bridges/