Pen Settings

HTML

CSS

CSS Base

Vendor Prefixing

Add External Stylesheets/Pens

Any URL's added here will be added as <link>s in order, and before the CSS in the editor. If you link to another Pen, it will include the CSS from that Pen. If the preprocessor matches, it will attempt to combine them before processing.

+ add another resource

JavaScript

Babel includes JSX processing.

Add External Scripts/Pens

Any URL's added here will be added as <script>s in order, and run before the JavaScript in the editor. You can use the URL of any other Pen and it will include the JavaScript from that Pen.

+ add another resource

Packages

Add Packages

Search for and use JavaScript packages from npm here. By selecting a package, an import statement will be added to the top of the JavaScript editor for this package.

Behavior

Save Automatically?

If active, Pens will autosave every 30 seconds after being saved once.

Auto-Updating Preview

If enabled, the preview panel updates automatically as you code. If disabled, use the "Run" button to update.

Format on Save

If enabled, your code will be formatted when you actively save your Pen. Note: your code becomes un-folded during formatting.

Editor Settings

Code Indentation

Want to change your Syntax Highlighting theme, Fonts and more?

Visit your global Editor Settings.

HTML

              
                <nav id="navbar">
  <header>ethEIP: ERC-Token Standards</header>
  <ul>
    <li><a class="nav-link" href="#20">ERC-20</a></li>
    <li>
      <a class="nav-link" href="#777"
        >ERC-777</a
      >
    </li>
    <li>
      <a class="nav-link" href="#721">ERC-721</a>
    </li>
    <li><a class="nav-link" href="#1155">ERC-1155</a></li> 
        <li><a class="nav-link" href="#137">EIP-137</a></li>
    <li><a class="nav-link" href="#165">EIP-165</a></li>

        <li><a class="nav-link" href="#190">EIP-190</a></li>
        <li><a class="nav-link" href="#627">EIP-627</a></li>

  </ul>
</nav>
<main id="main-doc">
  <section class="main-section" id="20">
    <header>ERC Token Standards:</header>
    <article>     
      <blockquote>
      The most common standard for Ethereum tokens is currently the ERC-20 standard, but there are also ERC-777, ERC-721, and ERC-1155 standards. 
      </blockquote>
      
      <h2>ERC-20 Overview</h2>
      <p>The ERC-20 Token Standard is the standard interface for tokens.</p>
      <p>The following standard allows for the implementation of a standard API for tokens within smart contracts. This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.</p>
      
      <h2>ERC-20 Motivation</h2>
      <p>A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges.</p>
      
      <h2>ERC-20 Token Specification</h2>
      <h3>Methods</h3>
      <h4>name</h4>
      <dd>Returns the name of the token</dd>
      <code>function name() public view returns (string)</code>
      
      <h4>symbol</h4>
      <dd>Returns the symbol of the token</dd>
      <code>function symbol() public view returns (string)</code>
      
      <h4>decimal</h4>
      <dd>Returns the number of decimals the token uses</dd>
      <code>function decimals() public view returns (uint8)</code>
      
      <h4>totalSupply</h4>
      <dd>Returns the total token supply</dd>
      <code>function totalSupply() public view returns (uint256)</code>
      
      <h4>balanceOf</h4>
      <dd>Returns the account balance of another account with address _owner</dd>
      <code>function balanceOf(address _owner) public view returns (uint256 balance)</code>
      
      <h4>transfer</h4>
      <dd>Transfers _value amount of tokens to address _to, and MUST fire the Transfer event. The function SHOULD throw if the message caller’s account balance does not have enough tokens to spend.</dd>
      <code>function transfer(address _to, uint256 _value) public returns (bool success)
</code>
      
      <h4>transferFrom</h4>
      <dd>Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event. The transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.</dd>
      <code>function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
</code>
      
      
      
      
      <h4>approve</h4>
      <dd>Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value. NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before</dd>
      <code>function approve(address _spender, uint256 _value) public returns (bool success)
</code>
      
      
      <h4>allowance</h4>
      <dd>Returns the amount which _spender is still allowed to withdraw from _owner</dd>
      <code>function allowance(address _owner, address _spender) public view returns (uint256 remaining)
</code>
      
      <blockquote><code>/*
    NOTE:
    The following variables are OPTIONAL vanities. One does not have to include them.
    They allow one to customise the token contract & in no way influences the core functionality.
    Some wallets/interfaces might not even bother to look at this information.
    */
    string public name;                   //fancy name: eg Gee Bux
    uint8 public decimals;                //How many decimals to show.
    string public symbol;                 //An identifier: eg GBX</code></blockquote>
      
      
      <h3>Events</h3>
      
      <h4>Transfer</h4>
      <dd>MUST trigger when tokens are transferred, including zero value transfers.
A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.</dd>
      <code>event Transfer(address indexed _from, address indexed _to, uint256 _value)
</code>
      
      <h4>Approval</h4>
      <dd>MUST trigger on any successful call to approve(address _spender, uint256 _value)</dd>
      <code>event Approval(address indexed _owner, address indexed _spender, uint256 _value)
</code>
      
      
      
      <dt>Notes: </dt>
      <dd><ul>
        <li>The following specifications use syntax from Solidity 0.4.17 (or above)</li>
        <li>Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!</li>
      </ul></dd>
      

      <p> <a href="http://https://github.com/ConsenSys/Tokens/blob/fdf687c69d998266a95f15216b1955a4965a0a6d/contracts/eip20/EIP20.sol">ConsenSys Implementation</a></p>
      <p><a href="http://https://github.com/OpenZeppelin/openzeppelin-contracts/blob/9b3710465583284b8c4c5d2245749246bb2e0094/contracts/token/ERC20/ERC20.sol">OpenZepplin Implementation</a></p>
      
     
    </article>
  </section>
  <section class="main-section" id="777">
    <h2>ERC-777</h2>
    <article>
      <p>This standard defines a new way to interact with a token contract while remaining backward compatible with ERC20.</p>
      <p>It defines advanced features to interact with tokens. Namely, operators to send tokens on behalf of another address—contract or regular account—and send/receive hooks to offer token holders more control over their tokens.</p>
     <p>It takes advantage of ERC1820 to find out whether and where to notify contracts and regular addresses when they receive tokens as well as to allow compatibility with already-deployed contracts.</p>
      <h2>ERC-777 Motivation</h2>
      <p>The principal intent for this standard is to solve some of the shortcomings of ERC20 while maintaining backward compatibility with ERC20, and avoiding the problems and vulnerabilities of EIP223.</p>
      <p>More than just sending tokens, ERC777 defines the entire lifecycle of a token, starting with the minting process, followed by the sending process and terminating with the burn process.</p>
      <p>Having a lifecycle clearly defined is important for consistency and accuracy, especially when value is derived from scarcity. In contrast when looking at some ERC20 tokens, a discrepancy can be observed between the value returned by the ' totalSupply ' and the actual circulating supply, as the standard does not clearly define a process to create and destroy tokens.</p>
      
      <p>This standard tries to improve upon the widely used ERC20 token standard. The main advantages of this standard are:</p>
      <ul>
        <li>1. Uses the same philosophy as Ether in that tokens are sent with ' send(dest, value, data) '.</li>
        <li>2. Both contracts and regular addresses can control and reject which token they send by registering a ' tokensToSend ' hook. (Rejection is done by ' revert 'ing in the hook function.)

</li>
        <li>3. Both contracts and regular addresses can control and reject which token they receive by registering a ' tokensReceived ' hook. (Rejection is done by ' revert 'ing in the hook function.)</li>
        <li>4. The tokensReceived hook allows to send tokens to a contract and notify it in a single transaction, unlike ERC20 which requires a double call (' approve ' / ' transferFrom ') to achieve this.</li>
        <li>5. The holder can “authorize” and “revoke” operators which can send tokens on their behalf. These operators are intended to be verified contracts such as an exchange, a cheque processor or an automatic charging system.</li>
        <li>6. Every token transaction contains ' data'  and ' operatorData ' bytes fields to be used freely to pass data from the holder and the operator, respectively.</li>
        <li>7. It is backward compatible with wallets that do not contain the ' tokensReceived ' hook function by deploying a proxy contract implementing the ' tokensReceived hook'  for the wallet.</li>
      </ul>
      
      <h2>ERC-777 Token Specificaition</h2>
      <h3>View Functions</h3>
      <p>The ' view ' functions detailed below MUST be implemented.</p>
      <h4>' name ' function</h4>
      <dd>Get the name of the token, e.g., "MyToken".</dd>
      <code>function name() external view returns (string memory)
</code>
      <h4>' symbol ' function</h4>
      <dd>Get the symbol of the token, e.g., "MYT".

</dd>
      <code>function symbol() external view returns (string memory)
</code>
      
<h4>' totalSupply ' function</h4>
<dd>Get the total number of minted tokens.
</dd>
      <p>NOTE: The total supply MUST be equal to the sum of the balances of all addresses—as returned by the balanceOf function.</p>
      <p>NOTE: The total supply MUST be equal to the sum of all the minted tokens as defined in all the Minted events minus the sum of all the burned tokens as defined in all the Burned events.</p>
<code>function totalSupply() external view returns (uint256)
</code>      
    <h4>' balanceOf ' function</h4>
    <dd>Get the balance of the account with address holder.</dd>
    <code>function balanceOf(address holder) external view returns (uint256)
