Add ERC: Crosschain Token Interface#692
Conversation
|
✅ All reviewers have approved. |
|
Regarding compatibility with xERC20 (ERC-7802), I wrote this document: |
ERCS/erc-7802.md
Outdated
| event CrosschainMint(address indexed _to, uint256 _amount, address indexed _sender); | ||
| ``` | ||
|
|
||
| Note: implementations might consider additionally emitting `Transfer(address(0), _to, _amount)` to be compliant with [ERC-5679](./eip-5679.md). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Very good catch. Just pushed to modify this invariant.
|
Gentle reminder to keep technical discussion in the Ethereum Magicians thread. It's easy to lose context after the pull request is merged. |
ERCS/erc-7802.md
Outdated
| --- | ||
| eip: 7802 | ||
| title: Crosschain Token Interface | ||
| description: Minimal token interface for cross-chain transfers |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Modified this section, let me know your thoughts now
There was a problem hiding this comment.
Can someone here explain how to view/claim tokens or prizes that were claimed too late because I didn't understand? I hope for the information
ERCS/erc-7802.md
Outdated
|
|
||
| ## Abstract | ||
|
|
||
| This standard 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Added more technical details.
|
|
||
| **`CrosschainMint`** | ||
|
|
||
| MUST trigger when `crosschainMint` is successfully called. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| As discussed in the Motivation section, a minimal, flexible cross-chain 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. |
There was a problem hiding this comment.
Does xERC-20 have an ERC? If so, you should link it.
There was a problem hiding this comment.
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.
Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
…d fix license in reference implementation
|
The commit 5d26ebb (as a parent of d3b7d38) contains errors. |
…to crosschainMint
| /// @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 { |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
SamWilsn
left a comment
SamWilsn
left a comment
There was a problem hiding this comment.
I think this is acceptable for draft. Do try to take care of these comments eventually. Also replace xerc-20 with links to that proposal when it's merged.
| @@ -0,0 +1,259 @@ | |||
| --- | |||
| eip: 7802 | |||
| title: Crosschain Token Interface | |||
There was a problem hiding this comment.
"Interface" in an ERC title doesn't add a ton of information. Most ERCs contain some kind of interface.
How about:
| title: Crosschain Token Interface | |
| title: Permissioned Token Mint/Burn Across Chains |
There was a problem hiding this comment.
Agree with the suggestion of removing "interface" from the title. I'm not convinced about using "Permissioned", as that is not inherent to the interface (it could be permissionless). What do you think about something like "Token with Mint/Burn access 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 cross-chain 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. |
There was a problem hiding this comment.
This paragraph probably belongs (with some rewording) in the Rationale section, since it explains why this standard is designed the way it is.
There was a problem hiding this comment.
The Rationale section already speaks about this design decision in more depth. I wanted to highlight this key property in the Abstract as well.
If you still consider this paragraph is too much information for the Abstract, I could rephrase it and make it shorter.
|
|
||
| Mints `_amount` of token to address `_account`. | ||
|
|
||
| This function works as the minting entry point for bridge contracts. Each implementation is responsible for its access control logic. |
There was a problem hiding this comment.
You can move the access control notes on each method to the security considerations section.
There was a problem hiding this comment.
The Security considerations mention this issue explicitly. I will remove these considerations from the method description to minimize redundancy.
eip-review-bot
left a comment
eip-review-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
Thanks for the feedback. I will open a new PR addressing the various comments. |
17 participants
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.