--- eip: 1046 title: ERC20 Metadata Extension author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs) discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfh1g/erc20_metadata_extension_eip_1046/ status: Draft type: Standards Track category: ERC created: 2018-04-13 requires: 20 --- ## Simple Summary Optionally extend ERC20 token interface to support the same metadata standard as ERC721 tokens. ## Abstract The ERC721 standard introduced the `tokenURI` parameter for non-fungible tokens to handle metadata such as: - thumbnail image - title - description - special asset properties - etc. Metadata is critical for assets such as crypto-collectibles and video game assets to have real utility and value. However, not all crypto-collectibles and gaming assets will be non-fungible. It is critical for fungible ERC20 tokens to have a metadata standard like that of ERC721 tokens. Standardization of metadata between ERC20 and ERC721 will simplify development of dApps and infrastructure that must support both fungible and non-fungible assets. ## Motivation The ERC721 standard was created to support the creation of perfectly unique, 1-of-1, non-divisible tokens known as "non-fungible tokens". The initial use case for the ERC721 standard was to support the creation of crypto-collectibles and gaming assets, initially for the ["Crypto Kitties"](https://www.cryptokitties.co/) collectibles game. The success of Crypto Kitties catalyzed significant application development to support the display of ERC721 assets using the `tokenURI` metadata parameter. However, not all crypto-collectibles and gaming assets need to be unique and non-fungible. Gaming assets (items, weapons, characters), crypto-artworks with non-unique "prints", and more will function more like traditional ERC20 tokens with a fungible `supply`. Many applications such as wallets, exchanges, games, etc. will want to support both fungible and non-fungible assets containing similar metadata. This proposal will extend the ERC20 standard to optionally include a nearly identical `tokenURI` parameter supporting the same JSON metadata schema as the ERC721 standard. ## Specification The **metadata extension** will be OPTIONAL for ERC20 contracts. This allows your smart contract to be interrogated for its name and for details about the assets which your tokens represent. ```solidity /// @title ERC-20 optional metadata extension interface TokenMetaData /* is ERC20 */ { /// @notice A distinct Uniform Resource Identifier (URI) for a given token. function tokenURI() external view returns (string); } ``` This is the "Token Metadata JSON Schema" referenced above. ```json { "title": "Asset Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this token represents", }, "description": { "type": "string", "description": "Describes the asset to which this token represents", }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.", } } } ``` The token's name() and symbol() getters should be preferred over the name and/or symbol properties in the tokenURI JSON. ## Rationale This proposal will make adding metadata to ERC20 tokens straightforward for developers with minimal-to-no disruption to the overall ecosystem. By using the same parameter name and by consolidating the underlying Token JSON Metadata Standard, developers will confidently understand how to add and interpret token metadata between ERC20 and ERC721 tokens. ## Backwards Compatibility This EIP is fully backwards compatible as its implementation simply extends the functionality of ERC20 tokens and is optional. ## Test Cases TO-DO ## Implementation - [Rare Art Labs](https://rareart.io) (WIP) - [Open Zeppelin](https://github.com/OpenZeppelin/zeppelin-solidity) (WIP) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).