ERC-6170 is a proposed Ethereum standard that defines a universal IMessageBridge interface for sending messages across blockchains. A dapp that integrates ERC-6170 can route messages through Hyperlane, LayerZero, Wormhole, Axelar, or any other compliant bridge without rewriting its integration logic. The EIP was authored by Wilson Cusack and submitted to the Ethereum Improvement Proposals repository in December 2022.
​

Before this standard, each bridge protocol exposed its own function signatures, parameter orderings, fee-payment patterns, and acknowledgment mechanisms. A dapp that wanted to support multiple bridges had to maintain one code path per bridge. ERC-6170 collapses those divergent ABIs into a single four-function interface, shifting bridge selection from a compile-time decision to a runtime configuration.
​

IMessageBridge is a Solidity interface consisting of four functions: sendMessage, estimateFees, getMessageFee, and receiveMessage. Any bridge that implements this interface can be swapped into a compliant dapp by changing one address. The interface is stateless from the dapp's perspective, meaning fee estimation and message dispatch happen through the same calls regardless of which bridge sits behind the contract.
​

The core of the interface is the sendMessage function, which accepts four parameters: toChainId (the destination chain as a uint256), message (arbitrary bytes payload), extraData (bridge-specific configuration packed as bytes), and a value field for native-token fee payment. The EIP-6170 specification intentionally leaves extraData unspecified to allow each bridge adapter to encode its own options, such as gas limits, execution parameters, or fallback behavior, without breaking the shared interface.
​

estimateFees returns a uint256 fee denominated in the native gas token of the source chain. This matters because cross-chain message fees vary by more than 10x across bridges depending on the destination chain, security model, and congestion. Exposing fee estimation through the same interface means a dapp can compare bridge costs at runtime before committing to a dispatch.
​

The receiveMessage function handles inbound delivery on the destination chain. It is called by the bridge adapter, not the dapp directly, and decodes the payload for the receiving contract. This separation keeps the receiving logic chain-agnostic: the dapp's receiver contract does not need to know which bridge delivered the message.
​

Bridge-agnostic messaging through ERC-6170 works by wrapping each bridge protocol in a thin adapter contract that translates the IMessageBridge function calls into the bridge's native ABI. The dapp holds a reference to an IMessageBridge address, not to a specific bridge contract. Changing the bridge is a matter of pointing that reference at a different adapter.
​

At dispatch time, the dapp calls sendMessage on the adapter. The adapter translates the call into the bridge's native format, for example calling Hyperlane's dispatch() or LayerZero's send(), and forwards the native-token fee. The Hyperlane messaging docs detail how its own interface accepts a destination domain ID and a bytes32 recipient, parameters that the ERC-6170 adapter encodes from the standard inputs. On the destination chain, the bridge delivers the payload to the adapter's receiveMessage function, which unpacks it and calls the dapp's receiver logic.
​

The extraData escape hatch handles the cases that do not fit the shared interface. Hyperlane's interchain security modules, LayerZero's adapterParams for destination-side gas airdrop, and Wormhole's consistency level for finality guarantees all live in extraData. A dapp that needs these features encodes them per-bridge before dispatch but does not expose this complexity to its own contract surface.
​

Without ERC-6170, a dapp integrates each bridge through its own proprietary interface, locking in that bridge at the contract level. Adding a second bridge requires new integration code, new auditing, and new deployment. ERC-6170 standardizes the boundary so the dapp code never changes when the bridge changes, only the adapter address does. The trade-off is that bridge-specific features must be encoded into extraData, which reintroduces bridge knowledge at the call site if advanced features are needed.
​

The table below summarizes the key dimensions across direct integration and an ERC-6170 adapter for four major bridge protocols.
​

The differences in native interface complexity are significant. Axelar's General Message Passing uses a string-based chain name rather than a uint256 chainId, which means an ERC-6170 adapter must maintain a mapping between the EIP-155 chain IDs used by the standard and Axelar's internal chain name registry. LayerZero v2 introduced a redesigned OApp framework that compiles to a different ABI than v1, so ERC-6170 adapters written for v1 are not forward-compatible without an upgrade.
​

ERC-6170 is most valuable for protocols that need bridge redundancy, bridge upgradability, or multi-bridge routing. A cross-chain governance system that wants to fall back to a different bridge if one is down can switch adapters without redeploying its governor contract. A cross-chain token bridge that wants to route through the cheapest available bridge at dispatch time can query estimateFees across multiple adapters and pick the lowest.
​