</code>
      <h4>' granularity ' function</h4>
      <dd>Get the smallest part of the token that’s not divisible.</dd>
      <code>function granularity() external view returns (uint256)</code>
      <p>In other words, the granularity is the smallest amount of tokens (in the internal denomination) which MAY be minted, sent or burned at any time. </p>
      <p>The following rules MUST be applied regarding the granularity:</p>
      <ul>
        <li>The granularity value MUST be set at creation time.</li>
        <li>The granularity value MUST NOT be changed, ever.</li>
        <li>The granularity value MUST be greater than or equal to 1.</li>
        <li>All balances MUST be a multiple of the granularity.</li>
        <li>Any amount of tokens (in the internal denomination) minted, sent or burned MUST be a multiple of the granularity value.</li>
        <li>Any operation that would result in a balance that’s not a multiple of the granularity value MUST be considered invalid, and the transaction MUST revert.</li>
      </ul>
      <p>NOTE: Most tokens SHOULD be fully partition-able. I.e., this function SHOULD return 1 unless there is a good reason for not allowing any fraction of the token.</p>
<p>The decimals of the token MUST always be 18. For a pure ERC777 token the ERC20 decimals function is OPTIONAL, and its existence SHALL NOT be relied upon when interacting with the token contract. (The decimal value of 18 is implied.) For an ERC20 compatible token, the decimals function is REQUIRED and MUST return 18. (In ERC20, the decimals function is OPTIONAL. If the function is not present, the decimals value is not clearly defined and may be assumed to be 0. Hence for compatibility reasons, decimals MUST be implemented for ERC20 compatible tokens.)
</p>      
 
      <h3>Operators</h3>
      
      <p>An ' operator ' is an address which is allowed to send and burn tokens on behalf of some holder.</p>
      
      <h4>Authorized Operator</h4>
      <p>When an address becomes an operator for a holder, an ' AuthorizedOperator ' event MUST be emitted. The AuthorizedOperator’s operator (topic 1) and holder (topic 2) MUST be the addresses of the ' operator '  and the ' holder ' respectively.</p>
      <h4>Revoked Operator</h4>
      <p>When a holder revokes an operator, a ' RevokedOperator ' event MUST be emitted. The RevokedOperator’s operator (topic 1) and holder (topic 2) MUST be the addresses of the ' operator ' and the ' holder ' respectively.</p>
      
      
      <h4>Default Operator</h4>
      <p>The token MAY define default operators. A default operator is an implicitly authorized operator for all holders. AuthorizedOperator events MUST NOT be emitted when defining the default operators. The rules below apply to default operators:</p>
      <ul>
        <li>The token contract MUST define default operators at creation time.

</li>
        <li>The default operators MUST be invariants. I.e., the token contract MUST NOT add or remove default operators ever.

</li>
        <li>AuthorizedOperator events MUST NOT be emitted when defining default operators.

</li>
        <li>A holder MUST be allowed to revoke a default operator (unless the holder is the default operator in question).

</li>
        <li>A holder MUST be allowed to re-authorize a previously revoked default operator.

</li>
        <li>When a default operator is explicitly authorized or revoked for a specific holder, an AuthorizedOperator or RevokedOperator event (respectively) MUST be emitted.

</li>
      </ul>
<p>The following rules apply to any operator:</p>
      <ul>
        <li>An address MUST always be an operator for itself. Hence an address MUST NOT ever be revoked as its own operator.</li>
        <li>If an address is an operator for a holder, isOperatorFor MUST return true.

</li>
        <li>If an address is not an operator for a holder, isOperatorFor MUST return false.

</li>
        <li>The token contract MUST emit an AuthorizedOperator event with the correct values when a holder authorizes an address as its operator as defined in the AuthorizedOperator Event.

</li>
        <li>The token contract MUST emit a RevokedOperator event with the correct values when a holder revokes an address as its operator as defined in the RevokedOperator Event.

</li>
      </ul>
   
  <p>NOTE: A holder MAY have multiple operators at the same time.</p>
      <p>NOTE: A holder MAY authorize an already authorized operator. An AuthorizedOperator MUST be emitted each time.</p>
      <p>NOTE: A holder MAY revoke an already revoked operator. A RevokedOperator MUST be emitted each time.</p>
      <h4>' AuthorizedOperator ' event</h4>
      <dd>Indicates the authorization of operator as an operator for holder.

</dd>
      <code>event AuthorizedOperator(address indexed operator, address indexed holder)
</code>
      
       <h4>' RevokedOperator ' event

</h4>
      <dd>Indicates the revocation of operator as an operator for holder.

</dd>
      <code>event RevokedOperator(address indexed operator, address indexed holder)
</code>
      
      <p>The defaultOperators, authorizeOperator, revokeOperator and isOperatorFor functions described below MUST be implemented to manage operators. Token contracts MAY implement other functions to manage operators.</p>
      
      <h4>' defaultOperators ' function</h4>
      <dd>Get the list of default operators as defined by the token contract.

</dd>
      <code>function defaultOperators() external view returns (address[] memory)
</code>
      
       <h4>' authorizeOperator ' function

</h4>
      <dd>Set a third party operator address as an operator of msg.sender to send and burn tokens on its behalf.</dd>
      <code>function authorizeOperator(address operator) external
</code>
      
       <h4>' revokeOperator ' function</h4>
      <dd>Remove the right of the operator address to be an operator for msg.sender and to send and burn tokens on its behalf.

</dd>
      <code>function revokeOperator(address operator) external
</code>

      <h4>' isOperatorFor ' function</h4>
      <dd>Indicate whether the operator address is an operator of the holder address.</dd>
      <code>
function isOperatorFor(
    address operator,
    address holder
) external view returns (bool)</code>
      
      <h3>Sending Tokens</h3>
      When an operator sends an amount of tokens from a holder to a recipient with the associated data and operatorData, the token contract MUST apply the following rules:
      <ul>
        <li>Any authorized operator MAY send tokens to any recipient (except to 0x0).

</li>
        <li>The balance of the holder MUST be decreased by the amount.

</li>
        <li>The balance of the recipient MUST be increased by the amount.

</li>
        <li>The balance of the holder MUST be greater or equal to the amount—such that its resulting balance is greater or equal to zero (0) after the send.

</li>
        <li>The token contract MUST emit a Sent event with the correct values as defined in the Sent Event.

</li>
        <li>The operator MAY include information in the operatorData.

</li>
        <li>The token contract MUST call the tokensToSend hook of the holder if the holder registers an ERC777TokensSender implementation via ERC1820.

</li>
        <li>The token contract MUST call the tokensReceived hook of the recipient if the recipient registers an ERC777TokensRecipient implementation via ERC1820.

</li>
        <li>The data and operatorData MUST be immutable during the entire send process—hence the same data and operatorData MUST be used to call both hooks and emit the Sent event.

</li>
      </ul>
 <p>The token contract MAY send tokens from many holders, to many recipients, or both. In this case:

</p>
      <ul>
        <li>The previous send rules MUST apply to all the holders and all the recipients.
</li>
        <li>The sum of all the balances incremented MUST be equal to the total sent amount.
</li>
        <li>The sum of all the balances decremented MUST be equal to the total sent amount.
</li>
        <li>A Sent event MUST be emitted for every holder and recipient pair with the corresponding amount for each pair.
</li>
        <li>The sum of all the amounts from the Sent event MUST be equal to the total sent amount.
</li>
      </ul>
      
      <p>The token contract MUST revert when sending in any of the following cases:</p>
      <ul>
        <li>The operator address is not an authorized operator for the holder.</li>
        <li>The resulting holder balance or recipient balance after the send is not a multiple of the granularity defined by the token contract.</li>
        <li>The recipient is a contract, and it does not implement the ' ERC777TokensRecipient ' interface via ERC1820.</li>
        <li>The address of the holder or the recipient is 0x0.</li>
        <li>Any of the resulting balances becomes negative, i.e. becomes less than zero (0).</li>
        <li>The ' tokensToSend ' hook of the holder reverts.</li>
        <li>The tokensReceived hook of the recipient reverts.</li>
      </ul>
    <p>The token contract MAY send tokens from many holders, to many recipients, or both. In this case:</p>
      
      <ul>
        <li>The previous send rules MUST apply to all the holders and all the recipients.</li>
        <li>The sum of all the balances incremented MUST be equal to the total sent amount.</li>
        <li>The sum of all the balances decremented MUST be equal to the total sent amount.</li>
        <li>A Sent event MUST be emitted for every holder and recipient pair with the corresponding amount for each pair.
</li>
        <li>The sum of all the amounts from the Sent event MUST be equal to the total sent amount.</li>
        <li>Mechanisms such as applying a fee on a send is considered as a send to multiple recipients: the intended recipient and the fee recipien</li>
        <li>Movements of tokens MAY be chained. For example, if a contract upon receiving tokens sends them further to another address. In this case, the previous send rules apply to each send, in order.</li>
        <li>Sending an amount of zero (0) tokens is valid and MUST be treated as a regular send.</li>
        
      </ul>
<h4>' Sent ' event</h4>
<dd>Indicate a send of amount of tokens from the from address to the to address by the operator address. NOTE: This event MUST NOT be emitted outside of a send or an ERC20 transfer process.

