Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC: Multi Token Standard #1155

Open
coinfork opened this Issue Jun 17, 2018 · 256 comments

Comments

Projects
None yet
@coinfork
Copy link
Contributor

coinfork commented Jun 17, 2018

---
eip: 1155
title: ERC-1155 Multi Token Standard
author: Witek Radomski <witek@enjin.com>, Andrew Cooke <andrew@enjin.com>, Philippe Castonguay <pc@horizongames.net>, James Therien <james@enjin.com>, Eric Binet <eric@enjin.com>
type: Standards Track
category: ERC
status: Last Call
review-period-end: 2019-03-28
created: 2018-06-17
discussions-to: https://github.com/ethereum/EIPs/issues/1155
requires: 165
---

Simple Summary

A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (for example, semi-fungible tokens).

Abstract

This standard outlines a smart contract interface that can represent any number of Fungible and Non-Fungible token types. Existing standards such as ERC-20 require deployment of separate contracts per token type. The ERC-721 standard's Token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the ERC-1155 Multi Token Standard allows for each Token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.

The _id parameter is contained in each function's parameters and indicates a specific token or token type in a transaction.

Motivation

Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games, and many other applications can benefit from this flexibility.

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

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.

Smart contracts implementing the ERC-1155 standard MUST implement the ERC1155 and ERC165 interfaces.

pragma solidity ^0.5.2;

/**
    @title ERC-1155 Multi Token Standard
    @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md
    Note: The ERC-165 identifier for this interface is 0xd9b67a26.
 */
interface ERC1155 /* is ERC165 */ {
    /**
        @dev Either TransferSingle or TransferBatch MUST emit when tokens are transferred, including zero value transfers as well as minting or burning.
        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.
        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);
    
    /**
        @dev Either TransferSingle or TransferBatch MUST emit when tokens are transferred, including zero value transfers as well as minting or burning.
        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.
        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);

    /**
        @dev MUST emit when an approval is updated.
    */
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /**
        @dev MUST emit when the URI is updated for a token ID.
        URIs are defined in RFC 3986.
        The URI MUST point a JSON file that conforms to the "ERC-1155 Metadata JSON Schema".
    */
    event URI(string _value, uint256 indexed _id);

    /**
        @notice Transfers value amount of an _id from the _from address to the _to address specified.
        @dev MUST emit TransferSingle event on success.
        Caller must be approved to manage the _from account's tokens (see isApprovedForAll).
        MUST throw if `_to` is the zero address.
        MUST throw if balance of sender for token `_id` is lower than the `_value` sent.
        MUST throw on any other error.
        When transfer is complete, this function MUST check if `_to` is a smart contract (code size > 0). If so, it MUST call `onERC1155Received` on `_to` and revert if the return value is not `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`.
        @param _from    Source address
        @param _to      Target address
        @param _id      ID of the token type
        @param _value   Transfer amount
        @param _data    Additional data with no specified format, sent in call to `_to`
    */
    function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;

    /**
        @notice Send multiple types of Tokens from a 3rd party in one transfer (with safety call).
        @dev MUST emit TransferBatch event on success.
        Caller must be approved to manage the _from account's tokens (see isApprovedForAll).
        MUST throw if `_to` is the zero address.
        MUST throw if length of `_ids` is not the same as length of `_values`.
        MUST throw if any of the balance of sender for token `_ids` is lower than the respective `_values` sent.
        MUST throw on any other error.
        When transfer is complete, this function MUST check if `_to` is a smart contract (code size > 0). If so, it MUST call `onERC1155BatchReceived` on `_to` and revert if the return value is not `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`.
        Transfers and events MUST occur in the array order they were submitted (_ids[0] before _ids[1], etc).
        @param _from    Source addresses
        @param _to      Target addresses
        @param _ids     IDs of each token type
        @param _values  Transfer amounts per token type
        @param _data    Additional data with no specified format, sent in call to `_to`
    */
    function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;

    /**
        @notice Get the balance of an account's Tokens.
        @param _owner  The address of the token holder
        @param _id     ID of the Token
        @return        The _owner's balance of the Token type requested
     */
    function balanceOf(address _owner, uint256 _id) external view returns (uint256);
    
    /**
        @notice Get the balance of multiple account/token pairs
        @param _owners The addresses of the token holders
        @param _ids    ID of the Tokens
        @return        The _owner's balance of the Token types requested (i.e. balance for each (owner, id) pair)
     */
    function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);

    /**
        @notice Enable or disable approval for a third party ("operator") to manage all of the caller's tokens.
        @dev MUST emit the ApprovalForAll event on success.
        @param _operator  Address to add to the set of authorized operators
        @param _approved  True if the operator is approved, false to revoke approval
    */
    function setApprovalForAll(address _operator, bool _approved) external;

    /** 
        @notice Queries the approval status of an operator for a given owner.
        @param _owner     The owner of the Tokens
        @param _operator  Address of authorized operator
        @return           True if the operator is approved, false if not
    */
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

ERC-1155 Token Receiver

Smart contracts MUST implement this interface to accept transfers.

pragma solidity ^0.5.2;

interface ERC1155TokenReceiver {
    /**
        @notice Handle the receipt of a single ERC1155 token type.
        @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated.
        This function MAY throw to revert and reject the transfer.
        Return of other than the magic value MUST result in the transaction being reverted.
        Note: The contract address is always the message sender.
        @param _operator  The address which called the `safeTransferFrom` function
        @param _from      The address which previously owned the token
        @param _id        The id of the token being transferred
        @param _value     The amount of tokens being transferred
        @param _data      Additional data with no specified format
        @return           `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`
    */
    function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);
    
    /**
        @notice Handle the receipt of multiple ERC1155 token types.
        @dev An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeBatchTransferFrom` after the balances have been updated.
        This function MAY throw to revert and reject the transfer.
        Return of other than the magic value WILL result in the transaction being reverted.
        Note: The contract address is always the message sender.
        @param _operator  The address which called the `safeBatchTransferFrom` function
        @param _from      The address which previously owned the token
        @param _ids       An array containing ids of each token being transferred
        @param _values    An array containing amounts of each token being transferred
        @param _data      Additional data with no specified format
        @return           `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`
    */
    function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4);
}

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

The following optional extensions can be identified with the (ERC-165 Standard Interface Detection)[https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md].

Changes to the URI MUST emit the URI event if the change can be expressed with an event. If the optional ERC1155Metadata_URI extension is included, the value returned by this function SHOULD be used to retrieve values for which no event was emitted. The function MUST return the same value as the event if it was emitted.

pragma solidity ^0.5.2;

/**
    Note: The ERC-165 identifier for this interface is 0x0e89341c.
*/
interface ERC1155Metadata_URI {
    /**
        @notice A distinct Uniform Resource Identifier (URI) for a given token.
        @dev URIs are defined in RFC 3986.
        The URI may point to a JSON file that conforms to the "ERC-1155 Metadata JSON Schema".
        @return URI string
    */
    function uri(uint256 _id) external view returns (string memory);
}

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.

The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.

{
    "title": "Token Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this token represents",
        },
        "decimals": {
            "type": "integer",
            "description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation.",
        },
        "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.",
        },
        "properties": {
            "type": "object",
            "description": "Arbitrary properties. Values may be strings, numbers, object or arrays.",
        },
    }
}

An example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata.

{
	"name": "Asset Name",
	"description": "Lorem ipsum...",
	"image": "https:\/\/s3.amazonaws.com\/your-bucket\/images\/{id}.png",
	"properties": {
		"simple_property": "example value",
		"rich_property": {
			"name": "Name",
			"value": "123",
			"display_value": "123 Example Value",
			"class": "emphasis",
			"css": {
				"color": "#ffffff",
				"font-weight": "bold",
				"text-decoration": "underline"
			}
		},
		"array_property": {
			"name": "Name",
			"value": [1,2,3,4],
			"class": "emphasis"
		}
	}
}
Localization

