ERC-7802: Token With Mint/Burn Access Across Chains

Allow authorized contracts to mint and burn token representations during crosschain transfers

Abstract

This standard introduces a minimal and extensible interface, IERC7802, for tokens to enable standardized crosschain communication. The interface consists of two functions, crosschainMint and crosschainBurn, which allow authorized bridge contracts to mint and burn token representations during crosschain transfers. These functions serve as the entry points for bridge logic, enabling consistent handling of token supply across chains.

The interface also defines two standardized events, CrosschainMint and CrosschainBurn, which emit metadata, including the target address, token amount, and caller. These events facilitate deterministic indexing and monitoring of crosschain activities by off-chain agents, such as indexers, analytics tools, and auditors.

IERC7802 is intentionally lightweight, ensuring minimal overhead for implementation. Its modular design enables extensibility, allowing additional features—such as mint/burn limits, transfer fees, or bridge-specific access control mechanisms—to be layered on top without modifying the base interface.

Motivation

All rollups and multiple important sidechains implement canonical bridges that embed their security into some part of the network’s core architecture. These bridges do not have mint/burn rights over original tokens, so they usually lock (unlock) liquidity on the native chain and then mint (burn) a non-equivalent representation on the other. Mint/burn is used because the native token is non-existent on that side, so they must create a new representation. However, each bridge implements a different interface for minting/burning on non-native chains.

This interface fragmentation is a massive issue in crosschain communication among chains via third-party bridges or future canonical solutions. At this point, it is clear that every bridge would benefit from a standardized interface for minted/burnt tokens.

There have been different attempts in the past to standardize token-bridging interfaces. However, third-party providers are also developing crosschain token frameworks. Each framework defines its features, like rate limits and fee switches, and implements its mint and burn versions. The resultant interfaces become highly specific, lacking naming conventions and structures.

The proposed interface includes the most relevant and minimal set of actions used by most of these standards. These actions also do not require any governance or owner participation, in contrast, for instance, to set rate limits.

Specification

This ERC introduces the IERC7802 interface.

Interface Identification

The interface identifier for IERC7802 is 0x33331994, calculated according to ERC-165 as the XOR of the function selectors of the two functions in the interface:

bytes4 constant INTERFACE_ID_IERC7802 = 
        bytes4(keccak256("crosschainMint(address,uint256)")) ^
        bytes4(keccak256("crosschainBurn(address,uint256)"));

or via Solidity as

type(IERC7802).interfaceId

Implementors MUST ensure that the supportsInterface method of ERC-165 returns true for this interface ID to indicate support for IERC7802.

Methods

crosschainMint

Mints _amount of token to address _account.

This function works as the minting entry point for bridge contracts.

function crosschainMint(address _account, uint256 _amount) external;

Implementations SHOULD emit Transfer(address(0), _to, _amount) on calls to crosschainMint to be compliant with ERC-20 invariants on token creation.

crosschainBurn

Burns _amount of token from address _account.

This function works as the burning entry point for bridge contracts.

function crosschainBurn(address _account, uint256 _amount) external;

Implementations might consider emitting Transfer(_from, address(0), _amount) on calls to crosschainBurn to be compliant with ERC-5679.

Events

CrosschainMint

MUST trigger when crosschainMint is successfully called. The _sender parameter MUST be set to the msg.sender at the time the function is called.

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

CrosschainBurn

MUST trigger when crosschainBurn is successfully called. The _sender parameter MUST be set to the msg.sender at the time the function is called.

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

Rationale

Design philosophy

The core design decisions behind this minimal interface are

• Bridge agnosticism.
• Extensibility.

Bridge agnosticism This interface is designed so bridges, not tokens, contain the logic to process crosschain actions. By maintaining this separation of concerns, token contracts remain simple, reducing their attack surface and easing auditing and upgradability. Offloading crosschain complexities to bridge contracts ensures that tokens do not embed specific bridge logic.

By implementing the proposed interface, tokens can be supported by different bridge designs:

