Skip to main content

ERC-7786

Useful in theory, unused in practice​

ERC-7786 defines a standard interface for cross-chain messaging. Its core primitive is a single function called sendMessage that takes a destination chain, a recipient and a message. The bridge handles delivery. If every bridge exposed this same API, developers could switch providers without rewriting their contracts.

This sounds like a useful primitive, but the standard has not gained traction. The following sections explore why.

The timing was not right​

As with ERC-5792 and EIP-7702: a retrospective, the primary developer-facing problem has already been solved. Each bridge already has its own working implementation, and there is little reason to add compatibility with a generalised standard that does not yet have wide adoption. Staying put has no cost, and if this mentality is adopted by the entire ecosystem, the result is a standard with very low adoption.

Every major messaging protocol has already deployed contracts on dozens of chains and onboarded clients. LayerZero supports over 150 chains. Wormhole, Axelar, Hyperlane and Chainlink CCIP each carved out their own segment with specialized security models and tooling.

From an application developer's perspective, these protocols expose fairly similar interfaces and capabilities. The differences come down to specific features, security models and gas optimizations. Most of their integrations are already in production and some are immutable. Migrating to a new interface would mean disrupting their entire operation for something that offers them no tangible benefit.

Technically superior standards routinely fail to displace incumbents that work well enough. An example of this can be seen outside of the blockchain space. IPv4 continues to dominate the internet despite IPv6 being available for decades.

Different players, different incentives​

Beyond inertia, there is an incentive problem.

From an application's perspective, being tied to a single bridge is a risk, and ERC-7786 allows them to have optionality.

For a bridge, the calculus is different. A cross-chain messaging protocol might prefer to maintain the friction that retains its clients. If migrating to another bridge becomes easy, retaining clients becomes harder.

Abstraction alone does not drive adoption​

Even if timing and incentives aligned, ERC-7786 faces another problem. It wraps existing bridges but does not add any additional capabilities. Every major messaging protocol already provides its own verification layer.

Previously, aggregation projects like Glacis and Hashi had the same adoption problems. The problem is that a standard interface over already functional solutions does not generate incentives for adoption. On the other hand, it can end up introducing integration risk, as was the case with Glacis and Hashi.

Displacing already functional standards, even if fragmented, must offer real improvements in security and/or incentives that justify the migration.

What would need to change?​

ERC-7786 attempted to carve out a place in a space where incumbents already provide sufficiently-functional solutions to entrenched users. Offering only abstraction wasn't enough to convince bridges and asset issuers - another reminder that standards can't take adoption for granted.

The status quo for message passing is unlikely to change, without some external shock. This could be triggered by events, such as the recent KelpDAO and LayerZero incident, which might prompt incumbents to revisit their security assumptions. Or it could be driven by new entrants shaking up the market, as more assets and activity come onchain. In either case, the adoption of ERC-7786 will be determined by markets more than working groups.

Sources​