</dd>
<code>event Sent(
    address indexed operator,
    address indexed from,
    address indexed to,
    uint256 amount,
    bytes data,
    bytes operatorData
)</code>
<p>The send and operatorSend functions described below MUST be implemented to send tokens. Token contracts MAY implement other functions to send tokens.</p>
      
<h4>' send ' function</h4>
<dd>Send the amount of tokens from the address msg.sender to the address to.</dd>
<code>function send(address to, uint256 amount, bytes calldata data) external
</code>

<h4>' operatorSend ' function</h4>
<dd>Send the amount of tokens on behalf of the address from to the address to. NOTE: from and msg.sender MAY be the same address. I.e., an address MAY call operatorSend for itself. This call MUST be equivalent to send with the addition that the operator MAY specify an explicit value for operatorData (which cannot be done with the send function).</dd>
<code>function operatorSend(
    address from,
    address to,
    uint256 amount,
    bytes calldata data,
    bytes calldata operatorData
) external</code>
      
      <h3>Minting Token</h3>
      <p>Minting tokens is the act of producing new tokens. ERC777 intentionally does not define specific functions to mint tokens. This intent comes from the wish not to limit the use of the ERC777 standard as the minting process is generally specific for every token.</p>
      
      <p>Nonetheless, the rules below MUST be respected when minting for a recipient:</p>
      <ul>
        <li>Tokens MAY be minted for any recipient address (except 0x0).</li>
        <li>The total supply MUST be increased by the amount of tokens minted.</li>
        <li>The balance of 0x0 MUST NOT be decreased.</li>
        <li>The balance of the recipient MUST be increased by the amount of tokens minted.</li>
        <li>The token contract MUST emit a Minted event with the correct values as defined in the Minted Event.</li>
        <li>The token contract MUST call the tokensReceived hook of the recipient if the recipient registers an ERC777TokensRecipient implementation via ERC1820.</li>
        <li>The data and operatorData MUST be immutable during the entire mint process—hence the same data and operatorData MUST be used to call the tokensReceived hook and emit the Minted event.</li>
      </ul>
      
      <p>The token contract MUST revert when minting in any of the following cases:</p>
      <ul>
        <li>The resulting recipient balance after the mint is not a multiple of the granularity defined by the token contract.</li>
        <li>The recipient is a contract, and it does not implement the ERC777TokensRecipient interface via ERC1820.</li>
        <li>The address of the recipient is 0x0.</li>
        <li>The tokensReceived hook of the recipient reverts.
</li>
      </ul>
      
<h4>Minted event</h4>
<dd>event Minted(
    address indexed operator,
    address indexed to,
    uint256 amount,
    bytes data,
    bytes operatorData
)</dd>
<code>Indicate the minting of amount of tokens to the to address by the operator address.</code>      
 
      <h4>Burning Tokens</h4>
      <p>Burning tokens is the act of destroying existing tokens. ERC777 explicitly defines two functions to burn tokens (burn and operatorBurn). These functions facilitate the integration of the burning process in wallets and dapps. However, the token contract MAY prevent some or all holders from burning tokens for any reason. The token contract MAY also define other functions to burn tokens.</p>
      <p>The rules below MUST be respected when burning the tokens of a holder:</p>
      <ul>
        <li>Tokens MAY be burned from any holder address (except 0x0).</li>
        <li>The total supply MUST be decreased by the amount of tokens burned.</li>
        <li>The balance of 0x0 MUST NOT be increased.</li>
        <li>The balance of the holder MUST be decreased by amount of tokens burned.</li>
        <li>The token contract MUST emit a Burned event with the correct values as defined in the Burned Event.</li>
        <li>The token contract MUST call the tokensToSend hook of the holder if the holder registers an ERC777TokensSender implementation via ERC1820.</li>
        <li>The operatorData MUST be immutable during the entire burn process—hence the same operatorData MUST be used to call the tokensToSend hook and emit the Burned event.</li>
      </ul>
      <p>The token contract MUST revert when burning in any of the following cases:</p>
      <ul>
        <li>The operator address is not an authorized operator for the holder.

</li>
        <li>The resulting holder balance after the burn is not a multiple of the granularity defined by the token contract.
</li>
        <li>The balance of holder is inferior to the amount of tokens to burn (i.e., resulting in a negative balance for the holder).</li>
        <li>The address of the holder is 0x0.</li>
        <li>The tokensToSend hook of the holder reverts.</li>
      </ul>
      <p>ERC20 compatibility requirement:</p>
      <dd>While a Sent event MUST NOT be emitted when burning; if the token contract is ERC20 enabled, a Transfer event with the to parameter set to 0x0 SHOULD be emitted. The ERC20 standard does not define the concept of burning tokens, but this is a commonly accepted practice.</dd>
      <p>The token contract MAY burn tokens for multiple holders at once. In this case:</p>
      <ul>
        <li>The previous burn rules MUST apply to each holders.
</li>
        <li>The sum of all the balances decremented MUST be equal to the total burned amount.</li>
        <li>A Burned event MUST be emitted for every holder with the corresponding amount for each holder.