Cross-chain governance is one of the most active use cases. Protocols like Compound and Uniswap already manage treasury and parameter-setting decisions that must propagate across multiple chains. With a direct-bridge integration, a governance executor on Ethereum that controls contracts on Arbitrum, Optimism, and Base must maintain three separate bridge-specific integrations. An ERC-6170-compliant executor maintains one interface contract and three adapter addresses, reducing upgrade surface area significantly.
​

Cross-chain automated market makers and yield aggregators also benefit. A vault on Ethereum that deploys liquidity to high-yield pools on Polygon or Avalanche via message-triggered transactions needs to send and receive messages as part of its rebalancing logic. The Connext research on cross-chain AMMs documents how message latency and reliability differences between bridges translate directly into rebalancing lag and slippage. ERC-6170's fee-estimation function gives the vault operator a way to model that cost before choosing a bridge for a given rebalancing cycle.
​

NFT bridges and gaming applications that move assets across chains also fit the pattern. A game that mints items on one chain and allows players to use them on another must send provenance messages reliably. If the primary bridge experiences downtime, an ERC-6170-compliant game can switch adapters without pushing a contract upgrade to all players.
​

ERC-6170 remains at draft status in the Ethereum EIP process as of April 2026. The EIP pull request received substantive review comments around message ordering guarantees and the handling of failed deliveries, two areas the current specification does not fully resolve. The EIP was not assigned Final status, which means no bridge protocol has formally certified conformance with the standard.
​

Despite draft status, the design pattern has influenced several independent implementations. Biconomy's Hyphen bridge and the Socket interoperability layer both expose abstraction interfaces that resemble the IMessageBridge shape, with a single function accepting destination chain, payload, and fee parameters. The Socket Protocol documentation shows a performAction pattern that decouples the calling contract from the underlying bridge route, mirroring the ERC-6170 intent without citing the EIP directly.
​

The EIP's influence on the space is arguably larger than its adoption count, because it crystallized the design argument for bridge abstraction that later informed cross-chain intent standards including ERC-7683. Intent-based execution systems effectively generalize the ERC-6170 approach: instead of the dapp selecting a bridge adapter, a solver network selects the optimal route and executes the message, further decoupling the application from the transport layer.
​

ERC-6170's abstraction model directly maps to the routing layer Eco operates. Eco Routes dispatches cross-chain transfers through message-passing protocols including Hyperlane, abstracting the underlying transport from the application submitting the transfer. A dapp integrated with Eco can initiate a cross-chain stablecoin transfer without binding to a specific bridge protocol at the contract level, which is the same outcome ERC-6170 targets at the interface layer. For teams building on top of Eco that also handle arbitrary cross-chain messaging beyond transfers, ERC-6170-style adapters and Eco's transfer routing are complementary: transfers go through Eco, arbitrary messages go through whichever IMessageBridge adapter best fits the use case.
​

ERC-6170 is a draft EIP as of April 2026. No bridge protocol has formally certified conformance. The draft remains open for comment, particularly around message ordering and failed-delivery handling. Teams can implement the interface pattern now but should not treat the ABI as stable until the EIP reaches Final status. See the interoperability overview for context on how bridge standards evolve.
​

The ERC-6170 design allows a protocol to update its IMessageBridge address to a different adapter without touching the dapp contract. If a bridge goes offline, the operator deploys or points to a working adapter. This swap takes one transaction on the source chain. Messages in flight when a bridge goes offline may be lost or stalled depending on the bridge's delivery guarantees, which ERC-6170 does not standardize.
​

ERC-6170 is a Solidity interface and applies only to EVM-compatible chains. Bridges that connect EVM chains to Solana, Cosmos, or non-EVM environments can expose an ERC-6170-compliant contract on the EVM side while handling the cross-ecosystem translation internally. The receiving side on non-EVM chains uses the bridge's native delivery mechanism, not ERC-6170.
​

The estimateFees function returns a fee in the source chain's native token before dispatch. The dapp passes this fee as msg.value when calling sendMessage. If the fee passed is below the bridge's required minimum, the adapter should revert. Fee calculation varies by bridge and by destination chain gas price; the estimate is not binding and may drift between the estimate call and the dispatch call in high-congestion conditions.
​

ERC-6170 standardizes how a dapp calls a bridge to deliver a message it has already composed. ERC-7683 standardizes a higher-level intent format that describes a desired outcome and lets solvers choose the bridge and execution path. The two standards are complementary: an ERC-7683 solver could use an ERC-6170 adapter internally to dispatch the message leg of an intent settlement. See the blockchain interoperability explainer for how these layers fit together.
​

Sources and methodology. EIP text and status verified against the Ethereum EIPs repository on April 30, 2026. Bridge interface documentation sourced from Hyperlane docs, LayerZero docs, Axelar docs, and Socket docs. No market figures from live-data snapshot were required for this article.
​