• Lock/unlock bridges can still operate and do not require any token modification.
• Burn/mint bridges can now use a universal and minimal token interface, so they will not need to introduce bridge-specific representations, improving crosschain fungibility.

Extensibility The minimal interface serves as a foundational layer upon which other standards can be built. Token issuers or bridge contracts can extend functionality by adding features such as mint/burn limits, crosschain transfer fees, and more without altering the core interface.

The interface is intentionally neutral and does not impose conditions on:

• Access Control: Token issuers determine who is authorized to call crosschainMint() and crosschainBurn().
• Zero Amount Calls: Token issuers decide whether to allow or revert calls with zero amounts.

Separation of Local and crosschain Minting/Burning

Different actions

Local minting and burning are fundamentally different from crosschain minting and burning.

• In crosschain operations, the total circulating supply across all chains is expected to remain constant, as tokens are transferred between chains rather than created or destroyed in isolation.
• Agents that mint and burn tokens in crosschain transfer fundamentally differ from token owners. It make sense for the two actors to have different permissions.

Therefore, it is reasonable to have different checks, access controls, and logic (such as mint/burn limits) for crosschain actions.

Separation of concerns

Merging local and crosschain minting/burning into the same functions can lead to complex implementations that intertwine different operational logic. By splitting into two, concerns remain separate, making the codebase cleaner and more maintainable.

This separation of concerns is particularly relevant for

• Upgrades: Any changes in access control, limits, or logic will only affect the separate crosschain functions (crosschainMint and crosschainBurn) without altering the standard local mint and burn implementations.
• Integrations with Different Chains: To make an ERC-20 crosschain compatible, issuers simply need to implement the ERC-7802 extension with the corresponding access controls for each chain. For example, when integrating with Optimism, the ERC-20 would grant access to the Optimism bridge; when integrating with Arbitrum, it would grant access to the Arbitrum bridge. The local mint and burn functions remain unchanged. Using dedicated functions for crosschain operations provides a more modular approach, avoiding the need to modify the base implementation for each chain.

Dedicated events

A similar reasoning applies to having dedicated crosschain-specific events. The separation significantly facilitates the work of indexers, analytics tools, and auditors. It allows for straightforward tracking of crosschain activities, detecting anomalies, and monitoring bridge operations. If crosschain and local events are indistinguishable, off-chain agents must implement complex logic to differentiate them, increasing the potential for errors and inefficiencies.

ERC-165 Interface

The inclusion of ERC-165 provides an additional security check for integrators. By providing the interface identifier through the supportsInterface method, callers can programmatically confirm that the token adheres to the IERC7802 interface. This verification ensures that the token supports both crosschainMint and crosschainBurn functions, preventing scenarios where only one function is implemented. Such incomplete implementations could lead to issues like users burning tokens to bridge out but being unable to mint them upon return, resulting in failed crosschain actions.

It is important to note that this check can only be performed locally on the chain where the token contract resides. There is no inherent guarantee that the token on the receiving chain also supports the IERC7802 interface. Ensuring crosschain consistency of interface support is the responsibility of the bridge implementation.

Backwards Compatibility

This proposal is fully backwards compatible with ERC-20.

As discussed in the Motivation section, a minimal, flexible crosschain standard interface is necessary. The problem becomes larger as more tokens are deployed without a standardized format.

• Upgradable tokens can be upgraded to implement the new interface.
• Non-upgradable tokens cannot implement the interface on the token itself. They can still migrate to a standard-compliant version using a lockbox mechanism, as proposed by xERC-20. The idea is to lock non-mintable tokens and mint the same amount of interface-compliant tokens. The bridge contract can act as a lockbox on the native chain.

Bridge contracts will also need an upgrade to integrate with the interface.

Reference Implementation

// SPDX-License-Identifier: CC0-1.0
pragma solidity 0.8.25;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/utils/introspection/IERC165.sol";


/// @title IERC7802
/// @notice Defines the interface for crosschain ERC20 transfers.
interface IERC7802 is IERC165 {
    /// @notice Emitted when a crosschain transfer mints tokens.
    /// @param to       Address of the account tokens are being minted for.
    /// @param amount   Amount of tokens minted.
    /// @param sender   Address of the caller (msg.sender) who invoked crosschainMint.
    event CrosschainMint(address indexed to, uint256 amount, address indexed sender);

