-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: Multi-chain Native Tokens #6403
Conversation
File
|
8b2a479
to
8c03471
Compare
2270807
to
e7ae46c
Compare
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This is ready for review |
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This is ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix the walidator errors.
The commit 8d47637 (as a parent of 8d4c274) contains errors. |
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
title: Multi-chain Native Tokens | ||
description: An interface for multi-chain native tokens. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your description doesn't provide any additional information compared to the title. Perhaps:
title: Multi-chain Native Tokens | |
description: An interface for multi-chain native tokens. | |
title: Multi-chain Native Tokens | |
description: Extending token interfaces with bridging support. |
|
||
## Abstract | ||
|
||
We propose new [`ERC20`](./eip-20.md), [`ERC721`](./eip-721.md) and [`ERC1155`](./eip-1155.md) extension interfaces which will allow provably secure, trustless bridge contracts to mint & burn tokens, enabling a new class of `ERC` tokens that can be native to multiple chains. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We propose new [`ERC20`](./eip-20.md), [`ERC721`](./eip-721.md) and [`ERC1155`](./eip-1155.md) extension interfaces which will allow provably secure, trustless bridge contracts to mint & burn tokens, enabling a new class of `ERC` tokens that can be native to multiple chains. | |
We propose new [`ERC20`](./eip-20.md), [`ERC721`](./eip-721.md) and [`ERC1155`](./eip-1155.md) extension interfaces which will allow provably secure, trustless bridge contracts to mint & burn tokens, enabling a new class of tokens that can be native to multiple chains. |
|
||
## Motivation | ||
|
||
[EIP-4844](./eip-4844.md) will set the stage for the Cambrian explosion of L2s on Ethereum. With multiple L2s living on the ethereum blockchain, It therefore becomes necessary to standardize an interface that will allow for native `ERC` tokens to flow across these L2s, removing the need for wrapped representations of these assets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[EIP-4844](./eip-4844.md) will set the stage for the Cambrian explosion of L2s on Ethereum. With multiple L2s living on the ethereum blockchain, It therefore becomes necessary to standardize an interface that will allow for native `ERC` tokens to flow across these L2s, removing the need for wrapped representations of these assets. | |
[EIP-4844](./eip-4844.md) will set the stage for the Cambrian explosion of L2s on Ethereum. With multiple L2s living on the ethereum blockchain, it therefore becomes necessary to standardize an interface that will allow for native tokens to flow across these L2s, removing the need for wrapped representations of these assets. |
|
||
[EIP-4844](./eip-4844.md) will set the stage for the Cambrian explosion of L2s on Ethereum. With multiple L2s living on the ethereum blockchain, It therefore becomes necessary to standardize an interface that will allow for native `ERC` tokens to flow across these L2s, removing the need for wrapped representations of these assets. | ||
|
||
Optimisim and Arbitrum, optimistic L2s which are already live on Ethereum today currently have their own custom token interfaces¹ that allow their bridge contracts to mint & burn tokens on L1 & L2. In order to remove the cognitive load on token issuers & developers from extending multiple interface for all the various L2s that will live on Ethereum. It becomes necessary to define a standardized API that all token issuers should implement in order to provide these trustless bridge contracts with the interface needed to transport tokens across these different chains. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only allow very specific external references (see EIP-1.)
Optimisim and Arbitrum, optimistic L2s which are already live on Ethereum today currently have their own custom token interfaces¹ that allow their bridge contracts to mint & burn tokens on L1 & L2. In order to remove the cognitive load on token issuers & developers from extending multiple interface for all the various L2s that will live on Ethereum. It becomes necessary to define a standardized API that all token issuers should implement in order to provide these trustless bridge contracts with the interface needed to transport tokens across these different chains. | |
Optimisim and Arbitrum, optimistic L2s which are already live on Ethereum today currently have their own custom token interfaces that allow their bridge contracts to mint & burn tokens on L1 & L2. In order to remove the cognitive load on token issuers & developers from extending multiple interface for all the various L2s that will live on Ethereum. It becomes necessary to define a standardized API that all token issuers should implement in order to provide these trustless bridge contracts with the interface needed to transport tokens across these different chains. |
|
||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
||
Smart contracts implementing the EIP-6160 standard MUST implement all of the functions in the `EIP-6160` interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smart contracts implementing the EIP-6160 standard MUST implement all of the functions in the `EIP-6160` interface. | |
Smart contracts implementing this standard MUST implement all of the functions in the corresponding interface defined below. |
|
||
## Rationale | ||
|
||
1. We have chosen the [EIP-5679](./eip-5679.md) standard to provide the mint & burn interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rationale section should explain why a choice was made, not just state which decisions were considered.
2. We have chosen [EIP-5982](./eip-5982.md) standard to provide the access control interface for trustless bridge contracts to check their permissions to mint & burn `ERC20` tokens. | ||
3. We have chosen NOT to create new events but to require the usage of existing transfer event as required by EIP-20 EIP-721 and EIP-1155 for maximum compatibility. | ||
|
||
## Implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Implementation | |
## Reference Implementation |
3. We have chosen NOT to create new events but to require the usage of existing transfer event as required by EIP-20 EIP-721 and EIP-1155 for maximum compatibility. | ||
|
||
## Implementation | ||
We have made an example implementation for this EIP at [polytope-labs implementation](https://github.com/polytope-labs/multichain-native-tokens/tree/main/src/tokens) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't allow external reference implementations. If you'd like, you can create a minimal reference implementation and include it in the assets
directory under a permissive license (CC0-1.0
preferred.) Failing that, just remove the whole section.
|
||
## Backwards Compatibility | ||
|
||
This EIP is designed to be compatible with EIP-20, EIP-721, EIP-1155. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This EIP is designed to be compatible with EIP-20, EIP-721, EIP-1155. | |
This EIP is designed to be compatible with ERC-20, ERC-721, ERC-1155. |
## References | ||
|
||
¹ Arbitrum: [ICustomToken](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/contracts/tokenbridge/ethereum/ICustomToken.sol), [IArbToken](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/contracts/tokenbridge/arbitrum/IArbToken.sol). Optimism: [IL2StandardERC20](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## References | |
¹ Arbitrum: [ICustomToken](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/contracts/tokenbridge/ethereum/ICustomToken.sol), [IArbToken](https://github.com/OffchainLabs/token-bridge-contracts/blob/main/contracts/tokenbridge/arbitrum/IArbToken.sol). Optimism: [IL2StandardERC20](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol). |
Please remove this whole section. We don't allow external links except as mentioned in EIP-1.
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually. As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process. If there is relevant history here, please link to this PR from the new pull request. On behalf of the EIP Editors, I apologize for this inconvenience. |
This EIP standardizes the interface for
ERC20
token contracts which will allow provably secure, trustless bridge contracts to mint & burn tokens, enabling a new class ofERC20
tokens that can be native to multiple chains.rendered