ERC-7802: Crosschain Token Interface

ERCs
,
1

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.
The interface is bridge agnostic and fully extensible.

PR:

16 Likes
2

I welcome the minimalism.

Yet, how do you expect the compatibility with xERC20? ( ERC 7281 ) - would be nice to have that elaborated in the compatibility section.

1 Like
3

+1 to @radek s question.

4

Hi @drgorilla.eth, I like the ERC design as it is pretty minimal!

We’ve been working on ERC-7786 (crosschain messaging gateways) to define a minimal standard to simply “get a message to another chain”. I tried to implement ERC-7802 on top of ERC-7786. Here’s the code (WIP). We’re planning to include it in the community version of OpenZeppelin Contracts

The idea to combine these 2 standards is because ERC-7802 defines an interface where a bridge address can mint or burn, but I would argue that it would be better if ERC-7802 depends on ERC-7786 to make the crosschain token its messaging gateway. This way, the bridge integration is abstracted away and the ERC20 can expose a crosschainTransfer that burns tokens on the source chain and relays a mint instruction to the destination chain.

EDIT: I’m rethinking the crosschainTransfer idea since I see the reasoning behind offloading the logic from the token. Still, we appreciate feedback, we’re planning to put this into the library pretty soon

1 Like
7

They complement each other. ERC-7802 defines the minimal interface for an ERC-20 token to communicate cross-chain, but it doesn’t specify how a protocol should send a cross-chain message to communicate with such tokens. Similarly, it doesn’t specify how a user will transfer tokens on-chain.

I agree this standard should remain minimal, but I would agree it may benefit if they specify an optional interface for the “token bridge” that depends on ERC-7786. It also makes sense to put it in another ERC.

8

Regarding compatibility with xERC20 (ERC-7802), I wrote this document:

9

Can it be an issue that an adapter for xERC20 doesn’t emit CrosschainMint/Burn? This is not discussed in the document, but these events are specified as “MUST”. If these events wont be reliable, it might make sense to lower the requirement in the spec (SHOULD or MAY) or even remove it.

10

The adapter itself is not an implementation of the IERC7802 standard, nor is it an ERC20 token. Instead, it serves as an intermediary to enable a bridge—already compliant with the IERC7802 API—to interact with xERC20 tokens that may not natively implement this interface.

Since the adapter is merely a compatibility layer and not a token contract, it is not required to emit CrosschainMint or CrosschainBurn events. These events are only mandatory for contracts that directly implement IERC7802. The role of the adapter is to translate standardized bridge calls into the xERC20’s existing mint and burn functionality, ensuring operational compatibility.

2 Likes
11

Love the proposal! There is definitely a problem with bridges as every provider forces to use their own mint/burn interface.

Have several questions though:

  1. Maybe it is worth expanding the crosschainMint() and crosschainBurn() interfaces to accept an additional bytes parameter?

    So the new function signatures will be:

    function crosschainMint(address _account, uint256 _amount, bytes memory _payload);
function crosschainBurn(address _account, uint256 _amount, bytes memory _payload);

    Possibly this can allow ERC-7802 tokens to perform some business-specific logic.

  2. In the provided reference implementation, shouldn’t there be token allowance spending in the crosschainBurn() function?

    function crosschainBurn(address _from, uint256 _amount) external onlyTokenBridge {
    _spendAllowance(_from, msg.sender, _amount); // <-- add this line
    _burn(_from, _amount);
    emit CrosschainBurn(_from, _amount, msg.sender);
}

    It is probably fine the way it is implemented now provided the TokenBridge understands current behavior and prohibits grefing.

1 Like
14

Great points!

  1. I understand that incorporating a bytes parameter could facilitate business-specific logic; however, it goes against the design goal of maintaining a minimal interface. The goal is to keep tokens straightforward and allow for more complex hooks or logic to be handled at the bridge level.
    Do you have any examples in mind of logic that would require using these bytes and cannot be implemented at the bridge level?
  2. In this scenario, we assume the bridge is trusted and does not require allowance checks. Including _spendAllowance would be more consistent with systems like xERC20, where allowances are essential. However, for this minimal approach, it is not necessary. If needed, allowances can always be added later for specific implementations.
15

I agree with the rational and adding metadata byte param. :pray:

16

Being in the middle of the implementation into ERC20 using both xERC20 and ERC7802.

I believe the mentioned msg.sender is not correct in the standard:

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);

I assume the rationale to emit sender is to filter out which events are related to the particular bridge.

In the case there is an adapter between the bridge and ERC20 token, such adapter becomes msg.sender.

17

This is an interesting point. I see the concern about the adapter becoming msg.sender, but I don’t necessarily think it’s an issue for the event to emit the adapter’s address. If we change _sender, we might introduce inconsistencies or require extra logic to track the original caller. Keeping msg.sender as-is ensures consistency, and indexers can be designed to trace the adapter path when necessary.

1 Like
19

Hi does ERC-7802 has a public audit report so far? Thank you! @drgorilla.eth

20

FYI - here is the draft of the minimal xERC20 standard: