Skip to content

Commit 36ddc29

Browse files
authored
Merge 4b4335e into 8788879
2 parents 8788879 + 4b4335e commit 36ddc29

File tree

924 files changed

+333
-161361
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

924 files changed

+333
-161361
lines changed

EIPS/eip-1046.md

Lines changed: 1 addition & 221 deletions
Original file line numberDiff line numberDiff line change
@@ -1,221 +1 @@
1-
---
2-
eip: 1046
3-
title: tokenURI Interoperability
4-
description: Extends ERC-20 with an ERC-721-like tokenURI, and extends ERC-721 and ERC-1155 with interoperability
5-
author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs), Gavin John (@Pandapip1)
6-
discussions-to: https://ethereum-magicians.org/t/eip-1046-erc-20-metadata-extension/13036
7-
status: Final
8-
type: Standards Track
9-
category: ERC
10-
created: 2018-04-13
11-
requires: 20, 721, 1155
12-
---
13-
14-
## Abstract
15-
16-
[ERC-721](./eip-721.md) introduced a `tokenURI` function for non-fungible tokens to handle miscellaneous metadata such as:
17-
18-
- thumbnail image
19-
- title
20-
- description
21-
- special asset properties
22-
- etc.
23-
24-
This ERC adds a `tokenURI` function to [ERC-20](./eip-20.md), and extends [ERC-721](./eip-721.md) and [ERC-1155](./eip-1155.md) to enable interoperability between all three types of token URI.
25-
26-
## Motivation
27-
28-
See the note about the metadata extension in [ERC-721](./eip-721.md#rationale). The same arguments apply to ERC-20.
29-
30-
Being able to use similar mechanisms to extract metadata for ERC-20, ERC-721, ERC-1155, and future standards is useful for determining:
31-
32-
- What type of token a contract is (if any);
33-
- How to display a token to a user, either in an asset listing page or on a dedicated token page; and
34-
- Determining the capabilities of the token
35-
36-
## Specification
37-
38-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
39-
40-
### Interoperability Metadata
41-
42-
The following TypeScript interface is used in later sections:
43-
44-
```typescript
45-
/**
46-
* Interoperability metadata.
47-
* This can be extended by other proposals.
48-
*
49-
* All fields MUST be optional.
50-
* **Not every field has to be a boolean.** Any optional JSON-serializable object can be used by extensions.
51-
*/
52-
interface InteroperabilityMetadata {
53-
/**
54-
* This MUST be true if this is ERC-1046 Token Metadata, otherwise, this MUST be omitted.
55-
* Setting this to true indicates to wallets that the address should be treated as an ERC-20 token.
56-
**/
57-
erc1046?: boolean | undefined;
58-
59-
/**
60-
* This MUST be true if this is ERC-721 Token Metadata, otherwise, this MUST be omitted.
61-
* Setting this to true indicates to wallets that the address should be treated as a ERC-721 token.
62-
**/
63-
erc721?: boolean | undefined;
64-
65-
/**
66-
* This MUST be true if this is ERC-1155 Token Metadata, otherwise, this MUST be omitted.
67-
* Setting this to true indicates to wallets that the address should be treated as a ERC-1155 token.
68-
**/
69-
erc1155?: boolean | undefined;
70-
}
71-
```
72-
73-
### ERC-20 Extension
74-
75-
#### ERC-20 Interface Extension
76-
77-
Compliant contracts MUST implement the following Solidity interface:
78-
79-
```solidity
80-
pragma solidity ^0.8.0;
81-
82-
/// @title ERC-20 Metadata Extension
83-
interface ERC20TokenMetadata /* is ERC20 */ {
84-
/// @notice Gets an ERC-721-like token URI
85-
/// @dev The resolved data MUST be in JSON format and support ERC-1046's ERC-20 Token Metadata Schema
86-
function tokenURI() external view returns (string);
87-
}
88-
```
89-
90-
#### ERC-20 Token Metadata Schema
91-
92-
The resolved JSON of the `tokenURI` described in the ERC-20 Interface Extension section MUST conform to the following TypeScript interface:
93-
94-
```typescript
95-
/**
96-
* Asset Metadata
97-
*/
98-
interface ERC20TokenMetadata {
99-
/**
100-
* Interoperabiliy, to differentiate between different types of tokens and their corresponding URIs.
101-
**/
102-
interop: InteroperabilityMetadata;
103-
104-
/**
105-
* The name of the ERC-20 token.
106-
* If the `name()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value.
107-
*/
108-
name?: string;
109-
110-
/**
111-
* The symbol of the ERC-20 token.
112-
* If the `symbol()` function is present in the ERC-20 token and returns a nonempty string, these MUST be the same value.
113-
*/
114-
symbol?: string;
115-
116-
/**
117-
* The decimals of the ERC-20 token.
118-
* If the `decimals()` function is present in the ERC-20 token, these MUST be the same value.
119-
* Defaults to 18 if neither this parameter nor the ERC-20 `decimals()` function are present.
120-
*/
121-
decimals?: number;
122-
123-
/**
124-
* Provides a short one-paragraph description of the ERC-20 token, without any markup or newlines.
125-
*/
126-
description?: string;
127-
128-
/**
129-
* A URI pointing to a resource with mime type `image/*` that represents this token.
130-
* If the image is a bitmap, it SHOULD have a width between 320 and 1080 pixels
131-
* The image SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive.
132-
*/
133-
image?: string;
134-
135-
/**
136-
* One or more URIs each pointing to a resource with mime type `image/*` that represents this token.
137-
* If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels
138-
* Images SHOULD have an aspect ratio between 1.91:1 and 4:5 inclusive.
139-
*/
140-
images?: string[];
141-
142-
/**
143-
* One or more URIs each pointing to a resource with mime type `image/*` that represent an icon for this token.
144-
* If an image is a bitmap, it SHOULD have a width between 320 and 1080 pixels, and MUST have a height equal to its width
145-
* Images MUST have an aspect ratio of 1:1, and use a transparent background
146-
*/
147-
icons?: string[];
148-
}
149-
```
150-
151-
### ERC-721 Extension
152-
153-
#### Extension to the ERC-721 Metadata Schema
154-
155-
Contracts that implement ERC-721 and use its token metadata URI SHOULD to use the following TypeScript extension to the metadata URI:
156-
157-
```typescript
158-
interface ERC721TokenMetadataInterop extends ERC721TokenMetadata {
159-
/**
160-
* Interoperabiliy, to avoid confusion between different token URIs
161-
**/
162-
interop: InteroperabilityMetadata;
163-
}
164-
```
165-
166-
### ERC-1155 Extension
167-
168-
#### ERC-1155 Interface Extension
169-
170-
[ERC-1155](./eip-1155.md)-compliant contracts using the metadata extension SHOULD implement the following Solidity interface:
171-
172-
```solidity
173-
pragma solidity ^0.8.0;
174-
175-
/// @title ERC-1155 Metadata URI Interoperability Extension
176-
interface ERC1155TokenMetadataInterop /* is ERC1155Metadata */ {
177-
/// @notice Gets an ERC-1046-compliant ERC-1155 token URI
178-
/// @dev The resolved data MUST be in JSON format and support ERC-1046's Extension to the ERC-1155 Token Metadata Schema
179-
/// This MUST be the same uri as the `uri()` function
180-
function tokenURI() external view returns (string);
181-
}
182-
```
183-
184-
#### Extension to the ERC-1155 Metadata Schema
185-
186-
Contracts that implement ERC-1155 and use its token metadata URI are RECOMMENDED to use the following extension to the metadata URI. Contracts that implement the interface described in the ERC-1155 Interface Extension section MUST use the following TypeScript extension:
187-
188-
```typescript
189-
interface ERC1155TokenMetadataInterop extends ERC1155TokenMetadata {
190-
/**
191-
* Interoperabiliy, to avoid confusion between different token URIs
192-
**/
193-
interop: InteroperabilityMetadata;
194-
}
195-
```
196-
197-
### Miscellaneous Recommendations
198-
199-
To save gas, it is RECOMMENDED for compliant contracts not to implement the optional `name()`, `symbol()`, or `decimals()` functions, and instead to only include them in the metadata URI. Additionally, if the decimals is `18`, then it is NOT RECOMMENDED to include the `decimals` field in the metadata.
200-
201-
## Rationale
202-
203-
This ERC makes adding metadata to ERC-20 tokens more straightforward for developers, with minimal to no disruption to the overall ecosystem. Using the same parameter name makes it easier to reuse code.
204-
205-
Additionally, the recommendations not to use ERC-20's `name`, `symbol`, and `decimals` functions save gas.
206-
207-
Built-in interoperability is useful as otherwise it might not be easy to differentiate the type of the token. Interoperability could be done using [ERC-165](./eip-165.md), but static calls are time-inefficient for wallets and websites, and is generally inflexible. Instead, including interoperability data in the token URI increases flexibility while also giving a performance increase.
208-
209-
## Backwards Compatibility
210-
211-
This EIP is fully backwards compatible as its implementation simply extends the functionality of ERC-20 tokens and is optional. Additionally, it makes backward compatible recommendations for ERC-721 and ERC-1155 tokens.
212-
213-
## Security Considerations
214-
215-
### Server-Side Request Forgery (SSRF)
216-
217-
Wallets should be careful about making arbitrary requests to URLs. As such, it is recommended for wallets to sanitize the URI by whitelisting specific schemes and ports. A vulnerable wallet could be tricked into, for example, modifying data on a locally-hosted redis database.
218-
219-
## Copyright
220-
221-
Copyright and related rights waived via [CC0](../LICENSE.md).
1+
This file was moved to https://github.com/ethereum/ercs/blob/master/ercs/erc-1046.md

0 commit comments

Comments
 (0)