</li>
        <li>The sum of all the amounts from the Burned event MUST be equal to the total burned amount.</li>
      </ul>
      
      <h4>Burned event</h4>
      <dd>event Burned(
    ddress indexed operator,
    address indexed from,
    uint256 amount,
    bytes data,
    bytes operatorData
);</dd>
      <code>Indicate the burning of amount of tokens from the from address by the operator address.</code>
  
      <p>The burn and operatorBurn functions described below MUST be implemented to burn tokens. Token contracts MAY implement other functions to burn tokens.</p>
      
      <h4>burn function</h4>
      <dd>Burn the amount of tokens from the address msg.sender.</dd>
      <code>function burn(uint256 amount, bytes calldata data) external</code>
      
      <h4>operatorBurn function</h4>
      <dd>Burn the amount of tokens on behalf of the address from.</dd>
      <code>function operatorBurn(
    address from,
    uint256 amount,
    bytes calldata data,
    bytes calldata operatorData
) external</code>
      
      <h3>ERC777TokensSender And The tokensToSend Hook</h3>
      <p>The tokensToSend hook notifies of any request to decrement the balance (send and burn) for a given holder. Any address (regular or contract) wishing to be notified of token debits from their address MAY register the address of a contract implementing the ERC777TokensSender interface described below via ERC1820.</p>
      
      <p>This is done by calling the setInterfaceImplementer function on the ERC1820 registry with the holder address as the address, the keccak256 hash of ERC777TokensSender (0x29ddb589b1fb5fc7cf394961c1adf5f8c6454761adf795e67fe149f658abe895) as the interface hash, and the address of the contract implementing the ERC777TokensSender as the implementer.</p>
      
      <code>interface ERC777TokensSender {
    function tokensToSend(
        address operator,
        address from,
        address to,
        uint256 amount,
        bytes calldata userData,
        bytes calldata operatorData
    ) external;
}</code>
      
      <p>NOTE: A regular address MAY register a different address—the address of a contract—implementing the interface on its behalf. A contract MAY register either its address or the address of another contract but said address MUST implement the interface on its behalf.</p>
      
      <h4>tokensToSend</h4>
      <dd>Notify a request to send or burn (if to is 0x0) an amount tokens from the from address to the to address by the operator address.</dd>
      <code>function tokensToSend(
    address operator,
    address from,
    address to,
    uint256 amount,
    bytes calldata userData,
    bytes calldata operatorData
) external
</code>
      <p>NOTE: This function MUST NOT be called outside of a burn, send or ERC20 transfer process.</p>
      
      <p>The following rules apply when calling the tokensToSend hook:</p>
      <ul>
        <li>The tokensToSend hook MUST be called for every send and burn processes.</li>
        <li>The tokensToSend hook MUST be called before the state is updated—i.e. before the balance is decremented.</li>
        <li>operator MUST be the address which triggered the send or burn process.</li>
        <li>from MUST be the address of the holder whose tokens are sent or burned.</li>
        <li>to MUST be the address of the recipient which receives the tokens for a send.</li>
        <li>to MUST be 0x0 for a burn.</li>
        <li>amount MUST be the number of tokens the holder sent or burned.</li>
        <li>data MUST contain the extra information (if any) provided to the send or the burn process.</li>
        <li>operatorData MUST contain the extra information provided by the address which triggered the decrease of the balance (if any).</li>
        <li>The holder MAY block a send or burn process by reverting. (I.e., reject the withdrawal of tokens from its account.)</li>
        <li>Multiple holders MAY use the same implementation of ERC777TokensSender.</li>
        <li>An address can register at most one implementation at any given time for all ERC777 tokens. Hence the ERC777TokensSender MUST expect to be called by different token contracts. The msg.sender of the tokensToSend call is expected to be the address of the token contract.</li>
      </ul>
      <p>ERC20 compatibility requirement:</p> 
      <p>This hook takes precedence over ERC20 and MUST be called (if registered) when calling ERC20’s transfer and transferFrom event. When called from a transfer, operator MUST be the same value as the from. When called from a transferFrom, operator MUST be the address which issued the transferFrom call.</p>
      <h4>Note On Gas Consumption</h4>
      <p>Dapps and wallets SHOULD first estimate the gas required when sending, minting, or burning tokens—using eth_estimateGas—to avoid running out of gas during the transaction.</p>
      
      
    </article>
  </section>
  <section class="main-section" id="721">
    <h2>ERC-721</h2>
    <article>
          <p>A standard interface for non-fungible tokens, also known as deeds.</p>
      <p>The following standard allows for the implementation of a standard API for NFTs within smart contracts. This standard provides basic functionality to track and transfer NFTs.</p>
      <p>We considered use cases of NFTs being owned and transacted by individuals as well as consignment to third party brokers/wallets/auctioneers (“operators”). NFTs can represent ownership over digital or physical assets. We considered a diverse universe of assets, and we know you will dream up many more:</p>
      <ul>
        <li>Physical property — houses, unique artwork</li>
        <li>Virtual collectables — unique pictures of kittens, collectable cards</li>
        <li>“Negative value” assets — loans, burdens and other responsibilities</li>
      </ul>
      <p>In general, all houses are distinct and no two kittens are alike. NFTs are distinguishable and you must track the ownership of each one separately.</p>
      <h2>Motivation</h2>
      <p>A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple ERC-721 smart contracts as well as contracts that track an arbitrarily large number of NFTs. Additional applications are discussed below.</p>
      <p>This standard is inspired by the ERC-20 token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).</p>
      <p>There are many proposed uses of Ethereum smart contracts that depend on tracking distinguishable assets. Examples of existing or planned NFTs are LAND in Decentraland, the eponymous punks in CryptoPunks, and in-game items using systems like DMarket or EnjinCoin. Future uses include tracking real-world assets, like real-estate (as envisioned by companies like Ubitquity or Propy. It is critical in each of these cases that these items are not “lumped together” as numbers in a ledger, but instead each asset must have its ownership individually and atomically tracked. Regardless of the nature of these assets, the ecosystem will be stronger if we have a standardized interface that allows for cross-functional asset management and sales platforms.</p>
      
      <h3>Specification</h3>
      <h4>"NFT" Word Choice</h4>
      <p>“NFT” was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that “deed” is very descriptive for certain applications of this standard (notably, physical property). Alternatives considered: distinguishable asset, title, token, asset, equity, ticket.</p>
      <h4>NFT Identifiers</h4>
      <p>Every NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”. Also note that a NFTs MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface.</p>
      <p>The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.</p>
      <h4>Transfer Mechanism</h4>
      <p>ERC-721 standardizes a safe transfer function safeTransferFrom (overloaded with and without a bytes parameter) and an unsafe function transferFrom. Transfers may be initiated by:</p>
      <ul>
        <li>The owner of an NFT</li>
        <li>The approved address of an NFT</li>
        <li>An authorized operator of the current owner of an NFT</li>
      </ul>
      <p>Additionally, an authorized operator may set the approved address for an NFT. This provides a powerful set of tools for wallet, broker and auction applications to quickly use a large number of NFTs.</p>
      <p>The transfer and accept functions’ documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:</p>
      <ul>
        <li>Disallow transfers if the contract is paused — prior art, CryptoKitties deployed contract, line 611</li>
        <li>Blacklist certain address from receiving NFTs — prior art, CryptoKitties deployed contract, lines 565, 566</li>
        <li>Disallow unsafe transfers — transferFrom throws unless _to equals msg.sender or countOf(_to) is non-zero or was non-zero previously (because such cases are safe)</li>
        <li>Charge a fee to both parties of a transaction — require payment when calling approve with a non-zero _approved if it was previously the zero address, refund payment if calling approve with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter _to to equal msg.sender, require transfer parameter _to to be the approved address for the NFT
</li>
        <li>Read only NFT registry — always throw from unsafeTransfer, transferFrom, approve and setApprovalForAll</li>
      </ul>

      <p>Failed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin’s implementation of SafeERC20.sol. ERC-20 defined an allowance feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue #438. In ERC-721, there is no allowance because every NFT is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20’s original design without problems that have been later discovered.</p>
      <p>Creating of NFTs (“minting”) and destruction NFTs (“burning”) is not included in the specification. Your contract may implement these by other means. Please see the event documentation for your responsibilities when creating or destroying NFTs.</p>
      <p>Creating of NFTs (“minting”) and destruction NFTs (“burning”) is not included in the specification. Your contract may implement these by other means. Please see the event documentation for your responsibilities when creating or destroying NFTs.</p>
      <p>We questioned if the operator parameter on onERC721Received was necessary. In all cases we could imagine, if the operator was important then that operator could transfer the token to themself and then send it – then they would be the from address. This seems contrived because we consider the operator to be a temporary owner of the token (and transferring to themself is redundant). When the operator sends the token, it is the operator acting on their own accord, NOT the operator acting on behalf of the token holder. This is why the operator and the previous token owner are both significant to the token recipient.</p>
      <p>Alternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.</p>
      <h4>ERC-165 Interface</h4>
      <p>We chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-721 smart contract supports.</p>
<p>A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-721 implementation to implement ERC721Enumerable, ERC721Metadata, or other interfaces by delegating to a separate contract.</p>
      <h4>Gas and Complexity</h4>
      <p>This specification contemplates implementations that manage a few and arbitrarily large numbers of NFTs. If your application is able to grow then avoid using for/while loops in your code (see CryptoKitties bounty issue #4). These indicate your contract may be unable to scale and gas costs will rise over time without bound.</p>
      <p>We have deployed a contract, XXXXERC721, to Testnet which instantiates and tracks 340282366920938463463374607431768211456 different deeds (2^128). That’s enough to assign every IPV6 address to an Ethereum account owner, or to track ownership of nanobots a few micron in size and in aggregate totalling half the size of Earth. You can query it from the blockchain. And every function takes less gas than querying the ENS.</p>
      <p>This illustration makes clear: the ERC-721 standard scales.</p>
      <h4>Privacy</h4>
      <p>Wallets/brokers/auctioneers identified in the motivation section have a strong need to identify which NFTs an owner owns.</p>
      <p>It may be interesting to consider a use case where NFTs are not enumerable, such as a private registry of property ownership, or a partially-private registry. However, privacy cannot be attained because an attacker can simply (!) call ownerOf for every possible tokenId.</p>
      <h4>Metadata Choices</h4>
      <p>We have required name and symbol functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions.</p>
      <p>We remind implementation authors that the empty string is a valid response to name and symbol if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as your contract. How a client may determine which ERC-721 smart contracts are well-known (canonical) is outside the scope of this standard.</p>
      <p>A mechanism is provided to associate NFTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each NFT. The image size recommendation is taken from Instagram, they probably know much about image usability. The URI MAY be mutable (i.e. it changes from time to time). We considered an NFT representing ownership of a house, in this case metadata about the house (image, occupants, etc.) can naturally change.</p>
      <p>Metadata is returned as a string value. Currently this is only usable as calling from web3, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information.</p>
      <p>Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough.)</p>
      <h3>Backwards Compatibility</h3>
      <p>We have adopted balanceOf, totalSupply, name and symbol semantics from the ERC-20 specification. An implementation may also include a function decimals that returns uint8(0) if its goal is to be more compatible with ERC-20 while supporting this standard. However, we find it contrived to require all ERC-721 implementations to support the decimals function.</p>
      <p>Example NFT implementations as of February 2018:</p>
      <ul>
        <li>CryptoKitties – Compatible with an earlier version of this standard.</li>
        <li>CryptoPunks – Partially ERC-20 compatible, but not easily generalizable because it includes auction functionality directly in the contract and uses function names that explicitly refer to the assets as “punks”.</li>
        <li>Auctionhouse Asset Interface – The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His “Asset” contract is very simple, but is missing ERC-20 compatibility, approve() functionality, and metadata. This effort is referenced in the discussion for EIP-173.</li>
      </ul>
      
      <p>Note: “Limited edition, collectible tokens” like Curio Cards and Rare Pepe are not distinguishable assets. They’re actually a collection of individual fungible tokens, each of which is tracked by its own smart contract with its own total supply (which may be 1 in extreme cases).</p>
      
      <p>The onERC721Received function specifically works around old deployed contracts which may inadvertently return 1 (true) in certain circumstances even if they don’t implement a function (see Solidity DelegateCallReturnValue bug). By returning and checking for a magic value, we are able to distinguish actual affirmative responses versus these vacuous trues.</p>
      
      <h3>Implementations</h3>
      <p>0xcert ERC721 – a reference implementation</p>
      <ul>
        <li>MIT licensed, so you can freely use it for your projects</li>
        <li>Includes test cases</li>
        <li>Active bug bounty, you will be paid if you find errors</li>
      </ul>
      
      <p>Su Squares – an advertising platform where you can rent space and place images</p>
      <ul>
        <li>Complete the Su Squares Bug Bounty Program to seek problems with this standard or its implementation</li>
        <li>Implements the complete standard and all optional interfaces</li>
      </ul>
      
      <p>ERC721ExampleDeed – an example implementation</p>
      <ul>
        <li>Implements using the OpenZeppelin project format</li>
      </ul>

      <p>XXXXERC721, by William Entriken – a scalable example implementation</p>
      <ul>
        <li>Deployed on testnet with 1 billion assets and supporting all lookups with the metadata extension. This demonstrates that scaling is NOT a problem.</li>
      </ul>
      <ul>
        <li>CryptoKitties. https://www.cryptokitties.co</li>
        <li>0xcert ERC-721 Token. https://github.com/0xcert/ethereum-erc721</li>
        <li>Su Squares. https://tenthousandsu.com</li>
        <li>Decentraland. https://decentraland.org</li>
        <li>CryptoPunks. https://www.larvalabs.com/cryptopunks
</li>
        <li>DMarket. https://www.dmarket.io</li>
        <li>Enjin Coin. https://enjincoin.io</li>
        <li>Ubitquity. https://www.ubitquity.io</li>
        <li>Propy. https://tokensale.propy.com</li>
        <li>CryptoKitties Deployed Contract. https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code</li>
        <li>Su Squares Bug Bounty Program. https://github.com/fulldecent/su-squares-bounty</li>
        <li>XXXXERC721. https://github.com/fulldecent/erc721-example</li>
        <li>ERC721ExampleDeed. https://github.com/nastassiasachs/ERC721ExampleDeed</li>
        <li>Curio Cards. https://mycuriocards.com</li>
        <li>Rare Pepe. https://rarepepewallet.com</li>
        <li>Auctionhouse Asset Interface. https://github.com/dob/auctionhouse/blob/master/contracts/Asset.sol</li>
        <li>OpenZeppelin SafeERC20.sol Implementation. https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/ERC20/SafeERC20.sol</li>
      </ul>
    <p>Every ERC-721 compliant contract must implement the ERC721 and ERC165 interfaces (subject to “caveats” below):</p>
      <code>pragma solidity ^0.4.20;

/// @title ERC-721 Non-Fungible Token Standard
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x80ac58cd.
interface ERC721 /* is ERC165 */ {
    /// @dev This emits when ownership of any NFT changes by any mechanism.
    ///  This event emits when NFTs are created (`from` == 0) and destroyed
    ///  (`to` == 0). Exception: during contract creation, any number of NFTs
    ///  may be created and assigned without emitting Transfer. At the time of
    ///  any transfer, the approved address for that NFT (if any) is reset to none.
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

    /// @dev This emits when the approved address for an NFT 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 NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

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

    /// @notice Count all NFTs assigned to an owner
    /// @dev NFTs assigned to the zero address are considered invalid, and this
    ///  function throws for queries about the zero address.
    /// @param _owner An address for whom to query the balance
    /// @return The number of NFTs owned by `_owner`, possibly zero
    function balanceOf(address _owner) external view returns (uint256);

    /// @notice Find the owner of an NFT
    /// @dev NFTs assigned to zero address are considered invalid, and queries
    ///  about them do throw.
    /// @param _tokenId The identifier for an NFT
    /// @return The address of the owner of the NFT
    function ownerOf(uint256 _tokenId) external view returns (address);

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

    /// @notice Transfers the ownership of an NFT 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 NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
    ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS 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 NFT. Throws if `_from` is
    ///  not the current owner. Throws if `_to` is the zero address. Throws if
    ///  `_tokenId` is not a valid NFT.
    /// @param _from The current owner of the NFT
    /// @param _to The new owner
    /// @param _tokenId The NFT to transfer
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) 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 approved address for a single NFT
    /// @dev Throws if `_tokenId` is not a valid NFT.
    /// @param _tokenId The NFT to find the approved address for
    /// @return The approved address for this NFT, or the zero address if there is none
    function getApproved(uint256 _tokenId) external view returns (address);

    /// @notice Query if an address is an authorized operator for another address
    /// @param _owner The address that owns the NFTs
    /// @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);
}

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);
}
</code>
      <p>A wallet/broker/auction application MUST implement the wallet interface if it will accept safe transfers.</p>
      <code>/// @dev Note: the ERC-165 identifier for this interface is 0x150b7a02.
