> ## Documentation Index
> Fetch the complete documentation index at: https://docs.layerzero.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Blockchain Interoperability

> Interoperability lets independent blockchains exchange data and value safely so applications can span multiple. LayerZero enables secure crosschain messaging.

**Interoperability** lets independent blockchains exchange data and value safely so applications can span multiple networks.

## The Basic Model

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
A[Source Contract]
end

    subgraph "Chain B"
        B[Destination Contract]
    end

    A -->|Crosschain Message| B
```

<br />

* **Source** — A smart contract on Chain A that encodes (data or value) and emits a message.
* **Crosschain Message** — A structured container that includes metadata about the source/destination chain and structured data for the destination contract's business logic.
* **Destination** — A smart contract on Chain B that receives the message, decodes, and executes some requested business logic.

## Why It Matters

Without interoperability, smart contract state, liquidity, and users remain **siloed per chain**, increasing fragmentation, friction, and operational overhead. Interoperability enables better UX, capital efficiency, and scalable architectures by coordinating logic and assets across chains.

## What Crosschain Smart Contracts Do

Interoperable smart contracts can share data, update state, trigger actions, and transfer value between different blockchain networks seamlessly, as if these contracts were deployed on a single network.

### 1) Data Messaging

Move structured data and/or trigger logic across smart contracts on different blockchains.

#### **Push**

A sends a message that B receives.

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Source Contract]
end

        subgraph "Chain B"
            B[Destination Contract]
        end

        U -->|"Calls method"| A
        A -->|"Push crosschain message"| B
```

#### **Pull**

A requests from B; B replies; A processes on arrival.

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Source Contract]
end

        subgraph "Chain B"
            B[Destination Contract]
        end

        U -->|"Calls method"| A
        A -->|"Crosschain data request"| B
        B -->|"Return data"| A
```

***

**Data Messaging** is typically used for state synchronization, remote function invocation, orchestration, and governance.

### 2) Value Transfer

Move assets between chains while preserving global supply/ownership invariants.

Value transfer in practice can take various forms, depending on the type of asset being moved (native chain currency or fungible token smart contract) and whether the bridge is the asset issuer, but the underlying pattern is the exact same: the contract **debits** funds on one chain, and **credits** an equivalent amount on another chain.

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
USER[User<br/>-100 tokens]
A[Source Contract]
end

    subgraph "Chain B"
        B[Destination Contract]
        RECEIVER[Receiver<br/>+100 tokens]
    end

    USER -->|"Call debits funds"| A
    A -->|Crosschain Message| B
    B -->|"Call credits funds"| RECEIVER
```

#### Canonical Burn/Mint

Chain A **burns** tokens and Chain B **mints** the same amount, unifying supply across chains.

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Source Contract]
BURN[Burn Address]
end

    subgraph "Chain B"
        B[Destination Contract]
        R[Receiver]
    end

    U -->|"Calls transfer"| A
    A -->|"Burn tokens"| BURN
    A -->|"Crosschain message"| B
    B -->|"Mint tokens"| R
```

#### Lock/Unlock

Chain A **locks** tokens on a home chain and represents elsewhere (typically Chain B **mints**). When B **burns**, A **unlocks** the original escrowed tokens.

**Forward flow (A → B):**

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Source Contract]
VAULT[Escrow Address]
end

    subgraph "Chain B"
        B[Destination Contract]
        R[Receiver]
    end

    U -->|"Calls transfer"| A
    A -->|"Lock tokens"| VAULT
    A -->|"Crosschain message"| B
    B -->|"Mint representation"| R
```

***

**Reverse flow (B → A):**

```mermaid wrap theme={null}
graph LR
subgraph "Chain B"
U2[User]
B[Source Contract]
BURN[Burn Address]
end

    subgraph "Chain A"
        A[Destination Contract]
        VAULT[Escrow Address]
        R2[Receiver]
    end

    U2 -->|"Calls transfer"| B
    B -->|"Burn representation"| BURN
    B -->|"Crosschain message"| A
    A -->|"Unlock from escrow"| VAULT
    VAULT -->|"Send original tokens"| R2
```

#### Liquidity Pools

Chain A transfers assets to pool A destination pays from pool B (fees/slippage possible).

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Source Contract]
POOL_A[Pool A]
end

    subgraph "Chain B"
        B[Destination Contract]
        POOL_B[Pool B]
        R[Receiver]
    end

    U -->|"Calls transfer"| A
    A -->|"Add tokens to pool"| POOL_A
    A -->|"Crosschain message"| B
    B -->|"Pay from pool"| POOL_B
    POOL_B -->|"Send tokens"| R
```

***

**Value Transfer** is typically used for crosschain payments, asset bridging, liquidity provision, and treasury management.

<Info>
  Value transfer is simply data messaging with token‑specific invariants/settlement logic.
</Info>

## How Crosschain Messages Can Be Trusted and Delivered

This concept applies to **both** Data Messaging and Value Transfer.

### A) Verification (state correctness)

Each blockchain is a network of nodes reaching consensus about the state of that specific chain. In principle, this means that nodes from one blockchain network and the consensus they reach is entirely independent of another blockchain network. Each network is effectively an isolated island without any knowledge of external state outside its own domain.

**The Core Challenge:** How can Chain B trust a statement about Chain A when Chain B's validators have no direct way to verify what happened on Chain A?

Because of this limitation, **every crosschain message requires verification**. Different approaches involve different trust assumptions and trade-offs:

#### Verifier Networks

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
A[Smart Contract A]
end

    subgraph "Chain B"
        B[Smart Contract B]
    end

    subgraph "Off-Chain Verification"
        VN[Verifier Network]
    end

    A -->|"Event: Message sent"| VN
    VN -->|"Proof: Message verified"| B
```

