Introduction

Ethereum’s roadmap prioritizes scaling through sub-blockchains called Rollups or generally, L2s. This approach has accelerated the scaling and mass adoption of Ethereum blockchain. However, the inherent nature of blockchains renders Rollups as isolated structures. As such, many of Rollups trying to scale Ethereum do so, but as fragmented structures with siloed data and liquidity. In conclusion, this roadmap has birthed a new problem called fragmentation.

Considerable research and development have gone into addressing fragmentation between and among EVM-based networks. Developers seek to solve the problem with canonical bridges, mint and burn bridges, and intent-based solutions. However, this far, there isn’t any exact solution to the fragmentation between Rollups.

This problem hits hard, especially regarding the basic ERC-20 transfers. ERC-7802, as an interface, seeks to facilitate authorized contracts to mint and burn tokens during cross-chain transfers. This article dives into the ERC-7802 standard and how it aims to solve the fragmentation problems in the Ethereum ecosystem.

Ethereum’s Evolution to a Rollup-centric Hub

In October 2020, Vitalik Buterin proposed to adopt a Rollup-centric scaling architecture. The proposed structure is similar to the shards that Ethereum relied on before, except each Rollup comes with a proprietary blockchain. The new system would have users undertaking a more scalable approach with their transactions happening on Rollups, where they are bundled together and executed before sending the transaction data back to the L1.

What makes Rollups different from L1s is that they deploy a management contract to L1 and then send the results, which may include transactions, state changes, and such other aspects, for the verification on L1. Validators on the L1, project the L2s' state changes and provide a security guarantee. This process defines how L2s benefit from the security of Ethereum.

However, dividing the only network to different blockchains makes Ethereum fragmented in terms of users and liquidity. This creates a challenge to achieve making it feel like one network amongst Rollup chains.

Biggest Challenge: Rollup Fragmentation

L2s have extended the Ethereum by scaling throughput, enabling new execution environments, lowering transaction costs, and reducing latency. However, creating isolated chains under the Ethereum L1 makes it fragmented as its global state has to be shared and changed among L2 solutions.

Whole process and structure change creates isolated blockchains that execute transactions on their chains and uses Ethereum L1 for validation and security purposes. This focus created a slightly big problem called fragmentation in liquidity, user experience, etc. in general: fragmentation. Also, this process breaks the composability in Ethereum.

Interoperability in Rollups are stated as enabling a transaction on one Rollup and updating the other one’s state, accordingly. It has to be seamlessly achieved between Rollups, although it is not pretty clear today. At the end, interoperability between Rollups meant ensuring transactions were finalized securely and quickly among. Relying on L1 about everything could be expensive, delayed, and meaningless.

After the roadmap change, big players earned big portions of the Rollup ecosystem pie. Examples like Arbitrum, Optimism, and Starknet launched their own Rollups with different technological variations. Some of them created ways to run and launch chains under their development stack for creating meshes and hubs.

There are various ways to solve the fragmentation problem, some of them noted as: Rollup-unification with hubs, chain abstraction, chain unification, multi-chain token standards, etc. Almost every Rollup approach/technology introduced their own solution for the fragmentation. Also, external companies created other ways to unify them, like confirmation layers.

Bridges

In current L2 bridging schemes, moving most of the assets between L2s is costly (if you want to work with native assets instead of wrapped assets). Also, L2 finality has to wait for the L1 finality. Which causes at least 12 to 15 minutes for exact transaction finality on L2s. Best way to achieve this problem in an AMM (Automated Market Maker) case is, fast bridging to the network which has greater liquidity on its AMM fork and bridge it back to the wanted chain.

Best bridge structure in Ethereum is based on solvers which are also referred to as intent-based, right now. These bridges have their own liquidity fragmentation problem based on their solvers’ liquidity but users can achieve seamless exchanges using these products.

• User authorizes the transaction that escrows tokens on the source chain,

• Tokens got locked in the escrow contract until the solver uses a cross-chain messaging protocol to verify that the solver paid the desired amount to user on the destination chain,

• Solver pays the user on the destination chain, with what user desired when it's done with the escrow transaction succession,

• After paying the user, the solver can claim the tokens from the escrow contract on the source chain depending on the latency of the used messaging protocol.

In this way, user liquidity can be swapped on a big Rollup in the matter of liquidity for better prices and then can be sent to a smaller Rollup.

The messaging process is usually achieved through L1. Since all L2s send data to L1, they can read the data from the L1 too.

Also, because everyone can deploy a bridge it increases the fragmentation.

The image above, refers to the current Ethereum bridging structure. Every bridge has their own bridge and they work with extensions related to token issuance. Also, native bridging is not possible in classical works. Users can get wrapped assets rather than native assets through bridging, in this method.

Rollup Meshes and Hubs

