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 @g11tech, @SamWilsn, @xinbenlv

[blmalone]

Some suggested amendments.

[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

[0xParticle]

Regarding compatibility with xERC20 (ERC-7802), I wrote this document:
https://defi-wonderland.notion.site/xERC20-ERC7802-compatibility-14c9a4c092c780ca94a8cb81e980d813?pvs=4

[frangio]

I strongly suggest making the Transfer events mandatory.

ERC-20 is more relevant than ERC-5679 IMO, and in the former it's already specified as SHOULD (i.e., a strong recommendation):

A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.

[0xParticle]

Very good catch. Just pushed to modify this invariant.

[SamWilsn]

Gentle reminder to keep technical discussion in the Ethereum Magicians thread. It's easy to lose context after the pull request is merged.

[SamWilsn]

Minimal

Too many standards claim to be minimal. I'd recommend removing this, and using your description to further elaborate on the ideas introduced in your title.

[0xParticle]

Modified this section, let me know your thoughts now

[SamWilsn]

Not bad, but I'd like to see a bit more technical meat here. Could you sketch out how your proposal operates, in addition to the description you already have.

[0xParticle]

Added more technical details.

[SamWilsn]

This leaves a lot unspecified (which is fine if it's intentional.) For example, should other non-standard functions that also effectively perform a crosschain mint also trigger this event, or is it specifically tied to this function?

[0xParticle]

Yes, this is intentionally unspecified. The CrosschainMint event MUST be triggered when the crosschainMint function is successfully called. However, implementers are not restricted from emitting this event when using other non-standard functions that effectively perform a crosschain mint.

If the implementation adheres to this standard, the full interface—including crosschainMint and crosschainBurn—will already be available, so it is expected that these functions are used for crosschain minting and burning. That said, the event is not mandated for every action that triggers a crosschain operation, as this standard focuses specifically on the standardized interface.

[SamWilsn]

Does xERC-20 have an ERC? If so, you should link it.

[0xParticle]

It has an open PR to the ERC repo with assigned number 7281, but it has not been merged. If I mention the ERC-7281 in this ERC, the EIP validator asks for an internal link, which I can't reference at the moment.

[Saraeutsza]

defi-wonderland:erc/crosschain-token-interface

[github-actions]

The commit 5d26ebb (as a parent of d3b7d38) contains errors.
Please inspect the Run Summary for details.