Localization

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

{
    "title": "Token Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this token represents",
        },
        "decimals": {
            "type": "integer",
            "description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation.",
        },
        "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.",
        },
        "properties": {
            "type": "object",
            "description": "Arbitrary properties. Values may be strings, numbers, object or arrays.",
        },
        "localization": {
            "type": "object",
            "required": ["uri", "default", "locales"],
            "properties": {
                "uri": {
                    "type": "string",
                    "description": "The URI pattern to fetch localized data from. This URI should contain the substring `{locale}` which will be replaced with the appropriate locale value before sending the request."
                },
                "default": {
                    "type": "string",
                    "description": "The locale of the default data within the base JSON"
                },
                "locales": {
                    "type": "array",
                    "description": "The list of locales for which data is available. These locales should conform to those defined in the Unicode Common Locale Data Repository (http://cldr.unicode.org/)."
                }
            }
        },
    }
}

Localized Sample

Base URI:

{
  "name": "Advertising Space",
  "description": "Each token represents a unique Ad space in the city.",
  "localization": {
    "uri": "ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT/{locale}.json",
    "default": "en",
    "locales": ["en", "es", "fr"]
  }
}

es.json:

{
  "name": "Espacio Publicitario",
  "description": "Cada token representa un espacio publicitario único en la ciudad."
}

fr.json:

{
  "name": "Espace Publicitaire",
  "description": "Chaque jeton représente un espace publicitaire unique dans la ville."
}

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 is suggested.

Rationale

Metadata Choices

The symbol function (found in the ERC-20 and ERC-721 standards) was not included as we do not believe this is a globally useful piece of data to identify a generic virtual item / asset and are also prone to collisions. Short-hand symbols are used in tickers and currency trading, but they aren't as useful outside of that space.

The name function (for human-readable asset names, on-chain) was removed from the standard to allow the Metadata JSON to be the definitive asset name and reduce duplication of data. This also allows localization for names, which would otherwise be prohibitively expensive if each language string was stored on-chain, not to mention bloating the standard interface. While this decision may add a small burden on implementers to host a JSON file containing metadata, we believe any serious implementation of ERC-1155 will already utilize JSON Metadata.

Upgrades

The requirement to emit TransferSingle or TransferBatch on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in ERC-1538. This will also have the added benefit of providing a stable contract address for users.

Design decision: Supporting non-batch

The standard supports safeTransferFrom and onERC1155Received functions because they are significantly cheaper for single token-type transfers, which is arguably a common use case.

Design decision: Safe transfers only

The standard only supports safe-style transfers, making it possible for receiver contracts to depend on onERC1155Received or onERC1155BatchReceived function to be always called at the end of a transfer.

Guaranteed log trace

As the Ethereum ecosystem continues to grow, many dapps are relying on traditional databases and explorer API services to retrieve and categorize data. The ERC-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. A database or explorer may listen to events and be able to provide indexed and categorized searches of every ERC-1155 token in the contract.

Approval

Approval

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 which is compatible with ERC-1155.

Usage

This standard can be used to represent multiple token types for an entire domain. Both Fungible and Non-Fungible tokens can be stored in the same smart-contract.

Batch Operations

Batch Transfers

The safeBatchTransferFrom function allows for batch transfers of multiple token ids and values. The design of ERC-1155 makes batch transfers possible without the need for a wrapper contract, as with existing token standards. This reduces gas costs when more than one token type is included in a batch transfer, as compared to single transfers with multiple transactions.

Another advantage of standardized batch transfers is the ability for a smart contract to respond to the batch transfer in a single operation using onERC1155BatchReceived.

Batch Balance

The balanceOfBatch function allows clients to retrieve balances of multiple owners and token ids with a single call.

Enumeration

Enumerating from events

In order to keep storage requirements light for contracts implementing ERC-1155, enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the Token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.

ERC-1155 contracts must therefore carefully emit TransferSingle or TransferBatch events in any instance where tokens are created, minted, or destroyed.

Non-Fungible Tokens

Non-Fungible Tokens

The following strategy is an example of how to mix fungible and non-fungible tokens together in the same contract. The top 128 bits of the uint256 _id parameter in any ERC-1155 function could represent the base token ID, while the bottom 128 bits might be used for any extra data passed to the contract.

Non-Fungible tokens can be interacted with using an index based accessor into the contract/token data set. Therefore to access a particular token set within a mixed data contract and particular NFT within that set, _id could be passed as <uint128: base token id><uint128: index of NFT>.

Inside the contract code the two pieces of data needed to access the individual NFT can be extracted with uint128(~0) and the same mask shifted by 128.

Example of split ID bits

uint256 baseToken = 12345 << 128;
uint128 index = 50;

balanceOf(baseToken, msg.sender); // Get balance of the base token
balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible token index

References

Standards

Implementations

Articles & Discussions

Copyright

Copyright and related rights waived via CC0.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 19, 2018

Suggestion: Add in some detail of how to encode extra information into the _itemId to facilitate the mixing of different item/token standards.

An example strategy to mix Fungible and Non-Fungible items together in the same contract for example may be to pass the base item ID in the top 128 bits of the uint256 _itemID parameter and then use the bottom 128 bits for any extra data you wish to pass to the contract.

In the ERC-721 case individual NFTs are interacted with using an index based accessor into the contract/item data set. Therefore to access a particular item set within a mixed data contract and particular NFT within that set, _itemID could be passed as "<uint128: base item id><uint128: index of NFT>".

Inside the contract code the two pieces of data needed to access the individual NFT can be extracted with uint128(~0) and the same mask shifted by 128.

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Jun 24, 2018

Added the split bits strategy to the description, thanks :)

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

Transfer made using this standard, 2 FTs (10k + 500) and 100 NFTs (100):

https://ropsten.etherscan.io/tx/0xfc924192fb068a6326bc28a2f5762be3a4b1fb6a1ef801bf6bf02c06af929d53

FT "ENJ" ID: 0x54e8b965cee12ac713ee58508b0d07300000000000000000000000000000000
FT "Gold" ID: 0x3bf7ded270a4ab1d5e170cc79deb931800000000000000000000000000000000
NFT "Lots of NFTs" ID: 0x4362b8ce48bee741861f523a3b91803c00000000000000000000000000000000

10000, 500 and 100*1 sent in one transaction costing 5480196 gas (~$2.42 at time of tx).

Note, this was done in an advanced solution with a lot more features than a basic impl. Basic/ref impl and gas as compared to current standards in basic form will be added soon.

@ericmuyser

This comment has been minimized.

Copy link

ericmuyser commented Jun 25, 2018

Hyperbridge is interested in potentially supporting this standard in our upcoming marketplace. We'd like to see where other organizations stand on this as it's an obvious problem, and if the proposed solution works for you. @coinfork I don't see source code, so I'm going to take to take it that it's currently proprietary. Is there any examples in the wild as of yet?

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Jun 25, 2018

