Multi-chain Native Tokens

Do not index

In this research article, we propose an extension interface for ERC20 , ERC721 and ERC1155 token contracts, in order for them to become native to multiple chains. These interfaces will become a necessity with the upcoming Cambrian explosion of rollups on Ethereum with addition of EIP-4844. You can find the actual EIP proposal here.

Motivation

As more and more rollups launch on Ethereum, it becomes necessary to standardize an interface that will allow bridge contracts natively mint & burn ERC20 tokens. This is necessary because existing rollups like Optimism & Arbitrum have already defined their own token interfaces that allows their bridge contracts move ERC20 tokens between L1 and L2. If we allow this to continue, then there’ll be a new interface for every L2 that launches on Ethereum. Standardization is necessary to prevent this.

Trustless interoperability, ie consensus verifying bridges, haven’t been possible out of Ethereum, until now. With the transition to proof of stake and the introduction of the Casper FFG & Altair light client protocol, It’s now possible for another blockchain to trustlessly track the state of the Ethereum beacon chain, enabling trustless bridges to & out of Ethereum. These new interfaces will provide these trustless bridge contracts with the necessary interface they need to natively transport tokens in and out of Ethereum.

Specification

In order to transport tokens, we consider the mint & burn approach. This allows token issuers to easily track their total TVL across chains, where escrow and release models can introduce new attack surface areas. In order to provide this mint and burn interface, we provide extension interfaces for the standard ERC20, ERC721 and ERC1155 token interfaces. These interfaces provide not only the necessary mint & burn interfaces needed to transport tokens, but also the access-control layer for token issuers to add & remove bridges to the allowed list of contracts that can mint & burn.

In this new architecture, token issuers are instead responsible for deploying their token contracts across all the chains they wish to support. This allows them to retain full control of all instances of their token across chains, rather than having the L2s or alt-L1s deploy wrapped (usually from bridges) versions of the tokens themselves.

1. Any contract complying with EIP-20 when extended with this EIP, **MUST** implement the following interface:


// The EIP-165 identifier of this interface is 0x01cbdea7*
interface IERC6160Ext20 is IERC5679Ext20, IERC_ACL_CORE, ERC165 {}

2. Any contract complying with EIP-721 when extended with this EIP, **MUST** implement the following interface:

// The EIP-165 identifier of this interface is 0x01cbdea7*
*interface IERC6160Ext721 is IERC5679Ext721, IERC_ACL_CORE, ERC165 {}

3. Any contract complying with EIP-1155 when extended with this EIP, **MUST** implement the following interface:

// The EIP-165 identifier of this interface is 0x01cbdea7*
interface IERC6160Ext1155 is IERC5679Ext1155, IERC_ACL_CORE, ERC165 {}

4. It is RECOMMENDED for compliant contracts to implement the optional extension IERC_ACL_GENERAL.

5. Compliant contracts MAY implement the optional extension IERC_ACL_METADATA.

Rationale

1. We have chosen the EIP-5679 standard to provide the mint & burn interface.

2. We have chosen EIP-5982 standard to provide the access control interface for trustless bridge contracts to check their permissions to mint & burn ERC 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.

Security Considerations

Currently all of the bridges going in & out of Ethereum are unfortunately trusted and rely on 3rd party attestation rather than proof-based authentication. (So much for don’t trust, verify). Given this situation, we don’t expect token issuers to add support for these kinds of bridges. Rather, with trustless interoperability on the horizon with protocols like succint labs, zkbridge, hyperledger labs , snowfork and electron labs. We see a need to begin to set the stage early for projects like these to be able to transport ERC tokens natively across L2s and alt-L1s alike.

References

Arbitrum: ICustomToken, IArbToken. Optimism: IL2StandardERC20.

https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus/

https://arxiv.org/pdf/2210.00264.pdf

https://medium.com/@datachain/datachain-successfully-completes-building-an-ibc-bridge-between-cosmos-and-harmony-on-the-local-5910e094e6c6

https://snowfork.substack.com/p/a-trustless-general-purpose-polkadot

https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634