interface ERC721TokenReceiver {
    /// @notice Handle the receipt of an NFT
    /// @dev The ERC721 smart contract calls this function on the recipient
    ///  after a `transfer`. 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 `safeTransferFrom` function
    /// @param _from The address which previously owned the token
    /// @param _tokenId The NFT identifier which is being transferred
    /// @param _data Additional data with no specified format
    /// @return `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`
    ///  unless throwing
    function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
}
</code>
      <p>The metadata extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent.</p>
      <code>/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x5b5e139f.
interface ERC721Metadata /* is ERC721 */ {
    /// @notice A descriptive name for a collection of NFTs in this contract
    function name() external view returns (string _name);

    /// @notice An abbreviated name for NFTs in this contract
    function symbol() external view returns (string _symbol);

    /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.
    /// @dev Throws if `_tokenId` is not a valid NFT. 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 _tokenId) external view returns (string);
}</code>
      <p>This is the “ERC721 Metadata JSON Schema” referenced above.</p>
      <code>{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
        }
    }
}</code>
      <p>The enumeration extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your contract to publish its full list of NFTs and make them discoverable.</p>
      <code>/// @title ERC-721 Non-Fungible Token Standard, optional enumeration extension
/// @dev See https://eips.ethereum.org/EIPS/eip-721
///  Note: the ERC-165 identifier for this interface is 0x780e9d63.
interface ERC721Enumerable /* is ERC721 */ {
    /// @notice Count NFTs tracked by this contract
    /// @return A count of valid NFTs tracked by this contract, where each one of
    ///  them has an assigned and queryable owner not equal to the zero address
    function totalSupply() external view returns (uint256);

    /// @notice Enumerate valid NFTs
    /// @dev Throws if `_index` >= `totalSupply()`.
    /// @param _index A counter less than `totalSupply()`
    /// @return The token identifier for the `_index`th NFT,
    ///  (sort order not specified)
    function tokenByIndex(uint256 _index) external view returns (uint256);

    /// @notice Enumerate NFTs assigned to an owner
    /// @dev Throws if `_index` >= `balanceOf(_owner)` or if
    ///  `_owner` is the zero address, representing invalid NFTs.
    /// @param _owner An address where we are interested in NFTs owned by them
    /// @param _index A counter less than `balanceOf(_owner)`
    /// @return The token identifier for the `_index`th NFT assigned to `_owner`,
    ///   (sort order not specified)
    function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);
}</code>
    </article>
  </section>
  <section class="main-section" id="1155">
    <h2>ERC-1155</h2>
    <p>
   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 (e.g. semi-fungible tokens).</p>
  <p>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.</p>
    <p>The _id argument contained in each function’s argument set indicates a specific token or token type in a transaction.</p>
      <h3>Motivation</h3>
<p>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.</p>
    <p>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.</p>
    <h3>Specification</h3>
    <blockquote>Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the ERC1155 interface. Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 supportsInterface function and MUST return the constant value true if 0xd9b67a26 is passed through the interfaceID argument.</blockquote>
    
    <code>
      pragma solidity ^0.5.9;

/**
    @title ERC-1155 Multi Token Standard
    @dev See https://eips.ethereum.org/EIPS/eip-1155
    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 (see "Safe Transfer Rules" section of the standard).
        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
        The `_from` argument MUST be the address of the holder whose balance is decreased.
        The `_to` argument MUST be the address of the recipient whose balance is increased.
        The `_id` argument MUST be the token type being transferred.
        The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.
        When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).
        When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address).        
    */
    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 (see "Safe Transfer Rules" section of the standard).      
        The `_operator` argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
        The `_from` argument MUST be the address of the holder whose balance is decreased.
        The `_to` argument MUST be the address of the recipient whose balance is increased.
        The `_ids` argument MUST be the list of tokens being transferred.
        The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.
        When minting/creating tokens, the `_from` argument MUST be set to `0x0` (i.e. zero address).
        When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address).                
    */
    event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);

    /**
        @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled).        
    */
    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 to a JSON file that conforms to the "ERC-1155 Metadata URI 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 (with safety call).
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard).
        MUST revert if `_to` is the zero address.
        MUST revert if balance of holder for token `_id` is lower than the `_value` sent.
        MUST revert on any other error.
        MUST emit the `TransferSingle` event to reflect the balance change (see "Safe Transfer Rules" section of the standard).
        After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard).        
        @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, MUST be sent unaltered in call to `onERC1155Received` on `_to`
    */
    function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;

    /**
        @notice Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call).
        @dev Caller must be approved to manage the tokens being transferred out of the `_from` account (see "Approval" section of the standard).
        MUST revert if `_to` is the zero address.
        MUST revert if length of `_ids` is not the same as length of `_values`.
        MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient.
        MUST revert on any other error.        
        MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "Safe Transfer Rules" section of the standard).
        Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc).
        After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard).                      
        @param _from    Source address
        @param _to      Target address
        @param _ids     IDs of each token type (order and length must match _values array)
        @param _values  Transfer amounts per token type (order and length must match _ids array)
        @param _data    Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_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);
}
    </code>
    
    <h4>ERC-1155 Token Receiver</h4>
    <p>Smart contracts MUST implement all of the functions in the ERC1155TokenReceiver interface to accept transfers. See “Safe Transfer Rules” for further detail.</p>
    <p>Smart contracts MUST implement the ERC-165 supportsInterface function and signify support for the ERC1155TokenReceiver interface to accept transfers. See “ERC1155TokenReceiver ERC-165 rules” for further detail.</p>
    <code>
      pragma solidity ^0.5.9;

/**
    Note: The ERC-165 identifier for this interface is 0x4e2312e0.
*/
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 MUST return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` (i.e. 0xf23a6e61) if it accepts the transfer.
        This function MUST revert if it rejects the transfer.
        Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller.
        @param _operator  The address which initiated the transfer (i.e. msg.sender)
        @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 MUST return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` (i.e. 0xbc197c81) if it accepts the transfer(s).
        This function MUST revert if it rejects the transfer(s).
        Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller.
        @param _operator  The address which initiated the batch transfer (i.e. msg.sender)
        @param _from      The address which previously owned the token
        @param _ids       An array containing ids of each token being transferred (order and length must match _values array)
        @param _values    An array containing amounts of each token being transferred (order and length must match _ids array)
        @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);       
}
    </code>
 <h4>Safe Transfer Rules</h4>
    <p>To be more explicit about how the standard safeTransferFrom and safeBatchTransferFrom functions MUST operate with respect to the ERC1155TokenReceiver hook functions, a list of scenarios and rules follows.</p>
    <dt>Scenario #1 : The recipient is not a contract.</dt>
    <ul>
      <li>onERC1155Received and onERC1155BatchReceived MUST NOT be called on an EOA (Externally Owned Account).</li>
    </ul>
    
    <dt>Scenario #2 : The transaction is not a mint/transfer of a token.</dt>
      <ul>
        <li>onERC1155Received and onERC1155BatchReceived MUST NOT be called outside of a mint or transfer process.</li>
      </ul>
    