Hey @ericmuyser thanks for your interest! We currently have a deployed contract on Ropsten (please see AC0DEM0NK3Y's post above) that is specifically tailored to our gaming use-case. We'll consider adding a reference implementation to the standard.

@powether

This comment has been minimized.

Copy link

powether commented Jun 25, 2018

I hope you didn't announce this like "Biggest innovation in the manking". 5480196 gas is unacceptably high.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

"I hope you didn't announce this like "Biggest innovation in the manking". 5480196 gas is unacceptably high."

I think you need to look at the gas cost relative to the alternatives and how this differs from them. If you average this down (even without the fungible transfers that went with it) the above transfer cost ~55K per NFT sent, which compared to many other ERC721 implementations for eg. (seeing numbers 250K+ each) this offers significant savings. A simple ETH transfer costs 21K and ERC20 tokens look to cost anywhere from 35k to 130k each tx after some quick explorer checks in the top 100. So I would say the above cost is quite reasonable.

On top of that there is also the reduction of number of contracts necessary to be deployed to the network, the transaction numbers being reduced (in this case 102 : 1) and also the possible features this would bring that wouldn't be possible with separate contracts and incompatible NFT & FT standards.

@shrugs

This comment has been minimized.

Copy link

shrugs commented Jun 25, 2018

I don't have strong opinions yet, but did y'all explore the option of composing ERC721 and 20/721 to get similar functionality? As in, creating a AllItems contract that is 721 but fully controlled by whatever governance mechanism you'd prefer. Then, owners can create a new item set like createNonFungible(...) to deploy a 721 contract and add that new contract address as one of the tokens tracked by the contract (owned by the AllItems contract itself). Similar for fungible assets. Then clients can get the set of all items via iterating the 721 interface, ERC165 detect fungibility or non-fungibility, and either 1) directly interface with those sub-contracts to manage their items or 2) you could provide similar multi-send features by proxying transfer requests through the AllItems contract that's either an approved operator of the sub-contract or is just an all-seeing authority (deferring the access-control logic to the AllItems contract to verify who owns what before transferring).

Anyway, it might be a little roundabout, but it does avoid the creation of a new standard by extending and composing existing ones, which is neat.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

Hi @shrugs while not getting too far into the implementation details of a system that uses this standard, in the above example where two different fungible types and one non-fungible set were operated on what a user/creator could do is call a "deployERCAdapter" function on the particular type if they so wish which will deploy an adapter contract that is either fully ERC721 or ERC20 compatible depending on the base type. This means the individual set is now backwards compatible with those standards and can therefore be used in any current system that supports them.
So we get the best of both worlds, full compatibility with ERC20 and ERC721 (as an option) but also the ability to mix these two standards together by operating at the 1155 "main level" and so can transfer/operate on these together and on multiple of the types, in the same transaction.

Extending ERC721 rather than making a new standard that can mix different fungibility (and then supporting ERC721 with backwards compatibility) wouldn't have quite worked as ERC721 mandatory standard has certain functions that only make it suitable for a single data set in a single contract such as "balanceOf(address _owner)" and "isApprovedForAll(address _owner, address _operator)" for example.

@shrugs

This comment has been minimized.

Copy link

shrugs commented Jun 25, 2018

@AC0DEM0NK3Y the ERC adaptor is interesting, yeah.

The fungible/non-fungible tokens would not be tracked in a single 721; their contract addresses would be.

AllItems (ERC721, tracking contract addresses)
  |__ Sword contract (ERC20)
  |
  |__ Legendary Armor contract (ERC721)

so each individual contract still fulfills 721 and 20 to the best of their ability, and you add additional features like multi-send and factory methods to the AllItems parent contract.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

That is a way to track perhaps, but is much less user/network friendly. If I want to send you an NFT A and and NFT B and do that through your tracking contract I'd have to call approve on contract A and B separately to give the tracking contract the allowance, then call the tracking contract to do the transfer.
That is 3 individual transactions (4 if your tracking contract doesn't support arrays for transfer API).

By allowing things to be mixed together and stored in a single contract I can transfer A and B to you in a single tx.

A and B contract also have to be deployed. It's more data on the chain than is needed and that is not sustainable and/or limiting imho.
If you consider use cases like a videogames that have lots of different types of NFTs and how many games there are in the market now and will be in the future, having to deploy an ERC20/ERC721 contract to support those types every time is not good for the ETH network as a whole going forward and that is just one use case.

@shrugs

This comment has been minimized.

Copy link

shrugs commented Jun 25, 2018

I mentioned that above as well, perhaps I wasn't clear enough; you can implement multi-send functionality by making the AllItems contract a designated operator (or a super user of sorts) for transferring tokens/items and then implement access control at the AllItems layer, allowing you to skip approvals and send multiple items with a single transaction exactly as you do in 1155. Nothing has changed here.

I agree that composability does come with gas costs, and these should be measured. You can also separate logic and data using proxy patterns and cut down on duplicate logic deployments. (and before someone references the parity wallet, this is very much the same approach that 1155 uses by consolidating the logic and data into a single contract; it's still a single point of failure if there is a show-stopping bug).

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

It sounds like it could work, but it doesn't fix the wastage/management issue. Deploying a contract for every NFT is not future proof imho.

Your pattern seems like it would work with 1155 though. The register function that you are proposing could be something someone implements and then this returns an ID to match the contract address when calling the function. The call to transfer A and B in that case would might be to call:

uint aID = 1155.register(ContractOfA);
uint aIndex = 12345; // NFT index I want to send from contract A
uint bID = 1155.register(ContractOfB);
uint bIndex = 888; // NFT index I want to send from contract B
ContractOfA.makeSuperUser(1155);
ContractOfB.makeSuperUser(1155);
1155.transfer([aID, aIndex, bID, bIndex], [yourAddr,yourAddr],[1,1]);

This now needs an extension to ERC721 to append "makeSuperUser" function.

@shrugs

This comment has been minimized.

Copy link

shrugs commented Jun 25, 2018

((an aside: using an existing standard is the definition of futureproof))

superuser would need to be added, yes. you could also get away with operator functionality that already exists; simply default to setting the approved operator of every token to the AllItems contract. users could revoke, but 1) why would they and 2) to restore previous behavior, they can simply re-approve the operator. compatible with both 20 and 721.

The data/logic separation via proxy is a well-known pattern and does indeed work. The only unknown is the gas implications, which could be measured. Having your sub-items be compatible with 20/721 by default is a very powerful effect. We've only just started the whole NFT thing, and fracturing into another standard instead of leveraging existing ones isn't really a strong move, imo. Existing indexers (Toshi, Trust Wallet, etc) would need to have extra logic to monitor this standard as well. And deploying ERC adaptors for every token just gets you back to the point I'm making; it should just be compatible with the existing standard by default.

Anyway, give it a think and see if it solves the problem you're interested in solving. I'm very familiar with the space and the problems you're facing, specifically around gaming, and have thought about this at length as well. A next step would be profiling the gas costs of a composable approach, which I may mind time to do within the next week or two, but can't guarantee.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

an aside: using an existing standard is the definition of futureproof

I would call that backwards compatible but hey :)

The data/logic separation via proxy is a well-known pattern and does indeed work.

Yes, we do this or sorts in our implementation. Storage contract holds all the data, then the rest is an API over the top of it. Many reasons to do this.
So in the above test, consider that a test of gas costs perhaps.

Thanks for the discussion @shrugs looking forward to more.

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jun 25, 2018

Hello!

Happy to see other people working on something like this. I personally recommend the following changes ;

  1. Remove transfer(...). It's a special case of transferFrom() and is less explicit, which isn't great.

  2. Add safeTransferFrom(...) instead of passing data in second 128 bits. Explicit > implicit should be favored in standards imo.

  3. Change arguments order of transferFrom(uint256[] _itemId, address[] _from, address[] _to, uint256[] _value)nt ordering from transferFrom(uint256[] _itemId, address[] _from, address[] _to, uint256[] _value) to transferFrom(address[] _from, address[] _to, uint256[] _itemId, uint256[] _value) which seems more consistent with current standards.

  4. Change the current approval logic to something like setApprovalForAll() or setOperator() instead of using specific approvals. Approvals are almost exclusively used to give access to your tokens to a trusted/vetted contract. I have yet to see an example of a specific approval value. Even with erc-721, I have yet to see a use case where giving approval to a single ID is useful.

When it comes to transfer() and transferFrom(), is the reason for "not" throwing and return a bool instead to prevent a single transfer from breaking the entire transfer? What does it mean to return false? That at least one of them was unsuccessful? All of them? Not sure I understand the logic here and would love some extra info.

@amittmahajan

This comment has been minimized.

Copy link

amittmahajan commented Jun 25, 2018

Thanks for putting this together!

