Add ERC: Crosschain Token Interface

[0xParticle]

This ERC introduces a minimal interface for tokens to communicate cross-chain. It allows bridges with mint and burn rights to send and relay token transfers with a standardized API.

[eip-review-bot]

File ERCS/erc-7802.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

[blmalone]

Some suggested amendments.

[blmalone]

@0xParticle I left an additional comment on Discord: https://discord.com/channels/1244729134312198194/1297972645014536325/1301548267447779328

It pertains to introducing IERC165 and committing to the bytes4 interface for IERC7802 (i.e. 0x33331994).

[github-actions]

The commit 1946670 (as a parent of 01bf2ad) contains errors.
Please inspect the Run Summary for details.

[blmalone]

Do we want to keep this abstract?

As per this gist, removing the abstract key word allows it to be immediately deployable in remix. If we decide to remove it, the constructor change will also need to be made.

[0xParticle]

Just removed it. Also, made the constructor a bit more generic.

[MSilb7]

Adding source/destination chain id & a unique message id to events would make crosschain data more easily usable. This ~may be a hard requirement for analytics, but hard to know without seeing further build out. This is necessary for joining messages across chains, to then see inflows/outflows by chain and routes.

This gap is a main reason why you don't see this data for 3P bridges. Most sites do ~1-3 L2<>L2 bridges, then give up due to the high overhead.

[hildobby]

+1

[0xParticle]

Hi @MSilb7 !

Thank you for your suggestion. We have discussed your idea internally and agree that it has value. However, we couldn't find a minimalistic set of parameters to add to the event without making the current standard more opinionated:

• Identifier: Incorporating an identifier would require defining an encoding standard within the ERC, which we believe is beyond the scope of this proposal.
• Adding from/to and chainIdFrom/chainIdTo: Including these parameters would require changing the inputs of crosschainMint and crosschainBurn to allow the bridge to pass them. This approach is opinionated because bridges might have multiple destinations or origins, and imposing single input parameters could limit their flexibility. Moreover, event-collisions would be possible.

We see significant value in adding msg.sender to the CrosschainMint and CrosschainBurn events. This addition would allow integrators to identify which bridge interacts with the tokens, and does not affect the interface's neutrality in anyway.

I believe your idea has the potential to become a standard for bridge events.

[MSilb7]

On msg.sender:

• Is the use case of msg.sender that in order to join, you would only look at transactions sent from that address on other chains? Or only function calls (internal txs) initiating from that address?
• Is this already derivable from the transaction / internal transaction? If so then the only benefit is just that you don't need to use traces, you can just use logs.

My overall opinion is:

• Without any way to clearly identify how you identify the source burn for any destination mint (and vice versa), it's not useful from an analytics & legibility perspective.
• The only value it fulfills now seems to be: I know that this is intended to be a cross-chain transfer, versus a same-chain transfer. But it still gives me no information about where the transfer came from or goes to.
• Which then opens up other questions, like: "How do applications know if the burn/mint is valid?"

[karankurbur]

adding msg.sender to the event would make indexing significantly easier as we can now find all mints/burns associated with a specific bridge purely based on log data.

[Deluaney1]

03f247e2ac8061e11176c8d0526f8a8af3aebffe

[yorhodes]

Nothing about any of these interfaces is "crosschain" in nature so wondering why not just use an existing "mintable" or "burnable" interface? What about the existing xERC20 standard is insufficient?

[prohimone]

Nothing about any of these interfaces is "crosschain" in nature so wondering why not just use an existing "mintable" or "burnable" interface? What about the existing xERC20 standard is insufficient?

or compatibility to the existing xERC20 for that matter

[Zodomo]

This interface should be made to match xERC20, which is essentially an implementation of this, but with safety features such as rate limiting. When it is very easy for this standard to match that one, why doesn't it?

[0xParticle]

Nothing about any of these interfaces is "crosschain" in nature so wondering why not just use an existing "mintable" or "burnable" interface? What about the existing xERC20 standard is insufficient?

wondering why not just use an existing "mintable" or "burnable" interface
Token issuers might want to implement different logic when minting and burning come from a bridge, such as additional security checks or events. Even though it is possible to use a standard mintable interface, having a separate function allows for a clear separation of concerns.

It might feel unnatural for tokens that do not implement any logic different from a regular mint and burn, but we want to ensure the standardized API works for the general case.

What about the existing https://github.com/ethereum/ERCs/pull/89 is insufficient?
xERC20 is not insufficient. In fact, adding mint/burn limits is a great security feature and can be built very easily on top of this ERC. Our proposal aims to complement standards like xERC20 by providing a minimalistic interface that includes only the common essential actions across various cross-chain token standards.

Features such as mint and burn limits should be optional rather than mandatory components of a cross-chain token interface. It is possible to set the limits to max in xERC20, but you would still need a token owner, which might not be the most general design.

