ERC-5164: Cross-Chain Execution
Cross-chain apps keep running into the same awkward reality: every bridge “speaks” a different API, even when the goal is identical, execute a call on another EVM chain. ERC-5164 (also published as EIP-5164) is a proposal to standardize that core primitive: dispatch a message on chain A, execute it on chain B, without forcing every protocol to hand-roll custom adapters for each bridge. It is not trying to replace bridges. It is trying to make them interchangeable at the application layer.
TL;DR
ERC-5164 defines a simple, shared interface for cross-chain execution across EVM networks. It splits the system into a MessageDispatcher (source chain) and a MessageExecutor (destination chain), connected by whatever transport layer (bridge or messaging layer) you trust. The practical win is portability: the same app-side code can work across multiple transports, instead of rewriting logic for each bridge API.
What is ERC-5164 and its Motivation?
ERC-5164 is a Standards Track ERC that “defines an interface that supports execution across EVM networks.” In plain terms: it standardizes how a contract on one EVM chain can request a contract call on another EVM chain, using a two-part pattern:
The actual transport can be a native bridge, a third-party bridge, or a messaging network, ERC-5164 does not dictate that choice.
Status
The EIP page lists ERC-5164 as Last Call, created 2022-06-14, with a Last Call deadline of 2023-11-15, and still presented as being in peer review on the canonical EIPs site.
What Happens During Last Call:
Motivation
Many Ethereum protocols need to coordinate state across multiple EVM chains, but bridge APIs are inconsistent, i.e., forcing custom integrations with different security and UX properties. ERC-5164 proposes a small common interface to increase code reuse and standardize how apps “speak” cross-chain execution.
That motivation is extremely practical: protocols scale to multiple chains, then discover their cross-chain control plane becomes a spaghetti bowl of one-off adapters.
Origins and Authors
ERC-5164 is authored by:
A notable data point from Uniswap governance discussion is that ERC-5164 was described as being developed “in partnership with Hop Protocol and others,” framing it explicitly as a bridge-agnostic execution standard rather than a new bridge product.
Technical Architecture
This ERC is mostly formed by two important interfaces, that we are going to review here.
MessageDispatcher (source chain)
A dispatcher is responsible for sending a message toward a destination chain. The EIP requires:
Core method:
function dispatchMessage(
uint256 toChainId,
address to,
bytes calldata data
) external payable returns (bytes32 messageId);
And the event:
event MessageDispatched(
bytes32 indexed messageId,
address indexed from,
uint256 indexed toChainId,
address to,
bytes data
);
MessageExecutor (destination chain)
An executor performs the actual destination call. The EIP requires:
The most distinctive (and important) part is calldata augmentation:
The executor must append packed (messageId, fromChainId, from) to calldata so the receiver contract can verify the origin.
Concrete call shape is to.call(abi.encodePacked(data, messageId, fromChainId, from));
The executor also emits event MessageIdExecuted(uint256 indexed fromChainId, bytes32 indexed messageId);
And defines standard errors like MessageIdAlreadyExecuted and MessageFailure to normalize failure handling.
Because the executor appends origin metadata to calldata, receiver contracts need a consistent way to unpack and authenticate the real origin. The PoolTogether / GenerationSoftware reference implementation explicitly calls this out and recommends inheriting an ExecutorAware.sol helper to decode the appended sender.
This is where the standard quietly upgrades safety: it nudges app developers into verifying (fromChainId, from) rather than trusting msg.sender on the destination chain.
Bridge-agnostic by Design
ERC-5164 intentionally does not define:
That’s the point: the interface stays stable while transports compete and evolve. The EIP itself warns that “bridge trust profiles are variable,” and users must understand security depends on the implementation.
Real implementations and ecosystem usage
There are some real implementations by PoolTogether and others, making this ERC a working product for the Ethereum and EVM ecosystem.
PoolTogether / Generation Software Wrappers
A widely referenced implementation is the ERC-5164 wrapper set from PoolTogether / GenerationSoftware. Their README states it includes implementations for:
…and that they use “native” bridge solutions.
It also documents a key real-world nuance: Arbitrum requires an additional “process” step where an EOA submits a transaction to process a previously dispatched message, splitting dispatch into two actions (dispatchMessage then processMessage).
PoolTogether Protocol Usage Example
On-chain code for PoolTogether-related contracts includes explicit ERC-5164 usage patterns (for example, relaying RNG auction results across chains “through the 5164 message dispatcher”), illustrating the “bridge + execute” control plane idea in production-style contracts.
Pontis (ETHGlobal showcase)
The ETHGlobal project “Pontis” describes itself as “an NFT bridge implementing the EIP5164 adapter for Hyperlane,” enforcing ERC-5164 interfaces, so messages can be dispatched on the source chain and executed on remote chains.
This is a great example of the intended modularity: Hyperlane is the transport, ERC-5164 is the app-facing interface.
Hop Protocol Messaging
In Uniswap governance discussion, ERC-5164 is directly associated with Hop’s roadmap, with the claim that Hop v2 messaging would include ERC-5164 support. Separately, Hop’s own governance forum described building a “Core Messenger” module as part of a modularized Hop stack. Even if individual module details evolve, the meta-signal is clear: teams working on cross-chain messaging primitives viewed ERC-5164 as a viable standard interface layer.
Uniswap Governance Attention
Blockworks reported that Uniswap’s Bridge Assessment Committee evaluated “bridge-agnostic solutions,” explicitly listing ERC-5164 alongside other approaches, reflecting that major protocols were at least seriously considering standardized execution interfaces as part of their cross-chain strategy.
How ERC-5164 can help the EVM ecosystem
Less adapter spaghetti, more portable cross-chain apps Most cross-chain systems fail at the boring layer: integration overhead. ERC-5164 reduces that by giving apps a stable “send message, execute there” interface, so switching transports is closer to a configuration change than a rewrite. The result is a more competitive bridge market because protocols are less locked-in by bespoke APIs.
Standardized observability for cross-chain execution
Returning messageId and emitting MessageIdExecuted makes cross-chain actions indexable in a uniform way. That is not just nice for dashboards, it is safety infrastructure for operational monitoring, incident response, and user support when cross-chain actions are delayed or retried.
Cleaner security posture for receivers
The calldata append pattern forces receivers to confront provenance. Instead of guessing how a given bridge exposes “origin sender,” the receiver has a normalized input: (fromChainId, from) and a messageId for replay protection. That consistency is exactly how you avoid subtle “works on Bridge A, breaks dangerously on Bridge B” authentication bugs.
Why This Matters for Cross-chain Aggregators like Rango
Aggregators already solve a hard problem: choosing routes across liquidity and bridges. But the next frontier is actions, not just asset movement. ERC-5164 supports a more composable cross-chain UX where a route can end with a contract call on the destination chain that finalizes the user’s intent.
Concrete examples where ERC-5164-style execution becomes useful:
The key is separation of responsibilities: Aggregators systems, like Rango Exchange, can focus on route intelligence, while the execution layer becomes standardized enough to plug into multiple transports with less bespoke surface area.
Conclusion
ERC-5164 is one of those deceptively small proposals that can shift a whole ecosystem’s ergonomics. It does not promise a magic bridge. It promises something more realistic: a shared contract-to-contract execution interface across EVM chains that bridges and messaging systems can implement, so applications stop rebuilding the same adapter layer forever.
If you believe the EVM world is going to stay multi-chain (spoiler: it will), then standards like ERC-5164 are how we keep that world from turning into an integration junkyard. The bridge layer can keep innovating, but the application layer gets to breathe.
Resources and Further Readings
Frequently asked questions
Check out most commonly asked questions, addressed based on community needs. Can't find what you are looking for?
Contact us, our friendly support helps!
What’s the difference between ERC-5164 and “a bridge”?
A bridge (or messaging layer) is the transport mechanism that actually moves proofs/messages across chains. ERC-5164 is the application-facing standard interface that a transport can implement so that apps call dispatchMessage(...) and receive authenticated execution on the destination chain through a known shape. That distinction matters because it lets protocols upgrade or diversify their transports without rewriting core app logic each time.
How can I migrate an existing cross-chain dApp to ERC-5164 without rewriting everything?
A practical migration path is to treat ERC-5164 as a thin compatibility layer rather than a full rewrite of your cross-chain stack. You start by deploying one or more MessageDispatcher + MessageExecutor pairs that internally call the bridge SDK you already use, effectively wrapping your current transport in the ERC-5164 interface. Existing contracts that previously spoke directly to a bridge can be incrementally refactored to call dispatchMessage instead, while destination-side logic is moved into “executor-aware” receivers that unpack origin metadata and apply the same checks you already had. Over time, you can add more dispatchers wired to other bridges or native messaging layers, letting you A/B test transports or route by cost/security, all while keeping your app-side code pointed at the same interface. This staged approach is how projects like PoolTogether have been able to plug multiple bridges into a unified EIP-5164-based architecture without throwing away their existing integrations.
Why would a protocol choose ERC-5164 instead of a cross-chain messaging SDK?
Because the SDK might be great, but it is still a form of lock-in. ERC-5164 aims to standardize the “execute on remote chain” primitive so multiple messaging systems can compete behind the same interface. You still choose transports based on security and UX, but you do it with less re-integration cost — and you can even support multiple transports in parallel more cleanly.
