mirror of https://github.com/status-im/EIPs.git
ERC20 metadata extension (#1046)
* Add initial EIP skeleton * Initial take through "Rationale" * First very rough draft of ERC20 Metadata Extension Nearly ready for comments by Matt, Matt, and John * Initial "Token Metadata Standard" Proposal + small change to ERC721 - Added initial “Token Metadata JSON Schema” - Re-named “ERC721 Metadata JSON Schema” to “Token Metadata JSON Schema” in the ERC721 EIP * ERC20 Metadata Extension ready to read * Update Title of ERC Metadata Extension * Fixing Matt's Github handle Apparently Github handles for authors are meant to be “accurate” - who knew? * update grammatical errors; properly format JSON to remove excess commas * update JSON descriptions & make grammatical changes to EIP * Changed language in Token Metadata JSON Schema to reflect use by tokens which are not NFT's. Added clarification for backwards compatibility * update authors and contact email * Author Fix * Removing Token Metadata Standard This Branch will be just the ERC20 Token Metadata Extension * Updates from reviewer comments - Some grammar fixes - Removed mentions of ERC721 standard code - Added EIP # and discussion forum * Fixing discussion-to discussion-to instead of discussion-forum * Should remove the change to 721 * 100% revert on ERC721 No changes to ERC721 in this PR now * Discussions-to
This commit is contained in:
parent
09d39ce44d
commit
6b2bdaa767
|
@ -0,0 +1,87 @@
|
|||
---
|
||||
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/).
|
Loading…
Reference in New Issue