A few folks (@petejkim (Cipher/Toshi), @lsankar4033 (PepeDapp), @pkieltyka (Horizon Games), and myself (Rare Bits/Fan Bits)) were actually bouncing around a Semi Fungible Token standard that may make sense to combine efforts on given the similarities. I've put it below for posterity. That being said, a couple ideological things that may be worth considering:

  1. ERC721 was just approved after a lot of deliberation and it seems like maintaining this as an evolution/superset of ERC721/ERC20 in terms of nomenclature / API compatibility will help with adoption / building to consensus quickly. We took the approach of starting with the ERC721 spec and then evolving from there to ensure we captured all of the hard work and thought that went into that standard.

  2. This is bigger than games and the ecosystem for NFTs is already spreading well beyond virtual items. Switching from Items to Tokens doesn't make a whole lot of sense given the existing ecosystem that exists around these standards already.

  3. We all agreed that having indexing/metadata functions are required versus optional makes life a lot easier for wallet providers and other indexers trying to display the data and interoperate with these contracts.

pragma solidity ^0.4.20;

/// The goal of this spec is to handle a now-common case of having different
/// token types with fungibility within each type.

/// Many DApps are either using ERC721 with multiple-tokens of the same type or deploying 
/// multiple ERC20 contracts to create fungible tokens within a set non-fungible token types.
/// An example would be a trading card game with different types but where 
/// each card of a given type is indistinguishable from the other. Or an art 
/// token where each print of an art piece is indistinguishable from any other print.

/// This is a *VERY* draft spec that is modified from the (near) final
/// ERC721-spec. We should evolve it as necessary from here.

/// @title ERC->>>TBD<<< Semi-Fungible Token Standard
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-TBD.md
///  Note: the ERC-165 identifier for this interface is >>>TBD<<<
interface ERCTBD /* is ERC165 */ {
    /// @dev This emits when ownership of any SFT changes by any mechanism.
    ///  This event emits when SFTs are created (from == 0) and destroyed
    ///  (to == 0). Exception: during contract creation, any number of SFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that SFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenType, uint256 indexed _value);

    /// @dev This emits when the approved address for an SFT is changed or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that SFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenType, uint256 indexed _value);

    /// @dev This emits when an operator is enabled or disabled for an owner.
    ///  The operator can manage all SFTs of the owner.
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

    /// @notice Returns the total token supply.
    /// @dev Throws if '_tokenType' is not a valid SFT
    /// @param _tokenType The type of SFT to get the totalSupply of. Must be less than the return value of totalTokenTypes
    /// @return The total supply of the given SFT
    function totalSupply(uint256 _tokenType) external view returns (uint256 totalSupply);

    /// @notice Count all SFTs of a given type owned by _owner
    /// @dev Throws if '_tokenType' is not a valid SFT or if _owner is set to the zero-address
    /// @param _owner An address for whom to query the balance
    /// @param _tokenType The type of SFT to get the balance of. Must be less than the return value of totalTokenTypes
    function balanceOf(address _owner, uint256 _tokenType) external view returns (uint256 balance);
    
    /// @notice Return all token types for a given _owner
    /// @param _owner An address for whom to return token types for
    function tokenTypesOf(address _owner) external view returns (uint256[] tokenTypes);

    /// @notice Returns the total number of token types for this contract
    /// @dev Can possibly be zero
    /// @return The total number of token types
    function totalTokenTypes() external view returns (uint256 totalTokenTypes);

    /// @notice Returns the total number of distinct owners who own _tokenType
    /// @dev Can possibly be zero
    /// @return The total number of distinct owners owning _tokenType
    function totalOwners(uint256 _tokenType) external view returns (uint256 totalOwners);

    /// @notice Returns the owner of _tokenType specified by _ownerIndex
    /// @param _ownerIndex Unique identifier of an owner of _tokenType
    /// @return The address of the ownner of _tokenType specified by _ownerIndex
    function ownerOf(uint256 _tokenType, uint256 _ownerIndex) external view returns (address owner);

    /// @notice Transfers the ownership of some SFTs from one address to another address
    /// @dev Throws unless 'msg.sender' is the current owner, an authorized
    ///  operator, or the approved address for the SFTs. Throws if '_from' is
    ///  not the current owner. Throws if '_to' is the zero address. Throws if
    ///  '_tokenType' is not a valid SFT type. When transfer is complete, this function
    ///  checks if '_to' is a smart contract (code size > 0). If so, it calls
    ///  'onERCTBDReceived' on '_to' and throws if the return value is not
    ///  'bytes4(keccak256("onERCTBDReceived(address,address,uint256,bytes)"))'.
    /// @param _from The current owner of the SFTs
    /// @param _to The new owner
    /// @param _tokenType The SFT type to transfer. Must be less than the return value of totalTokenTypes
    /// @param _value Amount of SFT to transfer
    /// @param data Additional data with no specified format, sent in call to '_to'
    function safeTransferFrom(address _from, address _to, uint256 _tokenType, uint256 _value, bytes data) external payable;

    /// @notice Transfers the ownership of some SFTs from one address to another address
    /// @dev This works identically to the other function with an extra data parameter,
    ///  except this function just sets data to "".
    /// @param _from The current owner of the SFTs
    /// @param _to The new owner
    /// @param _tokenType The SFT type to transfer. Must be less than the return value of totalTokenTypes
    /// @param _value Amount of SFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenType, uint256 _value) external payable;

    /// @notice Transfer ownership of some SFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT '_to' IS CAPABLE OF RECEIVING SFTS OR ELSE
    ///  THEY MAY BE PERMANENTLY LOST
    /// @dev Throws unless 'msg.sender' is the current owner, an authorized
    ///  operator, or the approved address for this SFT. Throws if '_from' is
    ///  not the current owner. Throws if '_to' is the zero address. Throws if
    ///  '_tokenType' is not a valid SFT.
    /// @param _from The current owner of the SFT
    /// @param _to The new owner
    /// @param _tokenType The SFT type to transfer. Must be less than the return value of totalTokenTypes
    function transferFrom(address _from, address _to, uint256 _tokenType, uint256 _value) external payable;

    /// @notice Change or reaffirm the approved address for some SFTs
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless 'msg.sender' is the current owner of the SFTs, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved SFT controller
    /// @param _tokenType The SFT type to approve. Must be less than the return value of totalTokenTypes
    /// @param _value The amount of SFT able to be withdrawn
    function approve(address _approved, uint256 _tokenType, uint256 _value) external payable;

    /// @notice Enable or disable approval for a third party ("operator") to manage
    ///  all of msg.sender's assets
    /// @dev Emits the ApprovalForAll event. The contract MUST allow
    ///  multiple operators per owner.
    /// @param _operator Address to add to the set of authorized operators
    /// @param _approved True if the operator is approved, false to revoke approval
    function setApprovalForAll(address _operator, bool _approved) external;

    /// @notice Get the amount of allowance a spender has for a given owner and SFT type
    /// @param _owner The address that owns the SFTs
    /// @param _spender The address that is operating on behalf of the owner
    /// @param _tokenType The type of SFT to find the approved address for. Must be less than the return value of totalTokenTypes
    /// @return The amount able to be spent by the spender for a given owner and type
    function allowance(address _owner, address _spender, uint256 _tokenType) external view returns (uint256);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the SFTs
    /// @param _operator The address that acts on behalf of the owner
    /// @return True if '_operator' is an approved operator for '_owner', false otherwise
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);

    /// @notice A descriptive name for a collection of SFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for SFTs of a given type
    function symbol(uint256 _tokenType) external view returns (string _symbol);

    /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
    /// @dev Throws if '_tokenType' is not a valid SFT. URIs are defined in RFC
    ///  3986. The URI may point to a JSON file that conforms to the "ERC721
    ///  Metadata JSON Schema".
    function tokenURI(uint256 _tokenType) external view returns (string);    
}

interface ERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return 'true' if the contract implements 'interfaceID' and
    ///  'interfaceID' is not 0xffffffff, 'false' otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}
@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jun 25, 2018

