|
| 1 | +# Cross-chain token standards and ERC-7786 |
| 2 | + |
| 3 | +## A standard everyone needs, but that no one adopts |
| 4 | + |
| 5 | +ERC-7786 defines a standard interface for cross-chain messaging. The standard starts from the following idea: if it were possible for all bridges to expose the same API, developers could switch providers without rewriting their contracts and building bridge-agnostic applications would become practical. |
| 6 | + |
| 7 | +Cross-chain token standards tried to do the same for token portability. Both xERC20 (driven by Connext and Wonderland) and ERC-7802 (proposed by Optimism and Uniswap) allow a token to work with any bridge without being tied to a single one. |
| 8 | + |
| 9 | +**So, what is the difference?** These standards differ in how much control they give the issuer. xERC2 offers granular control with bridge whitelisting and minting rate limits per bridge. On the other hand, ERC-7802 limits itself to the minimum, two `crosschainMint` and `crosschainBurn` functions. |
| 10 | + |
| 11 | +All these standards solve real problems. However, none achieved significant adoption. |
| 12 | + |
| 13 | +## The timing was not right |
| 14 | + |
| 15 | +Just like the lesson learned in our section [ERC-5792 and EIP-7702: a retrospective](https://www.notion.so/ERC-5792-and-EIP-7702-a-retrospective-30a9a4c092c7805c889cd0be52b5bcee?pvs=21) , the mistake of looking for a solution to a problem already solved repeats itself here. It is a game theory problem. Each bridge already has its own standard working and being the first to adopt a unified one means opening the door for your clients to migrate to the competition. What is interesting about this scenario is that staying put has no cost, if this mentality is adopted by the entire ecosystem, the result is a standard with very low adoption. |
| 16 | + |
| 17 | +Every major messaging protocol has already deployed its own interface, put contracts on dozens of chains and onboarded clients. LayerZero supports over [150 chains](https://layerzeroscan.com/). Wormhole has processed over [70B in cumulative volume](https://messari.io/report/wormhole-scaling-interoperability-across-chains-and-institutions). Axelar, Hyperlane and Chainlink CCIP each carved out their own segment with specialized security models and tooling. |
| 18 | + |
| 19 | +From a 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 contracts are already in production and some are immutable. Migrating to a new standard would mean disrupting their entire operation for something that offers them no tangible benefit. |
| 20 | + |
| 21 | +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. |
| 22 | + |
| 23 | +## Different players, different incentives |
| 24 | + |
| 25 | +This problem does not refer to coordination, it is a problem of incentive structure. |
| 26 | + |
| 27 | +From a dApp's perspective, being tied to a single bridge is a risk, and ERC-7786 allows them to have optionality. |
| 28 | + |
| 29 | +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. |
| 30 | + |
| 31 | +Given that ERC-7786 exists, the rational response for any individual bridge that intends to keep its clients is not to push for the adoption of this type of standards. Being one of the first to push for this change means risking client loss without gaining anything the bridge does not already have. |
| 32 | + |
| 33 | +## Abstraction alone does not drive adoption |
| 34 | + |
| 35 | +Even if timing and incentives aligned, ERC-7786 faces another problem. It wraps existing bridges but does not add any additional layer. Every major messaging protocol already provides its own verification layer. |
| 36 | + |
| 37 | +Previously, aggregation projects like [Glacis](https://www.glacislabs.com/), [Hashi](https://crosschain-alliance.gitbook.io/hashi) and xERC20 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](https://www.glacislabs.com/) and [Hashi](https://crosschain-alliance.gitbook.io/hashi). |
| 38 | + |
| 39 | +Displacing already functional standards, even if fragmented, must offer real improvements in security and/or incentives that justify the migration. |
| 40 | + |
| 41 | +## Token standards tell the same story |
| 42 | + |
| 43 | +The same dynamics that blocked ERC-7786 appear in cross-chain token standards. Each protocol built its own framework ([OFT](https://docs.layerzero.network/v2/concepts/applications/oft-standard), [NTT](https://wormhole.com/products/native-token-transfers), [ITS](https://www.axelar.network/its), [CCT](https://docs.chain.link/ccip/concepts/cross-chain-token), Warp Token) and the open standards failed to displace them. |
| 44 | + |
| 45 | +[Adoption numbers](https://messari.io/report/layerzero-scaling-stablecoin-issuers-with-the-oft-standard) can be misleading. As of May 2025 it would seem that OFT is the dominant standard with "$150B supported". But if we look at that number more closely, $138.6B come from a single partnership with Tether's USDT0 through a lock-and-mint wrapper and native OFTs represent only 4.6% ($11.4B). The fragmentation persists. |
| 46 | + |
| 47 | +## What would need to change? |
| 48 | + |
| 49 | +ERC-7786 and the token standards failed for overlapping reasons. Nobody needs to change when existing solutions work well enough, nobody can change when the standard depends on others that are not ready and nobody wants to push for change when incentives punish the first bridge to do so. |
| 50 | + |
| 51 | +Five lessons emerge from this: |
| 52 | + |
| 53 | +- Incentive alignment matters more than technical elegance. These standards needed bridges to adopt them, but bridges had no strong reason to do so. Future standards must offer something to the actors whose adoption they depend on, not just those who benefit from the abstraction. |
| 54 | +- Third-party bridges will not adopt these standards voluntarily. But if Ethereum moves toward native rollups, based rollups and synchronous composability, ERC-7786 or a similar standard could find a natural place in that infrastructure. A recent [ERC-7965](https://eips.ethereum.org/EIPS/eip-7965) (proof-based broadcasting) attempts to address the "abstraction without added value" problem by adding trustless verification through cryptographic proofs on top of ERC-7786, though this deepens the dependency chain further. |
| 55 | +- Dependency chains multiply friction. If one standard requires another to function, each unfinished dependency gives adopters a reason to wait. |
| 56 | +- Abstraction alone does not drive adoption. Adding a new layer must introduce real value beyond portability, whether that is security guarantees, economic incentives or protocol-level enforcement. |
| 57 | +- Demand must exist before a standard can take hold. Today, very few apps depend on multiple bridges simultaneously. Tokens that go multichain tend to commit to a single bridge. The largest players vertically integrate — Circle with [CCTP](https://www.circle.com/es-la/cross-chain-transfer-protocol) and Tether with [USDT0](https://usdt0.to/) control both the token and the bridging infrastructure, account for a large share of bridge volume and have an altogether different business structure. |
| 58 | + |
| 59 | +## Appendix |
| 60 | + |
| 61 | +### Why proprietary bridges exist |
| 62 | + |
| 63 | +Canonical bridges inherit all of Ethereum's security but they are slow, around 7 days for optimistic rollups and between 1-5 hours for ZK rollups. Proprietary messaging protocols exist because they trade trust assumptions for speed: |
| 64 | + |
| 65 | +| Protocol | Typical latency | |
| 66 | +| --- | --- | |
| 67 | +| [Circle CCTP v2](https://www.circle.com/blog/cctp-v2-the-future-of-cross-chain) | seconds (Fast Transfer, pre-finality) or standard | |
| 68 | +| [LayerZero](https://layerzero.network/blog/the-lzread-deep-dive) | source finality + Decentralized Verifier Network (DVN) verification + execution | |
| 69 | +| [Wormhole](https://wormhole.com/docs/products/reference/consistency-levels/) | source finality + Guardian consensus | |
| 70 | +| [Axelar](https://docs.axelar.dev/learn/txduration/) | source finality + validator confirmation | |
| 71 | +| [Hyperlane](https://eco.com/support/en/articles/11813938-hyperlane-warp-routes-guide-complete-cross-chain-token-bridge-tutorial) | source finality + Interchain Security Module (ISM) verification + 1 block | |
| 72 | +| [Chainlink CCIP](https://docs.chain.link/ccip/ccip-execution-latency) | source finality + Decentralized Oracle Network (DON) relay | |
| 73 | + |
| 74 | +Latency for almost all of them depends on source chain finality. Circle CCTP v2 is the exception with its [Fast Transfer](https://www.circle.com/cross-chain-transfer-protocol) mechanism. |
| 75 | + |
| 76 | +Not all protocols can afford a custom bridge like Circle with CCTP. That is why multiple protocols built their own token framework to address this problem: OFT (LayerZero), NTT (Wormhole), ITS (Axelar), Warp Token (Hyperlane) and CCT (Chainlink CCIP). |
| 77 | + |
| 78 | +On the other hand, xERC20 and ERC-7802 are open standards where the issuer retains sovereignty. |
| 79 | + |
| 80 | +Finally, although custom verification mechanisms offer benefits, default configurations remain the most widely used in practice. Each additional verification scheme introduces a potential point of failure. |
| 81 | + |
| 82 | +## Sources |
| 83 | + |
| 84 | +- [ERC-7786 Specification (GitHub)](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-7786.md) |
| 85 | +- [ERC-7786 Official EIP](https://eips.ethereum.org/EIPS/eip-7786) |
| 86 | +- [ERC-7786 Documentation Site](https://www.erc7786.org/) |
| 87 | +- [ERC-7930: Interoperable Addresses](https://eips.ethereum.org/EIPS/eip-7930) |
| 88 | +- [CAIP-350: Binary Serialisation](https://chainagnostic.org/CAIPs/caip-350) |
| 89 | +- [Ethereum Magicians Discussion](https://ethereum-magicians.org/t/erc-7786-cross-chain-messaging-gateway/21374) |
| 90 | +- [OpenZeppelin Community Contracts — Cross-chain Docs](https://docs.openzeppelin.com/community-contracts/crosschain) |
| 91 | +- [OpenZeppelin & Axelar OpenBridge Announcement](https://www.axelar.network/blog/erc-7786-openbridge) |
| 92 | +- [LiFi — Comparing Token Frameworks](https://li.fi/knowledge-hub/comparing-token-frameworks/) |
| 93 | +- [xERC20 (Connext)](https://www.connext.network/xerc20) |
| 94 | +- [Arbitrum Interoperability Post](https://medium.com/offchainlabs/bringing-interoperability-to-arbitrum-and-ethereum-ba97ea99d9ff) |
| 95 | +- [@kramnotmark on ERC-7786](https://x.com/kramnotmark/status/1907508307541295312) |
| 96 | +- [LayerZero — The Default is Many Chains](https://layerzero.network/blog/the-default-is-many-chains) |
| 97 | +- [Messari — LayerZero Stablecoin Report](https://messari.io/report/layerzero-scaling-stablecoin-issuers-with-the-oft-standard) |
| 98 | +- [Messari — Wormhole Report](https://messari.io/report/wormhole-scaling-interoperability-across-chains-and-institutions) |
| 99 | +- [Circle CCTP v2](https://www.circle.com/blog/cctp-v2-the-future-of-cross-chain) |
| 100 | +- [Axelar Latency](https://docs.axelar.dev/learn/txduration/) |
| 101 | +- [Wormhole Consistency Levels](https://wormhole.com/docs/products/reference/consistency-levels/) |
| 102 | +- [LayerZero Scan](https://layerzeroscan.com/) |
| 103 | +- [Chainlink CCIP Directory](https://docs.chain.link/ccip/directory/mainnet) |
0 commit comments