Rollup meshes and hubs are here for solving the interoperability problem among Rollups. Mesh approach stands for creating a trust between Rollups with direct trust connections, in order to achieve finality before finalized settlement.

The hub approach requires a shared layer to handle cross-chain messaging and interaction rather than doing it on the L1 itself.

In a mesh, each Rollup has to be trusted in each other. In order to a mesh getting connected, every independent Rollup in the mesh has to trust each other to be a mesh. However, in a hub, Rollups need to depend on the trust via a shared layer. The shared layer will act as a trust provider in this scenario.

OP Labs’s Superchain and Offchain Labs’s chain clusters can be examples to meshes. Matter Labs’s Elastic Chain, Polygon’s Agglayer, and Espresso’s confirmation network approach are some of the examples of hubs.

However, creating too many different approaches without exact success, multi-chain structure just became a mess. That’s why approaches to abstraction and shared-structures got developed and hyped these days.

Superchain

Superchain is an interoperable mesh which is being developed by OP Labs. With the Rollups among it, right now it may have the biggest portion of the Rollup mesh pie. Superchain is trying to build everything that a Rollup needs to be composable with others using the OP Stack developer tool.

With Superchain, desired output is to achieve a scalable state machine through horizontal scalability. Which means, adding more equipment but reducing the quality of it. In order to achieve the horizontal approach, chains need to be executed parallelly. This can be achieved through a mesh architecture for the need of knowing and executing each other's state in different chains.

As a conclusion, Superchain is a mesh that connects each OP chain with a shared bridge that enables messaging, shared security, and interoperability.

Elastic Chain

With ZKsync’s 3.0 upgrade, ZKsync’s L1 bridge reconfigured into a shared router contract to support the interoperability among ZK Chains. ZKsync’s own L2, ZKsync Era, becomes the first ZK Chain among others.

Elastic chain, enables recursive ZK proofs to parallelism for proof generation and constant-time verification of the computational outcome. Also, built on top of several parts:

• ZK Router, is responsible for managing the state of the network, handling chain registrations, facilitating critical interactions, and maintaining the shared liquidity for the network through smart contracts on Ethereum.

• ZK Gateway is a middleware between Ethereum and ZK Chains to facilitate interoperability. Enables the faster finality for low latency cross-chain bridging and optimizes the network interactions with Ethereum by combining proofs and state data.

• ZK Chains are the chains that are built/composed with the ZK Stack framework. These can be Rollups, Validiums, or Volitions. These are independent products but abstracted chains are interconnected through ZK Gateway and L1 smart contracts.

Based Rollups and Sequencing

In order to achieve synchronous composability (will explain it later in this article) within Ethereum and Rollups, it can be done through Ethereum itself. Based Rollups help and achieve liveness, simplicity, and economic alignment to Ethereum L1, through Ethereum L1.

This process is almost the same as shared sequencing but based sequencing is a version of shared sequencing with Ethereum alignment. Main idea is to use Ethereum’s proposer-builder mechanism and validator infrastructure instead of creating externals based on third-party solutions.

Coordinated Inter-Rollup Communication (CIRC) and Shared Sequencing

CIRC, inspired by Brendan Farmer’s article about aggregated blockchains, refers to solving fragmentation needs for shared state and liquidity across the chains. Tries to achieve the real-time message verification problem due to latency, with giving the verification work to Rollup operators. Additionally, Rollup operators have to check verifiable state proofs and fast BFT confirmations.

Espresso Systems is building a shared-sequencing protocol with an extension of CIRC. Shared sequencing is basically giving the block building process of different blockchains to the same entity (or network of same purpose entities).

Synchronous and Asynchronous Composability

Synchronous Composability

Synchronous composability is the interactions between different parts (ecosystem, applications, Rollups, blockchains) that occur within the timespan of a single block.

It also refers to the ability to execute a single and logical ACID (set of properties of transactions intended to guarantee data validity despite errors, power failures, etc.) transactions among applications deployed on different chains.

There are 3 components needed to achieve synchronous composability:

• Aggregated Settlement: Settlement of multiple transactions spanning multiple L2s occurs with a single L1 transaction. This property requires aggregating the settlement decisions among participant networks to atomic cross-chain transactions.

• Coordination: Coordination is the verification of cross-chain agreement before settlement. Since synchronous composition relies on the state and changes of it among participants, coordination is a must.

• Confirmation: In different “putting together” approaches (like meshes and hubs) doesn’t require trust for each Rollup to others, independently. Instead, they can trust a layer that becomes a middleware, which can be mentioned as a confirmation layer. As an example, shared sequencing uses independent networks for confirmation among participants that are built for this purpose and based sequencing uses Ethereum itself as a confirmation layer.

In conclusion, synchronous composability is an abstracted and shared state that gets updates synchronously and settled in a certain time period.

Asynchronous Composability