@amittmahajan Could you explain what ownerOf and totalOwners are referring to? It's not clear to me what the intentions are with these functions.

@amittmahajan

This comment has been minimized.

Copy link

amittmahajan commented Jun 25, 2018

@PhABC totalOwners is referring to the number of unique addresses that hold a given tokenType. ownerOf is one element of that "owners" array of a given tokenType. it allows you to enumerate every owner of a given tokenType.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 25, 2018

Thanks for adding that @amittmahajan and we'll discuss it internally. What first springs to mind however is that your proposal standard does not allow for approving/transferring etc. on multiple things in one shot as they do not take array arguments.

Also the functions such as @PhABC is talking about like totalOwners sound immediately to me like they would need more storage and so gas costs to maintain. I would advocate for as little as possible on chain storage and this sort of "metadata" instead recorded off-chain.
You could find the owners/track balance via transfer log events for eg. and store that info elsewhere. It isn't necessary for the users to have that info stored and the developers can get this info from a local node.
The less we bloat ETH while providing great features for the users the better imho.

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jun 25, 2018

@amittmahajan Ah I see. How do you keep track of all the owners? I can understand iterating over all token types an user owns if the totsl number of token types is somewhat low, but I can't really see a way to iterate over the owners unless you keep a big array of owners for each token types. Any insights?

@dwking2000

This comment has been minimized.

Copy link

dwking2000 commented Jun 25, 2018

Good to see this proposal.

Our use case is for ERC-20 tokens. We want to 'color' tokens by community while allowing them to be fungible on exchanges as a 'clear' token. Within communities transfer of colored tokens will be allowed in the community color only, but outside of communities the rest of the world will see the tokens as a single ERC-20 type token. This looks like a similar solution I came up with to solve this.

A standard will encourage the creation of tools and potentially wallets will that can deal with this paradigm. My question: is this EIP just for NFTs or is it intended to be used for ERC-20 tokens as well?

@amittmahajan

This comment has been minimized.

Copy link

amittmahajan commented Jun 26, 2018

@PhABC @AC0DEM0NK3Y re: totalOwners, ownerOf. not married to including these because we've built out the infra already to support it but I included it with the intent of spurring the discussion if there was a more clever way to implement it / see what the community demand for such a feature would be.

re: multiple token transfer, i think it's a good idea and has a lot of use cases. That being said, I wouldn't be surprised if that function is mostly called with a single type. Perhaps it makes sense to implement that as a new function (multiTransfer) to reduce complexity for the most basic use case of transfer. If I were to vote right now, i'd say stick with the current version (one func transfer that takes multiple types) but wanted to raise the topic of two funcs to be diligent.

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jun 26, 2018

@amittmahajan batch transfer is critical for these types of tokens, imo, it's really what makes such an interface interesting. I personally vote for batchTransferFrom(..) to follow naming conventions. I do agree that some applications might favor single type transfer while others might utilize the batch transfer functionality more often.Convince me :).

I personally would not include totalOwners & ownerOf as they add significant gas cost and their on-chain utility seems limited.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 26, 2018

We originally had a transfer (single) and multiTransfer (array) in the standard but after testing gas differences and usability we decided it better to just use the array version and name it transfer for simplicity.

If you pass in MEW for eg. as well as other methods, the difference in array vs non-array method is almost identical (it is identical in MEW) and the gas difference is negligible and the power of the feature is huge for gas savings and for functionaility.

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jun 26, 2018

With my implementation, it costs around 400k gas to send 100 token types, but single transfer is about 2k gas more expensive using the batchTransferFrom function compared to the transferFrom().

@lsankar4033

This comment has been minimized.

Copy link

lsankar4033 commented Jun 26, 2018

@AC0DEM0NK3Y one downside of a single transfer method (vs. separate transfer and multiTransfer methods) is that there's an additional burden on 3rd parties integrating with all standards, as they have to remember that transfer has different argument lists (address vs. address[]) for ERC721/20/1155.

I think the simplicity cost of having two methods is worth the integration win of cleaner unification with existing standards.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Jun 26, 2018

@lsankar4033 We'll talk/test about that internally and come back on it.

My first thought is that transfer has to change even in singular form to include the token/item type:

function transfer(address _to, uint256 _value)

vs

function transfer(uint256 _itemId, address _to, uint256 _value)
or
function transfer(uint256[] _itemId, address[] _to, uint256[] _value)

so if it has to change signature anyway, why not go for the most powerful version if it is just as easy to call, almost as cheap and provides the opportunity for much more functionality?

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Dec 28, 2018

@fulldecent

Hello! Congratulations on getting this far. Here is my review ERC-1155 at 38def77.

Thank you for the in-depth commentary! I'll answer some of your comment below:

Discussing the design choice of whether to include or not include hierarchal tokens in the standard is outside the scope of this last call review.

I agree that we could make the motivation section more application agnostic.

Please use the latest version of Solidity in examples. The posted code snippets are not compatible with the latest released compiler.

That shouldn't be a problem either.

The reference implementation should not be work-in-progress, it should be a fully usable product, with test cases using Truffle (or maybe try Specron). If the reference implementation is not usable then standardization should be delayed in my opinion.

Enjin's implementation seems to be up to date with current standard. Horizon's is not as of now, but will be tomorrow. I was initially intending on waiting for the EIP to be finalized to make the final edits, but i'm happy to make them sooner.

The cited implementations include only token deployments. However, this EIP addresses a standard for tokens, which involves the production and consumption of data. Only producers are cited, but I hope consumers can also be cited as a test for actual interoperability.

I am not sure to understand this point fully. If you could please point out examples found in the ERC-20 and ERC-721 standards that we could use as guides, we would appreciate it.

This means that strings and batch transfers cannot be inspected via event logs.

Two variables per transfer events are indexed (from and to), while three are not (ids, values, data), where the limit of indexed variable per events is 3. We believe most people will filter events based on a specific from or to value, not for a specific sequence of ids or values.

(You could do it with transaction logs. But hot damn, nobody wants to do that.)

If your goal is to maintain an off-chain database of the state of a contract, using indexed arguments for transfer events isn't particularly useful as you need to process all transfer events for all indexed parameters. This is what services like Google BigQuery or Graph Protocol do in order to build a database of contracts state.

But to achieve advertised savings of "Gas savings improves with the number of token types in the batch transfer" or to get anywhere close to the possible 80% to 90% improvements then a specialized implementation will be necessary. It seems like this claim was lifted from the Horizon article without justification. At current, the wording is misleading and/or inaccurate. I would go further and propose a correction, but again the motivation section is not clear enough for me to understand the needs.

We could mention the base gas cost saved compared to using a wrapper contract for ERC-20 or ERC-721, which would be more accurate. Our (Horizon's) implementation is indeed more specific, but is only possible when departing from the ERC-721 and ERC-20 standards. I am personally OK with removing this link from the standard if others believe it necessary, but I believe, if better clarified above, that it is relevant information for token implementers considering using ERC-1155.

...

Thank you again!

@awaldstein

This comment has been minimized.

Copy link

awaldstein commented Jan 7, 2019

Hi--
My focus is on Reimagining Philanthropy with NFTs.

Was a team leader on the Honu the CryptoKitty Charity Auction project with CryptoKitties and Bill Tai of Actai Global and Sir Richard Branson's team at Ocean Elders.

Putting together a presentation for NFT.NYC and exploring how 1155 can become an added building block to create a future for this.

Looking for projects, ideas, visionaries who can help me (with attribution of course) draw a picture of a possible future with new tools and protocols.

Contact info.
arnold@waldstein.com
@awaldstein skype

Thanks!

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Jan 9, 2019

I notice that the ENJIN team is pushing press releases to promote Enjin blockchain explorer. It is comparing ERC-1155 versus "legacy" ERC-721. Here is one such press release published on PR Newswire, ostensibly by the Enjin team.

In contrast, ERC-1155 does not designate 721 as deprecated and does not state that 721 replaces 721. And it does explicitly state deficiencies of 1155 against 721 which indicates continued use cases for 721. Furthermore ERC-1155 is not even finalized yet.

Reports of ERC-721's death are greatly exaggerated. :-p

This side topic is being discussed further here -> https://twitter.com/fulldecent/status/1082940498506002432

@pkieltyka

This comment has been minimized.

Copy link

pkieltyka commented Jan 9, 2019

yes, I agree with @fulldecent that the narrative of 721 as "legacy" is incorrect and overstated. 1155 is great, and we've come up against the same design needs in our projects, but I still see NFT-only utility in 721 for the distant future

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Jan 9, 2019

Thank you very much for the feedback! We went over all the points mentioned above and updated the descriptions to be more thorough, added a Rationale section, and the majority of your suggestions are resolved.

I have updated the EIP status to Draft again to allow for a (hopefully) final review! :)

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Jan 9, 2019