Again, our proposed standard is not intended to compete with xERC20 in any way. It's a smaller Lego piece that xERC20 and other standards can use.

[0xParticle]

Nothing about any of these interfaces is "crosschain" in nature so wondering why not just use an existing "mintable" or "burnable" interface? What about the existing xERC20 standard is insufficient?

or compatibility to the existing xERC20 for that matter

See #692 (comment)

[0xParticle]

This interface should be made to match xERC20, which is essentially an implementation of this, but with safety features such as rate limiting. When it is very easy for this standard to match that one, why doesn't it?

Yes, we could make it match with xERC20. The only difference between the two lies in function naming. In our proposal, we use distinct function names—crosschainMint and crosschainBurn—to explicitly differentiate minting and burning actions triggered by a bridge from standard token operations. We believe that having separate function names for cross-chain interactions provides clearer semantics and allows token contracts to implement specific logic or security measures for these operations.

We are open to collaborating on unifying the naming conventions, whether that involves adjusting names in our proposal or in xERC20.

[yorhodes]

Features such as mint and burn limits should be optional rather than mandatory components of a cross-chain token interface. It is possible to set the limits to max in xERC20, but you would still need a token owner, which might not be the most general design.

Again, our proposed standard is not intended to compete with xERC20 in any way. It's a smaller Lego piece that xERC20 and other standards can use.

Thanks for clarifying @0xParticle. I do think it would be in the spirit of the ERC process to mitigate fragmentation by reusing the xERC20 function interface (subset). This seems much more natural than encouraging existing tokens to upgrade/migrate to this new interface.

I understand that you think the crosschain prefix is important to be explicit about. My personal feeling is the opposite -- that there is no reason the token standard needs to distinguish between "crosschain" and "local" mint/burn roles, similar to how it is an antipattern to distinguish between EOAs and contracts. Token contracts can still implement crosschain checks/logic behind the mint/burn functions if they so choose.

[WojasKrk]

Xxx

[zainbacchus]

I do think it would be in the spirit of the ERC process to mitigate fragmentation by reusing the xERC20 function interface (subset). This seems much more natural than encouraging existing tokens to upgrade/migrate to this new interface.

Definitely understand the spirit of reusing where possible, one concern in reusing mint/burn is with generating a false sense of interoperability for tokens that are already deployed and have no way to deploying to the same address on other chains which I imagine will be important to mitigate the issue that authorized bridges will need to know what address does each token have in each chain - which I don't believe the xERC20 draft EIP has a formal requirement for currently.

[0xParticle]

Thanks for clarifying @0xParticle. I do think it would be in the spirit of the ERC process to mitigate fragmentation by reusing the xERC20 function interface (subset). This seems much more natural than encouraging existing tokens to upgrade/migrate to this new interface.

I understand that you think the crosschain prefix is important to be explicit about. My personal feeling is the opposite -- that there is no reason the token standard needs to distinguish between "crosschain" and "local" mint/burn roles, similar to how it is an antipattern to distinguish between EOAs and contracts. Token contracts can still implement crosschain checks/logic behind the mint/burn functions if they so choose.

Thank you for your feedback! This has been the main concern so far, so I'll elaborate on why we think having separate functions makes a lot of sense.

Local minting and burning are fundamentally different from cross-chain minting and burning.

• In cross-chain 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 cross-chain transfer fundamentally differ from token owners. It make sense for the two actors to have different permissions.

Therefore, having different checks, access controls, and logic for cross-chain actions is reasonable. The mint/burn limits that xERC20 introduces are a great example. Merging local and cross-chain minting/burning into the same functions can lead to complex implementations that intertwine different operational logic. By splitting into two, we separate concerns, 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 cross-chain functions (crosschainMint and crosschainBurn) without altering the standard local mint and burn implementations.
• Integrations with Different Chains: To make an ERC20 token cross-chain compatible, you simply need to implement the ERC-7802 extension with the corresponding access controls for each chain. For example, when integrating with Optimism, the ERC20 token 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 cross-chain operations provides a more modular approach, avoiding the need to modify the base implementation for each chain.

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

The analogy between distinguishing EOAs/contracts and local/cross-chain operations isn't directly applicable. As reflected in the protocol's roadmap, the Ethereum community is working towards account abstraction to unify EOAs and contract accounts. However, there's no equivalent movement to unify local and cross-chain token operations. Cross-chain actions inherently involve additional complexities and external dependencies that justify distinct handling in token contracts.

Finally, the standard is still compatible with xERC20 via custom adapters, even with a different naming. We will work to improve this compatibility, as we think xERC20 is a great standard and want to support it. As a matter of fact, my folks at Wonderland are coauthors to the xERC20 standard.

[jacekv]

This looks very much like the Pantos token contract for native cross-chain tokens. Just the naming of the functions is different, yet concept is the same:
https://github.com/pantos-io/ethereum-contracts/blob/main/src/interfaces/IPantosToken.sol