# ERC-7786: Cross-Chain Messaging Gateway

Source: https://www.eipsfordesigners.com/standards/ERC-7786
Agent brief: https://www.eipsfordesigners.com/standards/ERC-7786/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-7786
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Cross-Chain |
| Journey stages | Executing Transactions |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-7786 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-7786 |

## UX Impact

ERC-7786 defines gateway supportsAttribute() and sendMessage() calls plus the MessageSent source event and recipient receiveMessage(). Route discovery, health, status, destination post-processing, retry, and refunds remain adapter/provider-specific; send and receive IDs may differ.

## Summary

ERC-7786 standardizes gateway source/recipient message calls and attributes. Applications can send a message through a compliant gateway, while route discovery, bridge health, status, post-processing, retry, and refunds remain adapter/provider-specific.

## For Designers

- You can design UI around a single gateway interface for providers that implement it.
- You can standard message format enables consistent UX patterns.
- You can design UI that delivers swap bridge adapters without changing app logic.

## Applicability

### When to Use

- Your product addresses: each bridge has different integration requirements.
- Your users see inconsistent cross-chain UI across apps.
- Your UI should send through a gateway while exposing provider-specific route and status details.
- You are designing a bridge-agnostic transfer experience with visible states and recovery paths.

### When to Avoid

- The product never sends a cross-chain message or changes state across chains.
- No gateway source/recipient implementation is available for the flow.
- The selected provider exposes no route, status, or recovery data to the application.
- The flow only performs same-chain actions.

## Problems It Solves

### Each bridge has different integration requirements

Impact: critical

Old way: Custom code for LayerZero, different code for Wormhole, etc.

New way: Single gateway interface works with any compliant bridge

### Users see inconsistent cross-chain UI across apps

Impact: high

Old way: Every app shows bridges differently, different confirmations

New way: Standard message format enables consistent UX patterns

### Switching bridges requires code changes

Impact: high

Old way: Hardcoded bridge dependency, risky to change

New way: Swap bridge adapters without changing app logic

### No standard way to track cross-chain message status

Impact: medium

Old way: Each bridge has different tracking APIs

New way: MessageSent and send IDs provide a source-side record; status remains provider-specific

### Bridge failures handled inconsistently

Impact: medium

Old way: Some bridges auto-retry, some fail silently, some refund

New way: Provider-specific error, post-processing, retry, and refund handling

## Anti-Patterns

### Hiding which bridge is being used

Severity: critical

Users need to know for troubleshooting and trust

Instead: Show bridge name with link to their status page

### No status updates during bridging

Severity: critical

Users anxious when large value transfers show no progress

Instead: Real-time progress with stage indicators and ETA

### Abandoning users when messages fail

Severity: critical

Stuck funds cause panic and support tickets

Instead: Clear recovery UI with retry and refund options

### Auto-selecting bridge without explanation

Severity: high

Users surprised by speed or cost differences

Instead: Show why this bridge was chosen (price/speed/security)

### Not showing estimated completion time

Severity: medium

Users don't know if 5 minutes or 5 hours

Instead: Clear ETA based on bridge historical performance

## UI Components

### CrossChainProgress

Visual progress indicator for cross-chain messages
States: pending, confirming, relaying, executing, complete, failed
Props: sourceChain, destChain, currentStage, estimatedTime

### BridgeSelector

Choose between available bridge routes
States: loading, available, comparing, selected
Props: routes[], sortBy, onSelect

### MessageStatusPoller

Auto-updating status component
States: polling, updated, complete, error
Props: messageId, pollInterval, provider

### BridgeHealthBadge

Quick status indicator for a bridge
States: healthy, degraded, down, unknown
Props: bridgeName, status, lastCheck

## Key Takeaways

- ERC-7786 = one interface for all cross-chain messaging
- Show which provider/bridge is used and identify the estimate source
- Provide status tracking through stages when the provider exposes it
- Build recovery UI only for provider-supported retry/refund actions

## UX Patterns

### Bridge-Agnostic Transfer

User picks destination, not bridge

User flow:

- User enters amount and destination chain
- Application/provider supplies available bridge routes
- Shows routes sorted by user preference and provider data
- User picks route (or accepts default)
- Single interface sends regardless of bridge

### Cross-Chain Message Tracker

Unified status view for provider data across selected bridge routes

User flow:

- User sends cross-chain message
- Redirected to status page
- Polls the provider or adapter for status updates
- Progress bar advances through stages
- Shows bridge-specific details where helpful

### Bridge Health Dashboard

Show provider-supplied bridge reliability and status

User flow:

- User views bridge dashboard
- Provider/adapter aggregates bridge health data
- Shows status, speed, and reliability metrics
- Alerts highlight any issues
- Helps user choose appropriate bridge

### Failed Message Recovery

Handle failed cross-chain messages when provider recovery exists

User flow:

- Message fails to deliver
- User sees notification of issue
- UI explains what happened clearly
- Offers retry or refund options only when the provider supports them
- Labels bridge-specific post-processing and recovery

## Technical Notes

ERC-7786 defines IERC7786GatewaySource.supportsAttribute(bytes4) and sendMessage(bytes recipient, bytes payload, bytes[] attributes) payable returns (bytes32 sendId), plus a recipient receiveMessage(bytes32 receiveId, bytes sender, bytes payload). It defines a MessageSent source event; status, destination invocation/post-processing, route discovery, health, retry, and refunds are out of scope. The send ID may be zero or differ from the receive ID.