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.
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.
This ERC introduces the IERC7802 interface.
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:
or via Solidity as
Implementors MUST ensure that the supportsInterface method of ERC-165 returns true for this interface ID to indicate support for IERC7802.
crosschainMint
Mints _amount of token to address _account.
This function works as the minting entry point for bridge contracts.
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.
Implementations might consider emitting Transfer(_from, address(0), _amount) on calls to crosschainBurn to be compliant with ERC-5679.
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.
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.
The core design decisions behind this minimal interface are
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:
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:
crosschainMint() and crosschainBurn().Different actions
Local minting and burning are fundamentally different from crosschain minting and burning.
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
crosschainMint and crosschainBurn) without altering the standard local mint and burn implementations.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.
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.
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.
Bridge contracts will also need an upgrade to integrate with the interface.
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.
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 and related rights waived via CC0.