    /// @notice Emitted when a crosschain transfer burns tokens.
    /// @param from     Address of the account tokens are being burned from.
    /// @param amount   Amount of tokens burned.
    /// @param sender   Address of the caller (msg.sender) who invoked crosschainBurn.
    event CrosschainBurn(address indexed from, uint256 amount, address indexed sender);

    /// @notice Mint tokens through a crosschain transfer.
    /// @param _to     Address to mint tokens to.
    /// @param _amount Amount of tokens to mint.
    function crosschainMint(address _to, uint256 _amount) external;

    /// @notice Burn tokens through a crosschain transfer.
    /// @param _from   Address to burn tokens from.
    /// @param _amount Amount of tokens to burn.
    function crosschainBurn(address _from, uint256 _amount) external;
}

contract CrosschainERC20 is ERC20, IERC7802 {
    /// @notice Address of the TOKEN_BRIDGE contract that is allowed to mint/burn tokens.
    address public immutable TOKEN_BRIDGE;

    /// @notice Custom error for unauthorized access.
    error Unauthorized();

    /// @notice Constructor to set the TOKEN_BRIDGE address.
    /// @param _tokenBridge Address of the TOKEN_BRIDGE.
    constructor(address _tokenBridge, string memory name, string memory symbol) ERC20(name, symbol) {
        require(_tokenBridge != address(0), "Invalid TOKEN_BRIDGE address");
        TOKEN_BRIDGE = _tokenBridge;
    }

    /// @notice A modifier that only allows the TOKEN_BRIDGE to call
    modifier onlyTokenBridge() {
        if (msg.sender != TOKEN_BRIDGE) revert Unauthorized();
        _;
    }

    /// @notice Allows the TOKEN_BRIDGE to mint tokens.
    /// @param _to     Address to mint tokens to.
    /// @param _amount Amount of tokens to mint.
    function crosschainMint(address _to, uint256 _amount) external onlyTokenBridge {
        _mint(_to, _amount);
        emit CrosschainMint(_to, _amount, msg.sender);
    }

    /// @notice Allows the TOKEN_BRIDGE to burn tokens.
    /// @param _from   Address to burn tokens from.
    /// @param _amount Amount of tokens to burn.
    function crosschainBurn(address _from, uint256 _amount) external onlyTokenBridge {
        _burn(_from, _amount);
        emit CrosschainBurn(_from, _amount, msg.sender);
    }

    function supportsInterface(bytes4 interfaceId) external pure override returns (bool) {
        return interfaceId == type(IERC7802).interfaceId || interfaceId == type(IERC165).interfaceId;
    }
}

Security Considerations

Permissions

Token issuers are responsible for controlling which contracts are authorized to call the crosschainMint() and crosschainBurn() functions. A buggy or malicious authorized caller could mint or burn tokens improperly, damaging token holders and disrupting integrations.

One method to minimize potential losses is introducing mint/burn limits, as proposed by xERC-20. These features are fully compatible with the proposed interface.

Wrapped Native Tokens

This standard should not be used for wrapped native tokens like WETH, as it can lead to uncollateralized minting if the bridge does not control the underlying asset.

The only safe exception is when the bridge can burn and mint the native token symmetrically on both chains, ensuring proper collateralization.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

skeletor (@skeletor-spaceman), parti (@0xParticle), joxes (@Joxess), ng (@0xng), agus duha (@agusduha), disco (@0xDiscotech), gotzen <gotzen@defi.sucks>, 0age <0age@uniswap.org>, Mark Tyneway <mark@oplabs.co>, Zain Bacchus <zain@oplabs.co>, Matt Solomon <msolomon@oplabs.co>, Maurelian <maurelian@protonmail.ch>, Blaine Malone (@blmalone), "ERC-7802: Token With Mint/Burn Access Across Chains [DRAFT]," Ethereum Improvement Proposals, no. 7802, October 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7802.