Add ERC: Crosschain Token Interface #692
Conversation
|
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
|
Mfxrhxn |
| This function works as the burning entry point for bridge contracts. Each implementation is responsible for its access control logic. | ||
|
|
||
| ```solidity | ||
| function crosschainBurn(address _account, uint256 _amount) external; |
| /// @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 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.