Asynchronous composability means the composability between products where interactions occur within an unbound amount of time. Asynchronous composability mostly used in bridges for achieving fast work and better UX.

At the end, if you’re building a mesh, a hub or another approach for abstracted Ethereum, you need the standardization for it to become compatible with others. This is where ERC-7802 comes into the game.

Introduction to ERC-7802: Cross-chain Token Interface for Mint & Burn Operations

Since the Rollup-centric Ethereum became a reality, fragmentation among Ethereum networks became a bigger problem. In this case, the worst part of the interoperability problem is the bridge architecture and mostly canonical bridges of each network. Each canonical bridge can’t access the mint and burn facilities of the native tokens. This problem caused lock and mint architectures and wrapped asset transfers. This was achieved through different interfaces and caused fragmentation in the interfaces.

ERC-7802 proposes to have one standardized interface among cross-chain processes for every canonical bridge to achieve the mint and burn functionality of tokens. It requires EIP-165 (standard interface implementation standard) and EIP-5679 (token mint and burn extension) as base standards.

This work is jointly proposed by developers from Optimism, Uniswap, and Wonderland teams to achieve a unified token standard.

Understanding ERC-7802

Difference Between Local - Cross-chain Mint & Burn

Token mint and burn methods were introduced with EIP-5679 on ERC-20, ERC-721, and ERC-1155. We call this the local mint and burn method. The transfer method already allows token exchange on common standards. However, minting and burning requires access to the token supply. Creating different extensions for these approaches can end with errors.

With EIP-5679, token mint and burn methods became native and secured from errors and unauthorized attempts.

Execution of EIP-5679 makes Ethereum greater in terms of security. However, to make Ethereum composable, we need bridging. Most of the bridges (including messaging bridges) do token transfers but people and developers started to need a mint and burn execution through bridges. They used messages including methods but this approach leads us to the problems of why we bring local mint and burn with EIP-5679.

With ERC-7802 standardization, cross-chain mint and burn for common standards will be enabled to specify the error solving and standardization.

Specifications

This proposal introduces a new interface as IERC7802, two (2) new methods as crosschainMint and crosschainBurn, and two (2) new events as CrosschainMint and CrosschainBurn.

Interface

EIP-165 is a detection extension standard for interfaces. IERC7802, which is the interface of this EIP, gets identified and specified through EIP-165.

type(IERC7802).interfaceId

Methods crosschainMint method works as the minting entry point for bridge contract. It enables cross-chain minting on mint and burn token sending events. It basically mints _amount of token to address _account.

function crosschainMint(address _account, uint256 _amount) external;

crosschainBurn works as the reverse twin of crosschainMint method in the thought of logic and approach. It works as a burning entry point for bridge contracts. It basically burns _amount of token from address _account.

function crosschainBurn(address _account, uint256 _amount) external;

Events

CrosschainMint is the execution work (a.k.a. trigger for the event) of crosschainMint method. This event got triggered when crosschainMint method call is successfully placed in the blockchain. As a must, _sender parameter has to be set for msg.sender parameter’s value.

event CrosschainMint(address indexed _to, uint256 _amount, address indexed _sender);

CrosschainBurn is a must trigger part for crosschainBurn call. Also, _sender parameter has to be set for msg.sender parameter’s value in this event method.

event CrosschainBurn(address indexed _from, uint256 _amount, address indexed _sender);

Considerations and Applications

Implementing ERC-7786 over ERC-7802

OpenZeppelin was working on ERC-7786 to achieve cross-chain messaging with this cross-chain messaging gateway standard. ERC-7786’s main purpose is to create a common interface standard to send and receive cross-chain messages, securely.

They were planning to combine ERC-7786 and ERC-7802 for reasons like interface standardization with minimality.

ERC-7802, defines an interface for this structural work. Besides this, OpenZeppelin thinks that ERC-7786 should be the messaging gateway for ERC-7802. They’re planning to directly create a code as crosschainTransfer that burns the tokens on the source and relays a mint instruction to the destination.

       function sendMessage(
        string calldata destinationChain,
        string calldata receiver,
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes32 outboxId);

        function executeMessage(
        string calldata messageId, // gateway specific, empty or unique
        string calldata sourceChain, // CAIP-2 chain identifier
        string calldata sender, // CAIP-10 account address (does not include the chain identifier)
        bytes calldata payload,
        bytes[] calldata attributes
    ) external payable returns (bytes4);

Companion of ERC-7786 and ERC-7802 creates a cross-chain mint&burn mechanism (ERC-7802) with a shared infrastructure (ERC-7786).

ERC-7281 (a.k.a. xERC-20) <> ERC-7802 Compatibility

ERC-7281 has different names as Sovereign Bridged Token standard and xERC-20. It is a standard for deploying cross-chain tokens, natively and proposed by Everclear’s (ex Connext) founder Arjun Bhuptani. It is a purpose-built cross-chain standard; it carries the same worries (like fragmented liquidity and security issues that come from un-standardized products) with other cross-chain standards.