@fulldecent

Where do you see a mention of ERC-721 as being legacy standard or dead in the EIP? I don't see any mention of the Enjin blockchain explorer either.

If you are referring to Enjin's press releases content and not this EIP per say, I believe it would be more appropriate to argue these points outside this thread.

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Jan 13, 2019

@AC0DEM0NK3Y Thank you for the invitation. Please reach me at entriken@phor.net, we can catch up from there.

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Jan 31, 2019

@ericbinet has put some good work into a scoped approval extension to the standard. After working on some implementations, we realized that global ApprovalForAll was too open for typical usage. This extension aims to provide a flexible way to approve different scopes of token IDs.

I've merged the changes and updated the standard at the top of this thread. We would love to hear any further feedback from the community regarding this extension!

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Jan 31, 2019

ERCs are standards. So I am more interested to hear about actual applications that have been deployed, on mainnet, which have real uses cases.

"... we realized that global ApprovalForAll" is a great realization for deploying your own application.

But the standard should be supporting actual, concrete use cases.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Feb 1, 2019

ERCs are standards. So I am more interested to hear about actual applications that have been deployed, on mainnet, which have real uses cases.

"... we realized that global ApprovalForAll" is a great realization for deploying your own application.

But the standard should be supporting actual, concrete use cases.

I don't know if github is really the place to be discussing standards philosophy in terms of use cases but since it was brought up I will at least say that I do not personally agree that a standard has to cover just a fixed set of known quantity use cases and that is that.

Personally I want a standard to be able to take care of known use cases at the current time and possible use cases in the future that may (and via the nature of time likely will) arrive and for things we haven't even thought of yet.

I think back of a standard like rs232, a great standard for communicating with an external device in a 1:1 manner. It did its job for what it was good for and is still in use today in certain applications as it is a simple standard that does what it can do well.

The introduction of the USB standard some could have argued (and did at the time if you check internet history) was not needed as they had the standard they needed already in rs232 for connecting things together and why don't they just improve that instead of creating a new standard that is not in use and not widely supported by hardware at the time?

What wasn't fully appreciated in those early stages I think was that USB could do the 1:1 connection just as rs232 could do of course and a little faster sure, but that wasn't really the important part. The things people were not focusing on was what could it possibly do that wasn't thought of yet and the impact that would have on the users?
A good example there was a usb hub being a thing that wasn't really seen as necessary at the time, but is something that made connecting multiple devices to a single port possible which then made things far far easier for users who just want to plug and play and don't particularly care how it works under the hood as much as the developers do.
By not just focusing on the concrete of the time, among other things, USB became a ubiquitous standard (that albeit needed alterations over time), by focusing on flexibility and what could be rather than what was.

So anyway, back to the topic at hand. I think the scopes offer some possibilities within either a multi-class implementation of 1155 or a single class usage of 1155.

An example I may have there is perhaps you want to have all your types of "asset" in one single class usage of 1155. Lets say this is a game that uses cards to represent your deck to play, I will pick Hearthstone as a well known game that could be copied and used for that idea:

So in Hearthstone you have a set of cards that you might consider common, and you might have a set of cards you consider rare. Now what you could do as a company making that game is partition your card set out so your "common" types go to one 1155 contract deployed and your "rare" types go to another 1155 contract you deploy. This is nice for the developer it makes things somewhat easier for them to partition these things out in that fashion.
Now if they want a trading system in game or an exchange for which these players can trade easily through their system they are now probably going to want the users to give ApprovalForAll to both classes, not ideal in terms of ux to ask for double permission but hey.
They now have full control of that users entire card set. Which could be fine, but it might be not.
They also now have to deal with interacting with two sets of contracts if there are multi-class movements in one intention and their backend infrastructure has two sets of contracts to watch and pull events from.
Any new class they introduce in the future is additive to this overhead and an external party that is involved with that game has to be made aware that this new class type contract exists and alter their systems to accommodate it.
Maybe they are fine with all that and the 1155 standard allows for this.

If however they decide actually it would be much simpler if they had all their types in one contract that could be extended upon, maybe that simplifies things for them and the users.
The users only have to do a setApprovalForAll once and then they have access to the full set of class types for that user and they are good. Any new types added they will automatically have the approvals setup, there is no having to setup infrastructure to deal with the new class type for either that game developer or any external party interfacing with that games' assets for those users. The UX advantages and maintenance of the ecosystem is significantly improved.
The trouble is, what if the user doesn't want to give approval to all the class types? Maybe they are fine with all common types being able to be controlled by a dex (or someone else) but not the rares. That is where scoping can come in. Devs can put the two class types in two scopes and the users can approve just the "common" scope and they now have given approval for that type and not the rare.

Now that is one example...but what if scopes were not just used for approvals? What if you could put certain sets of items in a scope then attach a URI to that scope to give it a particular context?
I can think of a fair few use cases for that, especially for exchanges but I can't think of every single case it could cover in the future, but I like the fact that this standard allows for the possibility of the unknown and for it to not bound developers creativity with what we can currently conceive.

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Feb 2, 2019

Still "ApprovalForAll was too open for typical usage" would be much more helpful with more citations and actual use cases.

This line gets closer:

Now if they want a trading system in game or an exchange for which these players can trade easily through their system they are now probably going to want the users to give ApprovalForAll to both classes, not ideal in terms of ux to ask for double permission but hey.

I am hoping to hear more about what the end user wants and whey they are trying to accomplish with the application.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Feb 3, 2019

The Common and Rare sets example I gave that could be expanded (to say Epic for instance) and sub-categorized within those rarities is a use case typical of hundreds if not thousands of games.

But a more concrete example involving eth as of today I guess could be something like Cryptokitties.

I'm not too familiar with how CK implementation works anymore as I haven't really kept up with it or 721 since I/we realized it wasn't a typical game with lots of types and more of a singular collectables thing, and that 721 is quite unsuitable for most games like we are aiming to support given the lack of typing in key functions, as most full fledged games have many, possibly in the hundreds and also mix fungibility (this was basically why we started on 1155 instead of just using that) but with their generations it seems they have at least one "scope" type in there.

So from what I understand the earlier generations are more valuable than later ones, either in monetary or maybe sentimental value.

If I was a user that owned 10gen0 and 100gen1+ and wanted to go on an exchange maybe I would only want to give access to gen1 and above and not allow risk of someone else having access to my beloved gen0's.

In that particular implementation I would have a scope created for each generation, then instead of a user either having to do an approve all and put their gen0's at risk they could just approve the generation scopes they are comfortable with.

If as I think it is in CK gen0 is up to an index and anything after that is non-gen0 then you could actually scope gen1 and above by adding an ID range of the first gen1 ID to 0xffff...

This means a user only has to approve that gen1 and above scope once and so have a nicer ux experience on an exchange while keeping their gen0's secure.

On-top, maybe you can sub scope and say all cats with hats, or create a bundle scope or such and such then attach a Uri and give that scope extra context.
Maybe I bundle together a gen0 cat with a cape and a Unicorn Hat and call it "Supercat: Meowster of the Universe" and do things with that...

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Feb 4, 2019