<dt>Scenario #3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s).</dt>
    <ul>
      <li>The transfer MUST be reverted with the one caveat: 
        <p>If the token(s) being sent are part of a hybrid implementation of another standard, that particular standard’s rules on sending to a contract MAY now be followed instead. See “Compatibility with other standards” section.</p>.
</li>
    </ul>
    
    <dt>Scenario #4 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but returns an unknown value.</dt>
    <ul>
      <li>The transfer MUST be reverted.</li>
    </ul>
    
    <dt>Scenario #5 : The receiver implements the necessary ERC1155TokenReceiver interface function(s) but throws an error.</dt>
    <ul>
      <li>The transfer MUST be reverted.</li>
    </ul>
    
    <dt>Scenario #6 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called).</dt>
    <ul>
      <li>The balances for the transfer MUST have been updated before the ERC1155TokenReceiver hook is called on a recipient contract.</li>
      <li>The transfer event MUST have been emitted to reflect the balance changes before the ERC1155TokenReceiver hook is called on the recipient contract.
</li>
      <li>One of onERC1155Received or onERC1155BatchReceived MUST be called on the recipient contract.
</li>
      <li>The onERC1155Received hook SHOULD be called on the recipient contract and its rules followed. See “onERC1155Received rules” for further rules that MUST be followed.
</li>
      <li>The onERC1155BatchReceived hook MAY be called on the recipient contract and its rules followed. See “onERC1155BatchReceived rules” for further rules that MUST be followed.
</li>
    </ul>
    
    <dt>Scenario#7 : The receiver implements the ERC1155TokenReceiver interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called).</dt>
    <ul>
      <li>All balance transfers that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated before the ERC1155TokenReceiver hook is called on the recipient contract.
</li>
      <li>All transfer events MUST have been emitted to reflect current balance changes before an ERC1155TokenReceiver hook is called on the recipient contract.
</li>
      <li>onERC1155Received or onERC1155BatchReceived MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. The return magic value for every hook call MUST be checked and acted upon as per “onERC1155Received rules” and “onERC1155BatchReceived rules”.
</li>
      <li>The onERC1155BatchReceived hook SHOULD be called on the recipient contract and its rules followed. See “onERC1155BatchReceived rules” for further rules that MUST be followed.</li>
      <li>The onERC1155Received hook MAY be called on the recipient contract and its rules followed. See “onERC1155Received rules” for further rules that MUST be followed.
</li>
    </ul>
    
    <dt>Scenario#8 : You are the creator of a contract that implements the ERC1155TokenReceiver interface and you forward the token(s) onto another address in one or both of onERC1155Received and onERC1155BatchReceived.</dt>
    <ul>
      <li>Forwarding should be considered acceptance and then initiating a new safeTransferFrom or safeBatchTransferFrom in a new context.
The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful.</li>
      <li>The _data argument MAY be re-purposed for the new context.</li>
      <li>If forwarding fails the transaction MAY be reverted.
If the contract logic wishes to keep the ownership of the token(s) itself in this case it MAY do so.</li>
    </ul>
    
    <dt>Scenario#9 : You are transferring tokens via a non-standard API call i.e. an implementation specific API and NOT safeTransferFrom or safeBatchTransferFrom.</dt>
    <ul>
      <li>In this scenario all balance updates and events output rules are the same as if a standard transfer function had been called.
i.e. an external viewer MUST still be able to query the balance via a standard function and it MUST be identical to the balance as determined by TransferSingle and TransferBatch events alone.</li>
      <li>If the receiver is a contract the ERC1155TokenReceiver hooks still need to be called on it and the return values respected the same as if a standard transfer function had been called.
However while the safeTransferFrom or safeBatchTransferFrom functions MUST revert if a receiving contract does not implement the ERC1155TokenReceiver interface, a non-standard function MAY proceed with the transfer.
See “Implementation specific transfer API rules”.</li>
    </ul>
    <h4>Rationale</h4>
    <dt>Metadata Choices</dt>
     <p>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.</p>
    <p>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.</p>
    <dt>Upgrades</dt>
    <p>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.</p>
    <dt>Design decision: Supporting non-batch</dt>
    <p>The standard supports safeTransferFrom and onERC1155Received functions because they are significantly cheaper for single token-type transfers, which is arguably a common use case.</p>
<dt>Design decision: Safe transfers only</dt>
    <p>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.</p>
    <dt>Guaranteed log trace</dt>
    <p>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.</p>
    
    <dt>Approval</dt>
    <p>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.</p>
    <p>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.</p>
    <h4>Usage</h4>
    <p>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.</p>
    <dt>Batch Transfers</dt>
    <p>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.</p>
    <p>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.</p>
    <p>It is RECOMMENDED that clients and wallets sort the token IDs and associated values (in ascending order) when posting a batch transfer, as some ERC-1155 implementations offer significant gas cost savings when IDs are sorted. See Horizon Games - Multi-Token Standard “packed balance” implementation for an example of this.</p>
    <dt>Batch Balance</dt>
    <p>The balanceOfBatch function allows clients to retrieve balances of multiple owners and token IDs with a single call.</p>
    <dt>Enumerating from events</dt>
    <p>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.</p>
 <p>ERC-1155 contracts must therefore carefully emit TransferSingle or TransferBatch events in any instance where tokens are created, minted, transferred or destroyed.</p>   
 <h4>Non-Fungible Tokens</h4>
    <p>The following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this:</p>
   <dt>Split ID bits</dt>
    <p>The top 128 bits of the uint256 _id parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique.</p>
    <p>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 a particular non-fungible within that set, _id could be passed as ' uint128: base token id '' uint128: index of non-fungible ' .</p>
    <p>To identify a non-fungible set/category as a whole (or a fungible) you COULD just pass in the base id via the _id argument as ' uint128: base token id '' uint128: zero '. If your implementation uses this technique this naturally means the index of a non-fungible SHOULD be 1-based.</p>
    <p>Inside the contract code the two pieces of data needed to access the individual non-fungible can be extracted with uint128(~0) and the same mask shifted by 128.</p>
    <code>
      uint256 baseTokenNFT = 12345 << 128;
uint128 indexNFT = 50;

uint256 baseTokenFT = 54321 << 128;

balanceOf(baseTokenNFT, msg.sender); // Get balance of the base token for non-fungible set 12345 (this MAY be used to get balance of the user for all of this token set if the implementation wishes as a convenience).
balanceOf(baseTokenNFT + indexNFT, msg.sender); // Get balance of the token at index 50 for non-fungible set 12345 (should be 1 if user owns the individual non-fungible token or 0 if they do not).
balanceOf(baseTokenFT, msg.sender); // Get balance of the fungible base token 54321.
    </code>
    <p>Note that 128 is an arbitrary number, an implementation MAY choose how they would like this split to occur as suitable for their use case. An observer of the contract would simply see events showing balance transfers and mints happening and MAY track the balances using that information alone. For an observer to be able to determine type (non-fungible or fungible) from an ID alone they would have to know the split ID bits format on a implementation by implementation basis.</p>
    <dt>Natural Non-Fungible tokens</dt>
 <p>Another simple way to represent non-fungibles is to allow a maximum value of 1 for each non-fungible token. This would naturally mirror the real world, where unique items have a quantity of 1 and fungible items have a quantity greater than 1.</p>   
    <h4>Implementations</h4>
    <ul>
      <li><a href="http://github.com/enjin/erc-1155">Enjin Coin Multi-Token Standard</a></li>
      <li><a href="https://github.com/horizon-games/multi-token-standard">Horizon Games Multi-Token Standard</a></li>
      <li><a href="https://github.com/pixowl/thesandbox-contracts/tree/master/src/Asset">The Sandbox Multi-Token Standard</a></li>
    </ul>
    <h4>Rules</h4>
    <dt>safeTransferFrom rules:</dt>
    <ul>
      <li>Caller must be approved to manage the tokens being transferred out of the _from account (see “Approval” section).
</li>
      <li>MUST revert if _to is the zero address.
</li>
      <li>MUST revert if balance of holder for token _id is lower than the _value sent to the recipient.
</li>
      <li>MUST revert on any other error.
</li>
      <li>MUST emit the TransferSingle event to reflect the balance change (see “TransferSingle and TransferBatch event rules” section).
</li>
      <li>After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received on _to and act appropriately (see “onERC1155Received rules” section). The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the onERC1155Received hook function via its _data argument.
