status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-27 07:05:47 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 777

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Jacques Dafflon 2018-08-28 20:31:03 +02:00 committed by EIP Automerge Bot
parent 46961da17b
commit b20415cb9d
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
EIPS/eip-777.md
View File

@ -111,9 +111,10 @@ function totalSupply() public view returns (uint256)
Get the total number of minted tokens.
The total supply MUST be equal to the sum of the balances of all addresses—as returned by the `balanceOf` function.
*NOTE*: The total supply MUST be equal to the sum of the balances of all addresses—as returned by the `balanceOf` function.
*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. (This applies as well to [tokens minted when the token contract is created][initial supply].)
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. One exception is a cloned token (with cloned balances) where the newer token contract MAY have a `totalSupply` greater than the difference of all the `Minted` and `Burned` events.
> <small>**returns:** Total supply of tokens currently in circulation.</small>
@ -157,7 +158,7 @@ The following rules MUST be applied regarding the *granularity*:
*NOTE*: [`defaultOperators`][defaultOperators] and [`isOperatorFor`][isOperatorFor] are also `view` functions, defined under the [operators] for consistency.
*[ERC20] compatibility requirement*:
The decimals of the token MUST always be `18`. For a *pure* ERC777 token the [ERC20] `decimal` 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 `decimal` function is REQUIRED and MUST return `18`. (In [ERC20], the `decimals` function is OPTIONAL, but the value if the function is not present, is not clearly defined and may be assumed to be `0`. Hence for compatibility reasons, `decimals` MUST be implemented for [ERC20] compatible tokens.)
The decimals of the token MUST always be `18`. For a *pure* ERC777 token the [ERC20] `decimal` 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 `decimal` 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.)
*[ERC20] compatibility requirement*:
The `name`, `symbol`, `totalSupply`, and `balanceOf` `view` functions MUST be backward compatible with [ERC20].
@ -402,7 +403,8 @@ The token contract MUST `revert` when minting in any of the following cases:
- The *recipient* is a contract, and it does not implement the `ERC777TokensRecipient` interface via [ERC820].
- The address of the *recipient* is `0x0`.
*NOTE*: The initial token supply at the creation of the token contract MUST be considered as minting for the amount of the initial supply to the address (or addresses) receiving the initial supply.
<a id="initialSupply"></a>
*NOTE*: The initial token supply at the creation of the token contract MUST be considered as minting for the amount of the initial supply to the address(es) receiving the initial supply. This means one or more `Minted` events must be emitted and the `tokensReceived` hook of the recipient(s) MUST be called.
*[ERC20] compatibility requirement*:
While a `Sent` event MUST NOT be emitted when minting, if the token contract is [ERC20] backward compatible, a `Transfer` event with the `from` parameter set to `0x0` SHOULD be emitted as defined in the [ERC20] standard.
@ -619,7 +621,7 @@ Notify a send or mint (if `from` is `0x0`) of `amount` tokens from the `from` ad
> <small>`from`: *token holder* for a send and `0x` for a mint.</small>
> <small>`to`: *token recipient*.</small>
> <small>`amount`: Number of tokens the *recipient* balance is increased by.</small>
> <small>`data`: Extra information provided by the *token holder* for a send and nothing (empty bytes) for a mint,.</small>
> <small>`data`: Extra information provided by the *token holder* for a send and nothing (empty bytes) for a mint.</small>
> <small>`operatorData`: Extra information provided by the address which triggered the balance increase.</small>
The following rules apply when calling the `tokensToSend` hook:
@ -759,6 +761,7 @@ Copyright and related rights waived via [CC0].
[sent]: #sent
[minted]: #minted
[burned]: #burned
[initial supply]: #initialSupply
[logos]: https://github.com/ethereum/EIPs/tree/master/assets/eip-777/logo
[beige logo]: ../assets/eip-777/logo/png/ERC-777-logo-beige-48px.png