ERC-7281 gives the complete ownership to token issuers and as an option, token issuers can give these rights to bridges by authorization. With this approach, the same token (native) is the one worked through while bridging. It means, mint and burn functionalities can be given to bridges for abstracted usage.

It achieves these by building an extension to ERC-20 that adds bridge whitelisting and rate limiting features. Bridges who are authorized, can mint through ERC-7281 contracts the same version of the token (can be native) and becomes unificated.

This gives all the power to token issuers. Bridges have to race for being whitelisted, or in other words, they need to compete in the security manner.

In specifications, ERC-7281 has a special contract called “lockbox”. This contract wraps the ERC-20 tokens and returns them under ERC-7281 standard with 1:1 ratio. When deploying a contract through ERC-7281, issuers whitelist bridge contracts. Also, in the case of whitelisted bridges getting hacked, there is a rate limit that can be decided by the issuer to control the mint amount by the bridges every day.

We can say there are similarities in functions and naming between ERC-7281 and ERC-7802. In order to prevent errors, we need to re-define and consider the composability between these standards.

There are different solutions for the composability:

Case 1: Non-deployed token, or upgradable ERC-7281

Both standard interfaces (IXERC20 and IERC7802) are fully compatible and can exist with the same contract in the ecosystem. Implementing both codes (mint/burn and crosschainMint/crosschainBurn) may introduce redundancy because they can both be callable by bridges. However, the logic of the abstraction approach can be shared. So, this won’t create another list of errors.

Case 2: Deployed, non-upgradable ERC-7281

Both standards aim to create an API standardization for interacting with tokens. All bridges should adapt to this standardization but since all of the bridges are not using these, ERC-7281 proposes using “Adapter” contracts.

Adapter works as a router, it implements and translates bridge’s required interface and calls to ERC-7281 compliant operations. It works like a proxy contract to the bridge.

Case 3: Deployed, non-upgradable tokens

The tokens which are deployed without IXERC20 or IERC7802 interfaces, a Lockbox contract can be the middleman for composability. Lockbox contract, wraps the existing ERC-20 into a compliant version. It directly enters the logic and works as lock and release.

Can’t we Just Use Burn and Mint for Everything?

Before the cross-chain mint and burn standardization proposals like ERC-7281 and ERC-7802, that was how systems worked. Bridges have the power rather than token issuers, and a lot of bridge hacks ended with extraordinary token issuance by hackers. Although, Maker’s Teleport approach works as burning and minting canonical DAI with their own structure, this only depends and works because of Maker’s own security process.

Old methods can still be in the game after these standardizations but they need to consider why we called these as “improvement” proposals.

Preventing and Overcoming Hacks

Again, today’s approach on relying on bridges depends on liquidity rather than security. Higher liquidity owned bridges got rights for token properties to achieve adoption and distribution. This comes with risks.

With rate limit definitions on ERC-7802, bridges will have the limits to mint and burn amount if they are authorized. This limit approach will help to solve the unauthorized token issuance related to malicious hacks.

Security

The biggest concern was composability with ERC-7281. As we mentioned earlier, their workflow is almost the same and they almost share the same logic. However, they have the composability between and achieve problems through sharing the same logic.

Applications

SuperchainERC20

The token standard for Superchain, named as SuperchainERC20, is using ERC-7802 interface to achieve asset interoperability within the Superchain ecosystem.

Superchain achieves asset interoperability with this standard while allowing tokens move among Superchain by burning and minting, securely. It also deprecates the wrapped assets transition in transferring in the ecosystem.

Superchain uses two components for this process as SuperchainERC20 and SuperchainTokenBridge. Basically, they initiate a message on the source chain and execute the equivalent message on the destination chain with SuperchainTokenBridge.

Conclusion

ERC-7802 emerges as a vital step forward in addressing the persistent fragmentation problem within Ethereum’s Rollup-centric architecture. As the ecosystem continues to expand across various L2s, achieving a seamless and standardized cross-chain experience becomes crucial. By providing a unified interface for mint and burn operations, ERC-7802 empowers canonical bridges and reduces the reliance on fragmented, ad-hoc bridging solutions that often lead to security vulnerabilities and poor user experiences.

Its compatibility with standards like ERC-7281, and integration potential with systems like ERC-7786, positions ERC-7802 as a foundational building block for the next generation of composable, secure, and interoperable Ethereum applications. As projects like Optimism’s Superchain and zkSync’s Elastic Chain adopt these standards, the vision of a fluid and cohesive Ethereum ecosystem becomes more achievable. Ultimately, ERC-7802 is not just an interface — it’s a stride toward a more abstracted, unified, and developer-friendly Ethereum.