</li>
    </ul>
    <dt>safeBatchTransferFrom rules:</dt>
    <ul>
      <li>Caller must be approved to manage all the tokens being transferred out of the _from account (see “Approval” section).</li>
      <li>MUST revert if _to is the zero address.</li>
      <li>MUST revert if length of _ids is not the same as length of _values.</li>
      <li>MUST revert if any of the balance(s) of the holder(s) for token(s) in _ids is lower than the respective amount(s) in _values sent to the recipient.
</li>
      <li>MUST revert on any other error.
</li>
      <li>MUST emit TransferSingle or TransferBatch event(s) such that all the balance changes are reflected (see “TransferSingle and TransferBatch event rules” section).
</li>
      <li>The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc).
</li>
      <li>After the above conditions are met, this function MUST check if _to is a smart contract (e.g. code size > 0). If so, it MUST call onERC1155Received or onERC1155BatchReceived on _to and act appropriately (see “onERC1155Received and onERC1155BatchReceived rules” section).The _data argument provided by the sender for the transfer MUST be passed with its contents unaltered to the ERC1155TokenReceiver hook function(s) via their _data argument.
</li>
    </ul>
    <dt>TransferSingle and TransferBatch event rules:</dt>
    <ul>
      <li>TransferSingle SHOULD be used to indicate a single balance transfer has occurred between a _from and _to pair.</li>
      <li>It MAY be emitted multiple times to indicate multiple balance changes in the transaction, but note that TransferBatch is designed for this to reduce gas consumption.
</li>
      <li>The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
</li>
      <li>The _from argument MUST be the address of the holder whose balance is decreased.
</li>
      <li>The _to argument MUST be the address of the recipient whose balance is increased.
</li>
      <li>The _id argument MUST be the token type being transferred.
</li>
      <li>The _value argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by.
</li>
      <li>When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.
</li>
      <li>When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.
</li>
    </ul>
    <ul>
      <li>TransferBatch SHOULD be used to indicate multiple balance transfers have occurred between a _from and _to pair.
</li>
      <li>It MAY be emitted with a single element in the list to indicate a singular balance change in the transaction, but note that TransferSingle is designed for this to reduce gas consumption.
</li>
      <li>The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
</li>
      <li>The _from argument MUST be the address of the holder whose balance is decreased for each entry pair in _ids and _values.
</li>
      <li>The _to argument MUST be the address of the recipient whose balance is increased for each entry pair in _ids and _values.
</li>
      <li>The _ids array argument MUST contain the ids of the tokens being transferred.
</li>
      <li>The _ids array argument MUST contain the ids of the tokens being transferred.
</li>
      <li>_ids and _values MUST have the same length.
</li>
      <li>When minting/creating tokens, the _from argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.
</li>
      <li>When burning/destroying tokens, the _to argument MUST be set to 0x0 (i.e. zero address). See “Minting/creating and burning/destroying rules”.
</li>
    </ul>
    
    <ul>
      <li>The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.
</li>
      <li>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.
</li>
      <li>All TransferSingle and TransferBatch events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to onERC1155Received or onERC1155BatchReceived. To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract.
</li>
    </ul>
    <dt>onERC1155BatchReceived rules:</dt>
    <ul>
      <li>The _operator argument MUST be the address of an account/contract that is approved to make the transfer (SHOULD be msg.sender).
</li>
      <li>The _from argument MUST be the address of the holder whose balance is decreased. _from MUST be 0x0 for a mint.

</li>
      <li>The _ids argument MUST be the list of tokens being transferred.
</li>
      <li>The _values argument MUST be the list of number of tokens (matching the list and order of tokens specified in _ids) the holder balance is decreased by and match what the recipient balance is increased by.
</li>
      <li>The _data argument MUST contain the information provided by the sender for the transfer with its contents unaltered. i.e. it MUST pass on the unaltered _data argument sent via the safeBatchTransferFrom call for this transfer.
</li>
      <li>The recipient contract MAY accept an increase of its balance by returning the acceptance magic value bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
</li>
      <li>If the return value is bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transfer MUST be completed or MUST revert if any other conditions are not met for success.
</li>
      <li>The recipient contract MAY reject an increase of its balance by calling revert. If the recipient contract throws/reverts the transaction MUST be reverted. If the return value is anything other than bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transaction MUST be reverted.
</li>
      <li> A contract MAY skip calling the onERC1155BatchReceived hook function if the transfer operation is transferring the token(s) to itself.

</li>
      <li>onERC1155BatchReceived (and/or onERC1155Received) MAY be called multiple times in a single transaction and the following requirements must be met: 
        <ul>
          <li>All callbacks represent mutually exclusive balance changes.
</li>
          <li>The set of all calls to onERC1155Received and onERC1155BatchReceived describes all balance changes that occurred during the transaction in the order submitted.
</li>
        </ul>
</li>
    </ul>
    
    <dt>ERC1155TokenReceiver ERC-165 rules:</dt>
    <ul>
      <li>The implementation of the ERC-165 supportsInterface function SHOULD be as follows: <code>  function supportsInterface(bytes4 interfaceID) external view returns (bool) {
      return  interfaceID == 0x01ffc9a7 ||    // ERC-165 support (i.e. `bytes4(keccak256('supportsInterface(bytes4)'))`).
              interfaceID == 0x4e2312e0;      // ERC-1155 `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`).
  }</code>
        
</li>
      <li>The implementation MAY differ from the above but:
<ul>
  <li>It MUST return the constant value true if 0x01ffc9a7 is passed through the interfaceID argument. This signifies ERC-165 support.
</li>
  <li>It MUST return the constant value true if 0x4e2312e0 is passed through the interfaceID argument. This signifies ERC-1155 ERC1155TokenReceiver support.
</li>
  <li>It MUST NOT consume more than 10,000 gas. This keeps it below the ERC-165 requirement of 30,000 gas, reduces the gas reserve needs and minimises possible side-effects of gas exhaustion during the call.
</li>
</ul> 
 </li>
      
    </ul>
    
    <dt>Implementation specific transfer API rules:</dt>
    <p>If an implementation specific API function is used to transfer ERC-1155 token(s) to a contract, the safeTransferFrom or safeBatchTransferFrom (as appropriate) rules MUST still be followed if the receiver implements the ERC1155TokenReceiver interface. If it does not the non-standard implementation SHOULD revert but MAY proceed.
</p>
    <p>An Example</p>
 <ul>
   <li>An approved user calls a function such as function myTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values);.
</li>
   <li>myTransferFrom updates the balances for _from and _to addresses for all _ids and _values.
</li>
   <li>myTransferFrom emits TransferBatch with the details of what was transferred from address _from to address _to.
</li>
   <li>myTransferFrom checks if _to is a contract address and determines that it is so (if not, then the transfer can be considered successful).
</li>
   <li>myTransferFrom calls onERC1155BatchReceived on _to and it reverts or returns an unknown value (if it had returned bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) the transfer can be considered successful).
</li>
   <li>At this point myTransferFrom SHOULD revert the transaction immediately as receipt of the token(s) was not explicitly accepted by the onERC1155BatchReceived function.
</li>
   <li>If however myTransferFrom wishes to continue it MUST call supportsInterface(0x4e2312e0) on _to and if it returns the constant value true the transaction MUST be reverted, as it is now known to be a valid receiver and the previous acceptance step failed. NOTE: You could have called supportsInterface(0x4e2312e0) at a previous step if you wanted to gather and act upon that information earlier, such as in a hybrid standards scenario.
</li>
   <li>If the above call to supportsInterface(0x4e2312e0) on _to reverts or returns a value other than the constant value true the myTransferFrom function MAY consider this transfer successful. NOTE: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens.

</li>
 </ul>
    
    <blockquote>NOTE: this MAY result in unrecoverable tokens if sent to an address that does not expect to receive ERC-1155 tokens.</blockquote>
    <ul>
      <li>Balances that are updated MUST have equivalent transfer events emitted.</li>
      <li>A receiver address has to be checked if it is a contract and if so relevant ERC1155TokenReceiver hook function(s) have to be called on it.
</li>
      <li>Balances (and events associated) that are referenced in a call to an ERC1155TokenReceiver hook MUST be updated (and emitted) before the ERC1155TokenReceiver hook is called.
</li>
      <li>The return values of the ERC1155TokenReceiver hook functions that are called MUST be respected if they are implemented.
</li>
      <li>Only non-standard transfer functions MAY allow tokens to be sent to a recipient contract that does NOT implement the necessary ERC1155TokenReceiver hook functions. safeTransferFrom and safeBatchTransferFrom MUST revert in that case (unless it is a hybrid standards implementation see “Compatibility with other standards”).
</li>
    </ul>

    <dt>Minting/creating and burning/destroying rules:</dt>
    <p>A mint/create operation is essentially a specialized transfer and MUST follow these rules:
</p>
    <ul>
      <li>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.
</li>
      <li>The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the _from argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a mint to contract observers. NOTE: This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too.
</li>
    </ul>
    <p>A burn/destroy operation is essentially a specialized transfer and MUST follow these rules:
</p>
    <ul>
      <li>The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the burn(s) (i.e. singles or batches) however the _to argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a burn to contract observers.
</li>
      <li>When burning/destroying you do not have to actually transfer to 0x0 (that is impl specific), only the _to argument in the event MUST be set to 0x0 as above.