@ericbinet @coinfork

After working on some implementations, we realized that global ApprovalForAll was too open for typical usage. This extension aims to provide a flexible way to approve different scopes of token IDs.

with ApprovalForAll it is possible to implement such scoped approval in an external smart contract. As such the extension for scoped approval does not need to be part of this standard.

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Feb 4, 2019

with ApprovalForAll it is possible to implement such scoped approval in an external smart contract. As such the extension for scoped approval does not need to be part of this standard.

The reason for including this in the standard (as an extension) is to provide a common way for ERC-1155 contracts and dapps (exchanges, games, etc) to safely approve some subset of tokens. If everyone was expected to roll-their-own smart contract for approval there would be no known or accepted of doing this. Think of a deployed dapp that wants to interact with all ERC-1155 tokens and the practical usage of this in the real world.

Interested in hearing any counter-arguments to this point - but it seems to me that 90%+ of users would end up using the known approval mechanism out of convenience.

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Feb 5, 2019

The reason for including this in the standard (as an extension) is to provide a common way for ERC-1155 contracts and dapps (exchanges, games, etc) to safely approve some subset of tokens. If everyone was expected to roll-their-own smart contract for approval there would be no known or accepted of doing this. Think of a deployed dapp that wants to interact with all ERC-1155 tokens and the practical usage of this in the real world.

Actually if the smart contract responsible for scoped approval is exterior to the ERC1155 standard, we would only need one to be published, instead of having each ERC1155 to implement it in their contract.
The only thing needed in ERC1155 for that is ApprovalForAll.

This also means that instead of such scoped approval being optional, it becomes automatically enabled for all ERC1155 implementation..

Furthermore while I understand that this extension would be optional, it nevertheless increase the scope of the standard.

@AC0DEM0NK3Y

This comment has been minimized.

Copy link

AC0DEM0NK3Y commented Feb 5, 2019

Forgive me if I am reading you wrong but it seems your proposal is to have one contract that controls access to all other 1155 implementations out there? Isn't that going to be:

a) Unwieldy, we have to design one implementation to cover all. This leaves no room for individual impl details and so is prone to fracturing imo.
b) Means we have to have consensus on implementation for everyone that wants to use that i.e. long time waiting and circling the runway, to the point that it probably wont get made (or fractured as above).
c) Extra gas costs for everyone involved to jump the hoop of the external contract.

Also, think about this practically. In my CryptoKitties example above they have the equivalent of setApprovalForAll and didn't have a built-in scoping system to lean on. So to provide protection to users for specific generations there should be an external contract to provide that.
CK is one of the most mature and used asset classes on eth afaik, is there such a thing to provide this for users? I don't believe there is.
If I'm wrong and there is, it was created and not widely publicized and in use by all the points of entry for a user to give approval on their Kitties (exchanges) afaik.
If one was made now, think of the logistics of getting everyone to alter their system to accommodate for this brand new way of approving. And this is just for CK what about all other applications out there that may decide they want scoping too after their users demand or expect it.
I think the friction is so high to get something like that pushed through the entire ecosystem what will actually happen in the majority is users will simply have to accept giving up complete approval for all their assets to third party exchanges and the like. As an advocate for the users more than I am devs, I am strongly in favor of doing something about that for them at the base.

That said, as Witek mentioned it is optional. If you don't want to add grouping/scoping and possible approvals built-in to your implementation there is nothing stopping you omitting the addition of the interface for it and doing it in the manner you suggest. As a dev you have flexibility to choose between a standardized manner or a custom manner external to your impl that people have to point to in addition to your main contracts api.
That seems to be the best of both worlds to me.

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Feb 8, 2019

@AC0DEM0NK3Y

Forgive me if I am reading you wrong but it seems your proposal is to have one contract that controls access to all other 1155 implementations out there?

It is indeed the idea. If the semantic is well defined there would be no point of multiple implementation but there would nothing preventing having multiple implementation. Users would simply prefers the one that has been proven to be safe.

a) Unwieldy, we have to design one implementation to cover all. This leaves no room for individual impl details and so is prone to fracturing imo.

I am not sure I follow your reasoning here. The idea of having the scoped approval extension in the erc1155 standard is to define the semantic of it. Implementation details should not influence it.

This means that if we can come up with an agreement on the semantic of it as part of ERC1155, we will already have a canonical implementation that could be implemented in an external contract that ERC1155 tokens could pre-approve (removing the need for pre-approval for those erc1155 smart contract that chose to trust it).

it is true though that having an external contract for scoped approval might give rise to different implementation and semantic but this could be a good thing as it gives freedom of experimentation for different scoping mechanism not thought as yet. While this can lead to some sort of fragmentation, the only effect would be requiring users to approve new smart contract (but only if those introduce a meaningful improvement for the dapp's point of view, else dapps has incentive to reuse existing implementation, avoiding that way the need to require extra approval)

b) Means we have to have consensus on implementation for everyone that wants to use that i.e. long time waiting and circling the runway, to the point that it probably wont get made (or fractured as above).

There is no need of consensus, not even on the interface as any dapp can have their own implementation. But if we can come up with one canonical implementation, ERC1155 contracts could pre-approve it removing the need for an extra approval.

c) Extra gas costs for everyone involved to jump the hoop of the external contract.

I don't expect the gas cost to be significant compared to the operation being done.

CK is one of the most mature and used asset classes on eth afaik, is there such a thing to provide this for users? I don't believe there is.

It could simply means there were no real user need for it

I think the friction is so high to get something like that pushed through the entire ecosystem what will actually happen in the majority is users will simply have to accept giving up complete approval for all their assets to third party exchanges and the like. As an advocate for the users more than I am devs, I am strongly in favor of doing something about that for them at the base.

This is up to the dapp developers. Nothing block them form not using the extension too. Also since the extension is optional, the dapps cannot provide a similar experience for all tokens type. On the other hand if they have an external smart contract it will work on all items without requiring support from the erc1155 implementation. I do not see why dapps would not offers such scoped approval if users wants it.

That said, as Witek mentioned it is optional. If you don't want to add grouping/scoping and possible approvals built-in to your implementation there is nothing stopping you omitting the addition of the interface for it and doing it in the manner you suggest.

The point is that such extension is not necessary and that it add complexity to ERC1155 which was nearing completion (it was in "last call" not long ago) and removing such extension would allow to focus on the core proposal of ERC1155 and make it final quicker.

Of course we could add as many optional extension as we want. The point of a standard is to have something to rely on. Optional extension are not good on that ground since they introduce fragmentation. Dapps can't relies on their existence and have to add special case confusing potentially their users : "Why can't I approve specifically this set of item, like I can do for these items?"

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Feb 20, 2019

Thank you so much for the feedback! I have separated out the Scoped Approval to its own standard, and I have updated ERC-1155 with the rationale for this. Let's work on bringing this to Last Call again shortly.

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Mar 1, 2019

Hi,

While it is still a work in progress, here is the link to the ERC1155 implementation we are using @pixowl : https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset

This is going to be the token smart contract used for our upcoming game platform The Sandbox

It is a dual ERC1155 / ERC721 contract so feel free to add the link to the standard as an example of such possibility.

Thanks

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Mar 6, 2019

Hi,

While it is still a work in progress, here is the link to the ERC1155 implementation we are using @pixowl : https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset

This is going to be the token smart contract used for our upcoming game platform The Sandbox

It is a dual ERC1155 / ERC721 contract so feel free to add the link to the standard as an example of such possibility.

Thanks

Added it under Implementations. Thank you!

@coinfork

This comment has been minimized.

Copy link
Contributor Author

coinfork commented Mar 6, 2019

Hello @cdetrio @Arachnid I'd like to request for this EIP to be moved to Last Call status. The EIP meets the required criteria and has at least 4 implementations.

@Georgi87

This comment has been minimized.

Copy link

