EIP1046 - ERC20 Metadata Extension

# 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" (opens new window) 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.

/// @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);
}

1
2
3
4
5
6

This is the "Token Metadata JSON Schema" referenced above.

{
    "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.",
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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.