</li> 
      <li>The total value transferred from address 0x0 minus the total value transferred to 0x0 observed via the TransferSingle and TransferBatch events MAY be used by clients and exchanges to determine the “circulating supply” for a given token ID.
</li>
<li>As mentioned above mint/create and burn/destroy operations are specialized transfers and so will likely be accomplished with custom transfer functions rather than safeTransferFrom or safeBatchTransferFrom. If so the “Implementation specific transfer API rules” section would be appropriate. Even in a non-safe API and/or hybrid standards case the above event rules MUST still be adhered to when minting/creating or burning/destroying.

</li>
<li>A contract MAY skip calling the ERC1155TokenReceiver hook function(s) if the mint operation is transferring the token(s) to itself. In all other cases the ERC1155TokenReceiver rules MUST be followed as appropriate for the implementation (i.e. safe, custom and/or hybrid).
</li>
    </ul>
    <p>A solidity example of the keccak256 generated constants for the various magic values (these MAY be used by implementation):
</p>
    <code>bytes4 constant public ERC1155_ERC165 = 0xd9b67a26; // ERC-165 identifier for the main token standard.
bytes4 constant public ERC1155_ERC165_TOKENRECEIVER = 0x4e2312e0; // ERC-165 identifier for the `ERC1155TokenReceiver` support (i.e. `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) ^ bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`).
bytes4 constant public ERC1155_ACCEPTED = 0xf23a6e61; // Return value from `onERC1155Received` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))`).
bytes4 constant public ERC1155_BATCH_ACCEPTED = 0xbc197c81; // Return value from `onERC1155BatchReceived` call if a contract accepts receipt (i.e `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))`).
</code>
    
    <h4>Compatibility with other standards
</h4>
    <p>There have been requirements during the design discussions to have this standard be compatible with existing standards when sending to contract addresses, specifically ERC-721 at time of writing. To cater for this scenario, there is some leeway with the revert logic should a contract not implement the ERC1155TokenReceiver as per “Safe Transfer Rules” section above, specifically “Scenario#3 : The receiver does not implement the necessary ERC1155TokenReceiver interface function(s)”.</p>
    <p>Hence in a hybrid ERC-1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to onERC1155Received or onERC1155BatchReceived are made. Order of operation MUST therefore be:</p>
    <ul>
      <li>The implementation MUST call the function supportsInterface(0x4e2312e0) on the recipient contract, providing at least 10,000 gas.
</li>
      <li>If the function call succeeds and the return value is the constant value true the implementation proceeds as a regular ERC-1155 implementation, with the call(s) to the onERC1155Received or onERC1155BatchReceived hooks and rules associated.
</li>
      <li>If the function call fails or the return value is NOT the constant value true the implementation can assume the recipient contract is not an ERC1155TokenReceiver and follow its other standard’s rules for transfers.
</li>
    </ul>

    <p>Note that a pure implementation of a single standard is recommended rather than a hybrid solution, but an example of a hybrid ERC-1155/ERC-721 contract is linked in the references section under implementations. An important consideration is that even if the tokens are sent with another standard’s rules the ERC-1155 transfer events MUST still be emitted. This is so the balances can still be determined via events alone as per ERC-1155 standard rules.</p>
    
    <h4>Metadata</h4>
    <p>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 a large number of tokens to use the same on-chain string by defining a URI once, for that large number of tokens.</p>
    <ul>
      <li>The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.
</li>
      <li>The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.
</li>
      <li>Example of such a URI: https://token-cdn-domain/{id}.json would be replaced with https://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json if the client is referring to token ID 314592/0x4CCE0.</li>
      
    </ul>
    
    <dt>Metadata Extensions</dt>
    <p>The optional ERC1155Metadata_URI extension can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165].</p>
    <p>If the optional ERC1155Metadata_URI extension is included:</p>
    <ul>
      <li>The ERC-165 supportsInterface function MUST return the constant value true if 0x0e89341c is passed through the interfaceID argument.
</li>
      <li>Changes to the URI MUST emit the URI event if the change can be expressed with an event (i.e. it isn’t dynamic/programmatic). An implementation MAY emit the URI event during a mint operation but it is NOT mandatory. An observer MAY fetch the metadata uri at mint time from the uri function if it was not emitted.

</li>
      <li>The uri function SHOULD be used to retrieve values if no event was emitted.
</li>
      <li>The uri function MUST return the same value as the latest event for an _id if it was emitted.
</li>
      <li>The uri function MUST NOT be used to check for the existence of a token as it is possible for an implementation to return a valid string even if the token does not exist.
</li>
    </ul>
    
<code>pragma solidity ^0.5.9;

/**
    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 MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema".        
        @return URI string
    */
    function uri(uint256 _id) external view returns (string memory);
}</code>
    
    <dt>ERC-1155 Metadata URI JSON Schema</dt>
    <p>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.
</p>
<ul>
  <li>The string format of the substituted hexadecimal ID MUST be lowercase alphanumeric: [0-9a-f] with no 0x prefix.</li>
  <li>The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary.
</li>
</ul>    

    <code>
      {
    "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.",
        },
    }
}
    </code>
 
    <p>An example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata.</p>

    <code>{
	"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"
		}
	}
}</code>
    
    <dt>Localization</dt>
    <p>Metadata localization should be standardized to increase presentation uniformity across all languages. As such, a simple overlay method is proposed to enable localization. If the metadata JSON file contains a localization attribute, its content MAY be used to provide localized values for fields that need it. The localization attribute should be a sub-object with three attributes: uri, default and locales. If the string {locale} exists in any URI, it MUST be replaced with the chosen locale by all client software.</p>
    
    <dt>JSON Schema</dt>
    <code>{
    "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/)."
                }
            }
        },
    }
}
</code>
    <dt>Localized Sample</dt>
    <p>Base URI:</p>
    <code>{
  "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"]
  }
}
</code>
    <p>es.json:</p>
    <code>
      {
  "name": "Espacio Publicitario",
  "description": "Cada token representa un espacio publicitario único en la ciudad."
}
    </code>
<p>fr.json:</p>
    <code>
      {
  "name": "Espace Publicitaire",
  "description": "Chaque jeton représente un espace publicitaire unique dans la ville."
}
    </code>
    
    <h4>Approval</h4>
    <p>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. The counterpart isApprovedForAll provides introspection into any status set by setApprovalForAll.</p>
    <p>An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call setApprovalForAll to approve themselves as an operator before they can operate on them.</p>
    
    
  </section>
  <section class="main-section" id="137">
    <h2>EIP 137: Ethereum Domain Name Service</h2>
  </section>
  <section class="main-section" id="165">
    <h2>EIP 165: ERC-165 Standard Interface Detection</h2>
  </section>
  <section class="main-section" id="190">
    <h2>EIP 190: Ethereum Smart Contract Packaging Standard</h2>
  </section>
  <section class="main-section" id="627">
    <h2>EIP 627: Whisper Specification</h2>
  </section>
  
</main>
              
            
!

CSS

              
                html,
body {
  min-width: 290px;
  color: #4d4e53;
  background-color: #ffffff;
  font-family: "Open Sans", Arial, sans-serif;
  line-height: 1.5;
}

#navbar {
  position: fixed;
  min-width: 290px;
  top: 0px;
  left: 0px;
  width: 300px;
  height: 100%;
  border-right: solid;
  border-color: rgba(0, 22, 22, 0.4);
}

header {
  color: black;
  margin: 10px;
  text-align: center;
  font-size: 1.8em;
  font-weight: thin;
}

#main-doc header {
  text-align: left;
  margin: 0px;
}

#navbar ul {
  height: 88%;
  padding: 0;
  overflow-y: auto;
  overflow-x: hidden;
}

#navbar li {
  color: #4d4e53;
  border-top: 1px solid;
  list-style: none;
  position: relative;
  width: 100%;
}

#navbar a {
  display: block;
  padding: 10px 30px;
  color: #4d4e53;
  text-decoration: none;
  cursor: pointer;
}

#main-doc {
  position: absolute;
  margin-left: 310px;
  padding: 20px;
  margin-bottom: 110px;
}

section article {
  color: #4d4e53;
  margin: 15px;
  font-size: 0.96em;
}

section li {
  margin: 15px 0px 0px 20px;
}

code {
  display: block;
  text-align: left;
  white-space: pre;
  position: relative;
  word-break: normal;
  word-wrap: normal;
  line-height: 2;
  background-color: #f7f7f7;
  padding: 15px;
  margin: 10px;
  border-radius: 5px;
}

@media only screen and (max-width: 815px) {
  /* For mobile phones: */
  #navbar ul {
    border: 1px solid;
    height: 207px;
  }

  #navbar {
    background-color: white;
    position: absolute;
    top: 0;
    padding: 0;
    margin: 0;
    width: 100%;
    max-height: 275px;
    border: none;
    z-index: 1;
    border-bottom: 2px solid;
  }

  #main-doc {
    position: relative;
    margin-left: 0px;
    margin-top: 270px;
  }
}

@media only screen and (max-width: 400px) {
  #main-doc {
    margin-left: -10px;
  }

  code {
    margin-left: -20px;
    width: 100%;
    padding: 15px;
    padding-left: 10px;
    padding-right: 45px;
    min-width: 233px;
  }
}
              
            
!

JS

              
                




              
            
!
999px

Console