mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-04 19:13:48 +00:00
Automatically merged updates to draft EIP(s) 1155
Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing
This commit is contained in:
William Entriken
EIP Automerge Bot
parent
d3078681fc
commit
d581674317
@ -27,7 +27,7 @@ Tokens standards like ERC-20 and ERC-721 require a separate contract to be deplo
|
||||
|
||||
New functionality is possible with this design, such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to "approve" individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.
|
||||
|
||||
# Specification
|
||||
## Specification
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
@ -47,7 +47,7 @@ interface ERC1155 /* is ERC165 */ {
|
||||
Operator MUST be msg.sender.
|
||||
When minting/creating tokens, the `_from` field MUST be set to `0x0`
|
||||
When burning/destroying tokens, the `_to` field MUST be set to `0x0`
|
||||
The total value transferred from address 0x0 minus the total value transferred to 0x0 may be used by clients and exchanges to be added to the "circulating supply" for a given token ID.
|
||||
The total value transferred from address 0x0 minus the total value transferred to 0x0 MAY be used by clients and exchanges to be added to the "circulating supply" for a given token ID.
|
||||
To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0.
|
||||
*/
|
||||
event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);
|
||||
@ -57,7 +57,7 @@ interface ERC1155 /* is ERC165 */ {
|
||||
Operator MUST be msg.sender.
|
||||
When minting/creating tokens, the `_from` field MUST be set to `0x0`
|
||||
When burning/destroying tokens, the `_to` field MUST be set to `0x0`
|
||||
The total value transferred from address 0x0 minus the total value transferred to 0x0 may be used by clients and exchanges to be added to the "circulating supply" for a given token ID.
|
||||
The total value transferred from address 0x0 minus the total value transferred to 0x0 MAY be used by clients and exchanges to be added to the "circulating supply" for a given token ID.
|
||||
To broadcast the existence of multiple token IDs with no initial balance, this SHOULD emit the TransferBatch event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0.
|
||||
*/
|
||||
event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);
|
||||
@ -142,7 +142,7 @@ interface ERC1155 /* is ERC165 */ {
|
||||
}
|
||||
```
|
||||
|
||||
## ERC-1155 Token Receiver
|
||||
### ERC-1155 Token Receiver
|
||||
|
||||
Smart contracts **MUST** implement this interface to accept transfers.
|
||||
|
||||
@ -182,13 +182,13 @@ interface ERC1155TokenReceiver {
|
||||
}
|
||||
```
|
||||
|
||||
## Metadata
|
||||
### Metadata
|
||||
|
||||
The URI value allows for ID substitution by clients. If the string `{id}` exists in any URI, clients MUST replace this with the actual token ID in hexadecimal form. This allows for large number of tokens to use the same on-chain string by defining a URI once, for a large collection of tokens. Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced with `https://token-cdn-domain/780000000000001e000000000000000000000000000000000000000000000000.json` if the client is referring to token ID `780000000000001e000000000000000000000000000000000000000000000000`.
|
||||
|
||||
The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: `[0-9a-f]` with no 0x prefix.
|
||||
|
||||
### Metadata Extensions
|
||||
#### Metadata Extensions
|
||||
|
||||
The following optional extensions can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165].
|
||||
|
||||
@ -211,7 +211,7 @@ interface ERC1155Metadata_URI {
|
||||
}
|
||||
```
|
||||
|
||||
### ERC-1155 Metadata URI JSON Schema
|
||||
#### ERC-1155 Metadata URI JSON Schema
|
||||
|
||||
This JSON schema is loosely based on the "ERC721 Metadata JSON Schema", but includes optional formatting to allow for ID substitution by clients. If the string `{id}` exists in any JSON value, it MUST be replaced with the actual token ID, by all client software that follows this standard.
|
||||
|
||||
@ -275,11 +275,11 @@ An example of an ERC-1155 Metadata JSON file follows. The properties array propo
|
||||
}
|
||||
```
|
||||
|
||||
#### Localization
|
||||
##### Localization
|
||||
|
||||
Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a `localization` attribute, its content may be used to provide localized values for fields that need it. The `localization` attribute should be a sub-object with three attributes: `uri`, `default` and `locales`. If the string `{locale}` exists in any URI, it MUST be replaced with the chosen locale by all client software.
|
||||
Metadata localization should be standardized to increase presentation uniformity accross all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a `localization` attribute, its content MAY be used to provide localized values for fields that need it. The `localization` attribute should be a sub-object with three attributes: `uri`, `default` and `locales`. If the string `{locale}` exists in any URI, it MUST be replaced with the chosen locale by all client software.
|
||||
|
||||
#### JSON Schema
|
||||
##### JSON Schema
|
||||
|
||||
```json
|
||||
{
|
||||
@ -328,7 +328,7 @@ Metadata localization should be standardized to increase presentation uniformity
|
||||
}
|
||||
```
|
||||
|
||||
#### Localized Sample
|
||||
##### Localized Sample
|
||||
|
||||
Base URI:
|
||||
```json
|
||||
@ -359,7 +359,7 @@ fr.json:
|
||||
}
|
||||
```
|
||||
|
||||
## Approval
|
||||
### Approval
|
||||
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface (DRAFT)](https://eips.ethereum.org/EIPS/eip-1761) is suggested.
|
||||
|
||||
@ -391,7 +391,7 @@ As the Ethereum ecosystem continues to grow, many dapps are relying on tradition
|
||||
|
||||
The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts.
|
||||
|
||||
Restricting approval to a certain set of Token IDs, quantities or other rules may be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface (DRAFT)](https://eips.ethereum.org/EIPS/eip-1761) which is compatible with ERC-1155.
|
||||
Restricting approval to a certain set of Token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://github.com/ethereum/EIPs/issues/1761) which is compatible with ERC-1155.
|
||||
|
||||
## Usage
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user