Automatically merged updates to draft EIP(s) 777

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

EIPS/eip-777.md

@@ -75,7 +75,9 @@ The token contract MUST implement the above interface. The implementation MUST f
 
 The token contract MUST register the `ERC777Token` interface with its own address via [ERC820]. If the contract has a switch to enable or disable [ERC777] functions, every time the switch is triggered, the token MUST register or unregister the `ERC777Token` interface for its own address accordingly via [ERC820]. (Unregistering implies setting the address to `0x0`.)
 
-The basic unit token MUST be 10<sup>18</sup> (i.e., [ERC20]'s `decimals` MUST be `18`). All functions MUST consider any amount of tokens (such as balances and amount to send, mint, or burn) in the basic unit.
+The smallest unit&mdash;for all interactions with the token contract&mdash;MUST be `1`. I.e. all amounts and balances MUST be unsigned integers. The display denomination&mdash;to display any amount to the end user&mdash;MUST be 10<sup>18</sup> of the smallest.
+
+In other words the technical denomination is similar to a wei and the display denomination is similar to an ether. It is equivalent to an  [ERC20]'s `decimals` function returning `18`. E.g. if a token contract holds a balance of `500,000,000,000,000,000` (0.5&times;10<sup>18</sup>) for a user, the user interface SHOULD show `0.5` tokens to the user. If the user wishes to send `0.3` tokens, the contract MUST be called with an amount of `300,000,000,000,000,000` (0.3&times;10<sup>18</sup>).
 
 #### **View Functions**
 
@@ -111,7 +113,7 @@ Get the total number of minted tokens.
 
 The total supply MUST be equal to the sum of the balances of all addresses&mdash;as returned by the `balanceOf` function.
 
-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.
+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>
 
@@ -138,22 +140,24 @@ function granularity() public view returns (uint256)
 
 Get the smallest part of the token that's not divisible.
 
+In other words, the granularity is the smallest number of tokens (in the basic unit) which MAY be minted, sent or burned at any time.
+
 The following rules MUST be applied regarding the *granularity*:
 
-- The *granularity* value MUST be at creation time.
+- The *granularity* value MUST be set at creation time.
 - The *granularity* value MUST NOT be changed ever.
 - The *granularity* value MUST be greater or equal to `1`.
 - Any minting, send or burning of tokens MUST be a multiple of the *granularity* value.
 - 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`.
 
-*NOTE*: Most of the tokens SHOULD be fully partitionable. I.e., this function SHOULD return `1` unless there is a good reason for not allowing any partition of the token.
+*NOTE*: Most of the tokens SHOULD be fully partitionable. I.e., this function SHOULD return `1` unless there is a good reason for not allowing any fraction of the token.
 
 > <small>**returns:** The smallest non-divisible part of the token.</small>
 
 *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] enabled token, the `decimal` function is REQUIRED and MUST return `18`.
+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.)
 
 *[ERC20] compatibility requirement*:  
 The `name`, `symbol`, `totalSupply`, and `balanceOf` `view` functions MUST be backward compatible with [ERC20].
@@ -287,7 +291,7 @@ When an *operator* sends an `amount` of tokens from a *token holder* to a *recip
 - The balance of the *token holder* MUST be greater or equal to the `amount`&mdash;such that its resulting balance is greater or equal to zero (`0`) after the send.
 - The token contract MUST emit a `Sent` event with the correct values as defined in the [`Sent` Event][sent].
 - The *operator* MAY communicate any information in the `operatorData`.
-- The token contract MUST call the `tokensToSend` hook of the *token holder* if the *token holder* registers an `ERC777TokensRecipient` implementation via [ERC820].
+- The token contract MUST call the `tokensToSend` hook of the *token holder* if the *token holder* registers an `ERC777TokensSender` implementation via [ERC820].
 - The token contract MUST call the `tokensReceived` hook of the *recipient* if the *recipient* registers an `ERC777TokensRecipient` implementation via [ERC820].
 - The `data` and `operatorData` MUST be immutable during the entire send process&mdash;hence the same `data` and `operatorData` MUST be used to call both hooks and emit the `Sent` event.
 
@@ -398,6 +402,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.
+
 *[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.