# EIP-7786: Cross-Chain Messaging Gateway

Source: https://www.eipsfordesigners.com/standards/EIP-7786
Agent brief: https://www.eipsfordesigners.com/standards/EIP-7786/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-7786
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Last Call |
| Chain | both |
| Category | Cross-Chain |
| Journey stages | Executing Transactions |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-7786 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-7786 |

## UX Impact

Users interact with a unified cross-chain messaging interface that works across EVM and non-EVM chains without knowing which bridge is being used underneath. Design implications: abstract bridge selection behind the scenes or offer it as advanced option, design address input fields that handle different chain address formats (EVM vs Solana vs others), show message attributes as optional settings, display sender/recipient clearly with chain context. Design decisions: whether to expose bridge choice to users (simpler UX vs transparency tradeoff), how to visualize non-EVM addresses, whether to show post-processing steps (like gas payment) inline or as separate flow.

## Summary

EIP-7786 standardizes how apps send messages across chains. Instead of integrating separately with LayerZero, Wormhole, Axelar, etc., apps implement one interface. The standard abstracts bridge-specific details behind a common "gateway," so users get consistent UX regardless of which bridge routes their message. Developers integrate once, users switch bridges seamlessly.

## For Designers

- You can design UI that delivers single gateway interface works with any compliant bridge.
- 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 single gateway interface works with any compliant bridge.
- You are designing a bridge-agnostic transfer experience with visible states and recovery paths.

### When to Avoid

- Show bridge name with link to their status page.
- Real-time progress with stage indicators and ETA.
- Clear recovery UI with retry and refund options.
- The product never moves assets or state across chains.

## 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: Standard events and status checking interface

### Bridge failures handled inconsistently

Impact: medium

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

New way: Standard error handling and retry patterns

## 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, gateway

### BridgeHealthBadge

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

## On Monad

### Destination Finality

Ethereum: Arriving on Ethereum may need 15+ seconds finality

Monad: Messages to Monad finalize in under 1 second

Design implication: Fast final step—show quick completion animation

### Message Execution

Ethereum: Executing arrived message may cost significant gas

Monad: Cheap execution on Monad side

Design implication: Include execution cost in fee estimates

### Retry Speed

Ethereum: Retrying failed message can take time/gas

Monad: Fast, cheap retries on Monad

Design implication: Retry button can feel responsive

### Reserve Balance

Ethereum: May need ETH to execute arrived message

Monad: 10 MON reserve ensures accounts can always receive cross-chain messages

Design implication: Users won't be stranded receiving cross-chain messages

## Key Takeaways

- EIP-7786 = one interface for all cross-chain messaging
- Always show which bridge is used and estimated time
- Provide clear status tracking through all stages
- Build robust error handling with retry/refund options
- On Monad: fast finality makes receiving messages feel instant

## UX Patterns

### Bridge-Agnostic Transfer

User picks destination, not bridge

User flow:

- User enters amount and destination chain
- UI queries available bridges via gateway
- Shows routes sorted by user preference
- User picks route (or accepts default)
- Single interface sends regardless of bridge

Mockup registry key: `concept/bridge` (React UI on the live standard page).

### Cross-Chain Message Tracker

Unified status view for any bridge

User flow:

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

Mockup registry key: `concept/bridge` (React UI on the live standard page).

### Bridge Health Dashboard

Show bridge reliability and status

User flow:

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

Mockup registry key: `concept/bridge` (React UI on the live standard page).

### Failed Message Recovery

Handle and retry failed cross-chain messages

User flow:

- Message fails to deliver
- User sees notification of issue
- UI explains what happened clearly
- Offers retry or refund options
- Standard interface regardless of bridge

Mockup registry key: `concept/bridge` (React UI on the live standard page).

## Technical Notes

EIP-7786 defines a Gateway interface that abstracts bridge-specific implementations. Key components: send(destChain, receiver, message) for sending, messageStatus(messageId) for tracking, and standard events (MessageSent, MessageReceived, MessageExecuted). Bridge adapters implement the gateway interface, allowing apps to switch bridges by changing the adapter address.