Georgi87 commented Mar 19, 2019

We (Gnosis) are using ERC1155 in our new prediction market implementation (https://github.com/gnosis/hg-contracts). Different outcomes of prediction markets are represented with different tokens. ERC1155 allows us to significantly reduce gas costs by managing all tokens/outcomes in one contract.

We agree with all rationals but question the design decision to support only safe transfers for the following reasons:

  1. All existing smart contract accounts are excluded from using ERC1155 tokens as they don’t implement the required interfaces. This includes old Gnosis multisig contracts but also new smart contract account designs like the Gnosis Safe contracts, which don’t support ERC1155.
  2. It adds gas costs to every transfer operation for validating the account type and eventually validating the return value of the smart contract call.

The main benefit of using safe transfers is to ensure tokens won’t get lost by sending them to smart contracts, which cannot handle ERC1155 tokens.

In our view any more sophisticated validations of user inputs should be done on the user interface level. It is not the task of a smart contract to validate all user inputs.

We suggest to not require contracts to implement the ERC1155 token receiver interface and would favor to add functions to transfer ERC1155 tokens without calling the receiving contract.

I apologize for not participating in this discussion earlier and I hope this can still be taken into consideration.

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Mar 19, 2019

Hey @Georgi87 , thanks for the comment! You are saying the smart contract accounts can't receive ERC-1155 as they do not implement the onERC1155Received()? Now that you mention this, perhaps the main problem is the lack of abstraction with the onReceive() function, which should be a verifying against a mapping variable on the receiver side instead of hard-coding a function for each standard.

Regarding your suggestion:

We suggest to not require contracts to implement the ERC1155 token receiver interface and would favor to add functions to transfer ERC1155 tokens without calling the receiving contract.

We had this debate many times and I personally think this is a reasonable suggestion. The main problem we had was that we need to not only add transferFrom method, but also batchTransferFrom() and that now users have less guarantees that their tokens will be transferred. I agree that verifying at the UI level makes more sense, but it's an added complexity that isn't certain to be implemented by all interfaces.

We opted for the simplicity, trading off small amount of gas, but I personally did not consider existing multisigs and smart wallets in this decision. Curious to hear what others think @AC0DEM0NK3Y @coinfork @wighawag

@JamesTherien

This comment has been minimized.

Copy link

JamesTherien commented Mar 19, 2019

@Georgi87, you can solve the vanilla multi-sig contract issue easily. Just use an ERC1155 escrow contract contract owned by the multi-sig wallet.

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Mar 21, 2019

Hi @Georgi87 @PhABC

I personally would not mind adding the "unsafe" variants but a more robust option (that preserve the guarantees provided by the current spec) would be to use #1820 like #777 does so wallets like gnosis safe can simply register a receiving contract to handle onERC1155Received and onERC1155BatchReceived on its behalf.

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Mar 26, 2019

If anybody else is starting a last call review. Here are the changes since the previous last call.

38def77...masterdiff-a2c479cb10d20a1fefb8f0e226869334

@fulldecent

This comment has been minimized.

Copy link
Contributor

fulldecent commented Mar 26, 2019

Hello team, this is getting better. Here is my review of ERC-1155 at 9ce2e5f. My previous review (above on 2018-12-28) looked at 38def77. This is conceptual-level review based on a reading of the EIP text itself. I have not attempted to implement the specification nor have I reviewed or ran the example implementations. This review includes every outstanding item anew, even if it was already stated above.

Formatting

This EIP is formatted with extensive use of <details>/ <summary>. This looks cool when viewed in GitHub, but unfortunately it does not render properly on eips.ethereum.org. The preferred citation for ERC-1155 is at https://eips.ethereum.org/EIPS/eip-1155 (as per authoritative source) so this should be targeted to look best at that medium.

Screen Shot 2019-03-25 at 11 53 55 PM

Please switch to normal heading/text Markdown formatting.

Solidity version

Please use the latest version of Solidity in all examples. This is a recommendation provided by the Solidity project.

Inline hyperlink

Please move the remaining hyperlinks down to the references section. This is the current style guide for EIPs.

ApprovalForAll event documentation

The documentation could be more clear. Currently it is:

@dev MUST emit when an approval is updated.

Compare to the related documentation in ERC-721:

/// @dev This emits when an operator is enabled or disabled for an owner.
///  The operator can manage all NFTs of the owner.

The risk as current is that the language below (Specification/Approval) also refers to other approval mechanisms. This could lead to an unclear interpretation of the standard.

Transfers include undefined behavior

The specification for safeTransferFrom is a strange departure from other standards such as ERC-721 and ERC-20. Specifically:

  • A valid implementation may allow anybody to transfer tokens using safeTransferFrom, even if they are not authorized.
  • Through a perverse reading of the specification, it would be legal for an implementation to transfer a token, emit event, then decide the transfer was unauthorized and "not complete", and not call onERC1155Received on the recipient.
  • "Transfers and events MUST occur..." is open to much interpretation.
    • Is this legal: transfer id[0], onERC1155BatchReceived(0), transfer id[1], onERC1155BatchReceived(1), emit(0+1)
    • Is this legal: transfer id[0], transfer id[1], onERC1155BatchReceived(0), onERC1155BatchReceived(1), emit(0+1)

Other notes:

  • "Throw" and "revert" are used interchangeably — pick one
  • "Success" and "complete" are used interchangeably — pick one

Later in the document, under Approvals, this open (literally: vague) specification is used for future extensibility features. Specifically the part that references ERC-1761.

I just want to say that all of this is okay, your specification can do this. But you might want to beef up the rationale to explain this as an active decision you have considered and made.

Metadata

It is currently unspecificed whether leading zeros are necessary for {id}. Please specify this to remove confusion and incompatibilities.

In other words, is the URL

https://a.b/123

or

https://a.b/000000000000000000000000000000000000000000000000000123

Also, this specification is unclear:

Changes to the URI MUST emit the URI event if the change can be expressed with an event

I am wholy unsure what the prescription is in that sentence.

Enumerating

The claim in the EIP is:

… enumeration (discovering the IDs and values of tokens) must be done using event logs. It is RECOMMENDED that clients such as exchanges and blockchain explorers maintain a local database containing the Token ID, Supply, and URI at the minimum. This can be built from each TransferSingle, TransferBatch, and URI event, starting from the block the smart contract was deployed until the latest block.

In other words, the off-chain observer would like to know the URI and total circulating supply for each token ID. And they should do this by observing the TransferSingle, TransferBatch and URI events.

This is not possible using this approach. In other words, it is not possible to inspect an ERC-1155 and know how many of any type of token are in existance.*

The caveat(*) is that it is not possible using event logs. Yes, it is possible using internal transactions. But a well funded token explorer (Etherscan) has been working on using this technique to track ERC-20 and ERC-721 transfers for years and they are still not done.

I could not find any deployed ERC-1155 implementations to inspect their transactions. I wanted to provide a link here.

Backwards Compatibility

This section is missing from the EIP.

Test Cases

This section is missing from the EIP.

Implementations

The implementations must be completed before any EIP is given status “Final”.

This standard explains how a token contract can be implemented. Please cite examples of implementations which are deployed and which implement this standard. This is the producer of information.

This standard also explains the perspective of block "explorers" and "exchanges". Please cise examples of implementations which are deployed and which implement this standard. (In other words, they can interface with ERC-1155 contracts.) This is the consumer of information.

Other notes

"Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection."

This is also mentioned in the referenced page https://blog.enjincoin.io/erc-1155-the-crypto-item-standard-ac9cf1c5a226

  • It is not required that each token type or collection use separate contracts when implementing ERC-721. Although, often, this is how people have been implementing it. This is a minor note and does not warrant a change in the EIP draft.

Also I just wanted to point out that on that page it is referenced as "The Crypto Item Standard" which is inconsistent with the wording here "Multi Token Standard".

Other PRs

These are very minor PRs I just sent over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.