<br />

Verifier Networks act as **independent observers** that watch blockchain events and provide proof to the destination chain that a state change occurred on the source network.

They are opinionated about how crosschain messages are routed, what chains they support, and what trust assumptions are used to confirm the state of a message from another chain.

> **Note**: The following is a simplified mental model. In practice, security depends on implementation details, economic incentives, validator sets, and attack vectors specific to each system.

| Approach                 | Core Assumption                               | Typical Characteristics                          |
| ------------------------ | --------------------------------------------- | ------------------------------------------------ |
| **Light / zk client**    | Chain consensus or validity proofs            | High assurance; higher cost/latency              |
| **Committee / multisig** | Honest majority of a known validator set      | Fast; social/economic security; validator risks  |
| **Optimistic**           | Fraud proofs during a challenge window        | Delayed finality; capital‑efficient              |
| **Middlechain**          | Shared validator set and middlechain liveness | Aggregated security; inherits middle layer risks |

**Key insight**: There's no universal "best" approach - the optimal choice depends on your application's value-at-risk, latency requirements, and acceptable trust assumptions.

As this trilemma between verification security, cost, and latency evolves, new verifier networks may emerge with better properties that serve applications better than existing solutions.

### B) Transport & Message Delivery

Transport layers handle the routing and delivery of crosschain messages, managing the flow from source to destination contracts.

**Question:** How are verified messages actually delivered on the destination chain?

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
SENDER["Sender Contract"]
TL_A["Transport Layer<br/>Contract"]
end

    subgraph "Chain B"
        TL_B["Transport Layer<br/>Contract"]
        RECEIVER["Receiver Contract"]
    end

    U -->|"Initiates"| SENDER
    SENDER -->|"Message"| TL_A
    TL_A -->|"Crosschain Delivery"| TL_B
    TL_B -->|"Delivers Message"| RECEIVER
```

<br />

Crosschain systems must solve fundamental delivery challenges: ensuring messages arrive reliably, handling ordering requirements, and preventing replay attacks. Different applications have varying needs - some require strict ordering, while others can tolerate unordered delivery for better performance.

**Key considerations:**

* **Message ordering**: Whether messages must arrive in sequence or can be processed independently
* **Delivery guarantees**: Handling network failures, ensuring messages aren't lost or duplicated
* **Replay protection**: Preventing the same message from being executed multiple times

### C) Execution & Gas Management

Executors are external services that monitor for verified messages and pay the gas costs to execute them on destination chains.\
**Question:** Who pays for destination chain execution and how is it funded?

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
A[Smart Contract A]
end

    subgraph "Chain B"
        TL_B[Transport Layer]
        B[Smart Contract B]
    end

    subgraph "Off-Chain Services"
        EX[Executor<br/>Gas Provider]
    end

    U -->|"Initiates + Pays Gas"| A
    A -->|"Message Ready"| TL_B
    EX -->|"Monitors and Executes<br/>Uses own gas"| TL_B
    TL_B -->|"Delivers Message"| B
```

<br />

Every crosschain message requires someone to submit a transaction on the destination chain and pay gas fees. This creates an economic coordination problem: **the message sender is on a different chain from where execution costs are incurred**.

**Key considerations:**

* **Execution responsibility**: Whether delivery is permissionless, automated, or manual
* **Gas funding**: How destination chain fees are paid and by whom
* **Economic incentives**: Ensuring reliable delivery through proper fee markets and incentive alignment

## Complete Crosschain Message Flow

Now combining all three components, here's how a complete crosschain message flows through verification, transport, and execution:

```mermaid wrap theme={null}
graph LR
subgraph "Chain A"
U[User]
SENDER["Sender Contract"]
TL_A["Transport Layer<br/>Contract"]
end

    subgraph "Chain B"
        TL_B["Transport Layer<br/>Contract"]
        RECEIVER["Receiver Contract"]
    end

    subgraph "Off-Chain Services"
        VN[Verifier Network]
        EX[Executor<br/>Gas Provider]
    end

    U -->|Initiates + Pays Gas| SENDER
    SENDER -->|Message| TL_A
    TL_A -->|Event: Message sent| VN
    VN -->|Proof: Message verified| TL_B
    TL_B -->|Message ready| EX
    EX -->|Monitors and Executes<br/>Uses own gas| TL_B
    TL_B -->|Delivers Message| RECEIVER
```

<br />

1. **Send** on Chain A: User calls method, contract updates state and notifies transport layer
2. **Notify**: The transport layer notifies the verifier network to produce proof/attestation of what happened on A
3. **Mark Verified**: Verifier network marks message as verified in Chain B's transport layer
4. **Detect**: Executor detects verified message ready for delivery
5. **Deliver & Execute**: Executor calls transport layer to deliver message to destination contract

## See Also

* [Glossary](./glossary) — canonical terms used throughout
* Module 2: [Crosschain Verification & Interface Issues](./interface-coupling-problems)
* Module 3+: [Protocol‑specific implementation details](./layerzero-protocol-architecture)