# Agent instructions

You are advising on UX and product design for **ERC-5164: Cross-Chain Execution**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- Treat **MUST NOT** items as editorial guardrails. Check their applicability and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-5164: Cross-Chain Execution

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

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

## UX Impact

ERC-5164 defines MessageDispatcher.dispatchMessage() and destination MessageExecutor interfaces. The executor appends message context before invoking the target; bridge selection, timing, status, ordering, security, retries, and refunds are provider/application-specific.

## Summary

ERC-5164 standardizes message dispatch and destination execution interfaces for cross-chain applications. A bridge adapter can carry a dispatcher message to a destination executor, while bridge selection, timing, security, status, and recovery remain provider-specific.

## For Designers

- You can design UI around the dispatcher/executor interface while disclosing the selected bridge's behavior.
- You can design UI that delivers consistent cross-chain action UI.
- You can design UI that delivers dispatchMessage() triggers remote execution.

## Applicability

### When to Use

- Your product addresses: each bridge has different interface.
- Your product addresses: cross-chain UX is confusing.
- The flow should deliver: a dispatcher message reaches a destination executor through a selected bridge adapter.
- You are designing a cross-chain action experience with visible states and recovery paths.

### When to Avoid

- The product never dispatches messages or state across chains.
- The flow has no source/destination chain context to display.
- The selected bridge/application provides no status or recovery data to surface.
- The product only performs same-chain actions.

## Problems It Solves

### Each bridge has different interface

Impact: critical

Old way: Learn Arbitrum bridge API, then Optimism, then Polygon...

New way: A common dispatcher/executor interface works across adapters that implement it

### Cross-chain UX is confusing

Impact: critical

Old way: Different UI patterns for each chain

New way: Consistent cross-chain action UI

### Can't execute contracts across chains easily

Impact: high

Old way: Manual bridging, then manual execution

New way: MessageDispatcher sends a message to a destination MessageExecutor, which invokes the target call

### Hard to track cross-chain transactions

Impact: high

Old way: Check source chain, then destination, manually

New way: The application can correlate dispatcher/executor observations with its bridge-specific tracking data

### Bridge-specific lock-in

Impact: medium

Old way: App only works with one bridge

New way: Swap bridge adapters without changing the application message interface

## MUST NOT (Anti-Patterns)

- **Not showing bridging time** (critical)
  - Why: User expects instant, gets confused by delay
  - Instead: Always show estimated time prominently

- **Hiding which chain user is on** (critical)
  - Why: User signs thinking they're on destination
  - Instead: Bold chain indicators at all times

- **Silent cross-chain failures** (critical)
  - Why: User thinks it worked, funds stuck
  - Instead: Explain the failed stage and show only bridge/application recovery actions that are actually available

- **No progress tracking after sign** (high)
  - Why: User doesn't know if it worked
  - Instead: Real-time progress through all stages

- **Auto-selecting bridge without showing** (medium)
  - Why: User can't make informed time/cost choice
  - Instead: Show bridge options with tradeoffs

## UX Patterns

### Cross-Chain Action

Execute action on another chain

User flow:

- User wants to stake on different chain
- Sees current chain and destination
- Views action journey (steps)
- Sees time and fee estimates
- Signs transaction on source chain
- Message bridged to destination
- Destination MessageExecutor invokes the target when the selected bridge/application delivers it

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

### Cross-Chain Transaction Tracker

Track message as it crosses chains

User flow:

- User initiates cross-chain action
- Sees progress through each stage
- Source chain confirmed first
- Bridge/application transit status is shown when available
- Destination execution is confirmed from the executor or provider
- Links to explorers for verification

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

### Bridge Selector

Choose which bridge to use

User flow:

- User needs to cross chains
- Views bridge options supplied by the application/provider
- Compares time, cost, security
- Selects preferred bridge
- Proceeds with cross-chain action

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

### Cross-Chain Error Handling

Show when cross-chain action fails

User flow:

- Cross-chain action fails on destination
- User sees where failure occurred
- Clear error explanation
- Explains whether the selected bridge/application offers recovery; message failure alone does not refund assets
- Shows only recovery options the provider actually supports

### Governance Cross-Chain

DAO votes execute on multiple chains

User flow:

- DAO proposal passes
- Execution begins on all chains
- User sees status per chain
- Each chain updates as executed
- New parameters active when complete

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

## UI Components

### CrossChainProgress

Multi-step progress for cross-chain tx
States: source-pending, bridging, destination-pending, complete, failed
Props: sourceChain, destChain, bridge, currentStep, timeRemaining

### BridgePicker

Select from available bridges
States: loading, ready, selected
Props: bridges[], selectedBridge, onSelect

### ChainPairIndicator

Visual showing source → destination
States: connecting, connected, error
Props: sourceChain, destChain, status

### MessageTracker

Track cross-chain message by ID
States: searching, found, in-transit, delivered, failed
Props: messageId, sourceChain, destChain, status

### CrossChainError

Display cross-chain failure with recovery
States: source-failed, bridge-failed, dest-failed
Props: error, failedStep, recoveryOptions[]

## Key Takeaways

- ERC-5164 = standard interface for cross-chain messaging
- Always show source chain, destination chain clearly
- Display provider-specific time estimates with their source
- Track source, delivery, and destination observations when available
- Handle failures with bridge/application-specific recovery options

## Technical Notes

ERC-5164 defines MessageDispatcher.dispatchMessage(uint256 toChainId, address to, bytes data) and a destination MessageExecutor. The executor appends messageId, fromChainId, and from to the destination calldata before invoking the target. It does not define a CrossChainReceiver.processMessage interface, bridge discovery, universal ordering, asset escrow, or refunds; timing, security, tracking, and recovery remain bridge/application-specific.

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-5164