Was there discussion of adding a Mint/Burn pair of events and/or mint/burn functions to this proposed standard?

If this was discussed and rejected, what are the reasons for rejecting it? If it was not discussed, should it have been?

While not foolproof (because a contract may neglect to call these events), it would make the automated accounting of ICO sales for token contracts that do comply a lot easier. To accurately account for existing ERC 20 token sales, one must read and understand the contract's code.

What is the use of _to while is obvious that is the TokenFallback reciever itself (the contract address(this)), and why is needed _ref if we can store a _ref data inside _data if application needs it?

I would find better to stick to the needed stuff, such as:

    /**
    * @notice ERC223 and ERC667 Token fallback 
    * @param _from sender of token
    * @param _amount value sent
    * @param _data data sent
    **/    
    function tokenFallback(
        address _from,
        uint _amount,
        bytes _data
    )

Can you describe situations where _ref and _to are important, or crucial?

@3esmit The _to is because the proxy that handles the interface for a specific address can be a different contract. Please see EIP #672 .

For the _ref, this should act as a reference, for example a check number, or an invoice number. In general the ref will be set by the operator and the data will be set for the sender and will be the equivalent to the data in an ethereum transaction.

May be a good alternative would be to integrate this 2 parameters in data and define a standard for data This way we would maintain current compatibility with EIP223...

I suggest also adding a boolean return to tokenFallback, and token contract require a true return to accept transaction, in order to avoid this scenario: dapperlabs/cryptokitties-bounty#3

@3esmit This is problematic. This function is called after the transfer is done. So returning false would mean to rollback the transfer. This can add a lot of reentrance issues, so I decided that the function ether executes or throws the full transaction.
The nice thing of this standard is that if the tokens a sent via send it eans the the receiver must register the interface in EIP672 way. If not, it fails. Of course you can use the old transfer method for backwards compatibility.

I propose renaming operatorData to logData to make more explicit that the purpose of that data is no other than being part of a log. The ability of adding context to token transfers is powerful, and the gas hit is minimal when they are not used.

Really like and support this proposal, exactly the vision that made me excited about ERC223 10 months (!!!) ago. We are considering making ERC777 the base standard for all the tokens issued on @aragon!

This is an interesting proposal, but I worry about the entire ecosystem having to migrate to new multisig wallets in order to be able to receive ERC777 tokens.

It seems like there was an attempt made to create a whitelist of contracts that one can safely transfer to even if they do not implement ITokenReceipient:

The function MUST throw if:

• to is a contract that is not prepared to receive tokens. That is it is a contract that does not implements ITokensReceived interface and the hash of the sourcecode is not in between the whitilisted codes listed in the appendix of this code.

But there is no such appendix, I would love to see it 😊

@onbjerg We are working on it. We are thinking in keeping this list open for a while (centralized) and close the list at some point (make it decentralized).

Was there any consideration over allowing users to specify how much an operator can control, e.g. changing authorizeOperator() to:

function authorizeOperator(address operator, uint authorizedAmount) public?

One could use 2^256 - 1 (or hypothetically the totalSupply() if that never grows) to simulate the previous true behaviour and 0 for false.

The only difference for new contracts implementing ERC20 is that registration of ITokenRecipient via EIP-672 takes precedence over ERC20. This means that even with on a ERC20 transfer call, the token contract MUST check via EIP-672 if the to address implements tokensReceived and call it if available.

I find this somewhat confusing and unexpected. We'll have a dichotomy of "ERC20" tokens: ones that will never call the tokensReceived() callback, even if ITokenRecipient is registered; and ones that will always check. Even if the ERC20 functions are only supposed to be called via old contracts, I think there'll be lots of confusion about this since the meaning of what an "ERC20" token will have essentially changed depending on if your token also supports EIP777.

It also feels odd because you don't have to support the ERC20 interface with EIP777, but you most likely will to support prior contracts expecting that standard.

What if EIP777 was instead a superset of ERC20's interface but overrided specific parts, e.g. transfer() and transferFrom(), to support the ITokenRecipient interface?

I kind of like and dislike the send() nomenclature. On one hand, it's nice how it parallel's ETH's transfer() and send() nomenclature. On the other, it's confusing because these two terms are now both overloaded with different meanings for ETH and tokens. It's confusing enough that we have both for ETH, but it's going to be even more confusing when there's the same names for tokens. I do like the naming for transferAndCall() because it's really obvious what it's probably going to do.

I guess an alternative could be transferToRecipient().

@sohkai:
1.- The idea o authorizeOperator is mainly to authorise a contract.
The maximum allowed limitation and many others limitations, like a daily limits, should be implemented in the operator contract and keep this standard as clean as possible.

2.- The idea is that the receiver should have the warranty that the tokensReceived() method is ALWAYS called. Even if it is called via an obsolete ERC20 transfer() or transferFrom() method. This way, for example, allows a recipient to NEVER accept a specific token. or forward some tokens to a specific charity.

3.- The big problem of maintaining transfer() name in the new standard is that if you use transfer() in an ERC20 only token, you will end up locking a lot of tokens. This mistake might become very common in a moment where 50% of the tokens are ERC20Only and 50%ERC777.

As I have mentioned in other threads, I strongly recommend removing decimals. Here is a cross post of what I have said elsewhere:

Decimals are easily the number one source of confusion for both token authors and users of ERC20. I strongly recommend removing this as a variable and instead asserting that tokens must have a certain "humanizing divisor". Reasonable choices IMO are:

• 0 - The purpose of decimals is to humanize a very large number, nothing more. If you issue a bunch of your tokens, then people can work with gigatokens instead of tokens. People are used to this already with hard drives (no one talks about hard drive size in bytes, it's gigabytes or terrabytes). This scales with the system and allows it to easily change with time.
• 10^24 - This Allows the token to center on a range that is maximally within the accepted SI prefixes, ranging all the way from yoctotokens to yottatokens. From a scientific/mathematics standpoint, this is probably the best option.
• 10^18 - 10^18 is the most common humanizing divisor, and it is what ETH used. In order to limit confusion, there may be value in asserting that everyone should just use this. While this isn't a particularly optimal choice, it is fairly compelling due to ETH choosing it.
• 10^2 - Most fiat currencies use cents, in general, population is more used to currencies with 2 decimals than 0 or more than 2. I'm including this for completeness, but it ends up being effectively the same as 0.

I think the worst option is to continue to allow for variable humanizing divisors. This doesn't actually solve any real problems, since any chosen unit is very likely to be a wrong choice at some point in time (too big or too small). Also, since the token author can pick the token supply, allowing them to also choose the humanizing divisor doesn't give them any more/less power to try to target a "nice human-scale number".

You mention function send(address to, uint256 value, bytes userData, bytes operatorData) public; in the interface but it doesn't appear in the function descriptions below. Perhaps it was meant to be replaced by operatorSend but you forgot to delete it from the interface?

I recommend splitting function authorizeOperator(address operator, bool authorized) public; into:

function authorizeOperator(address operator) public;
function revokeOperator(address operator) public;

At the callsite, this will provide a lot more clarity as to what is happening.

This is rad. Its going to be a long, slow journey to move away from ERC20 but this is a good first step. Couple things:

1. Why has spender authorization been moved to a boolean? I personally haven't found a use-case for allowing a spender to access a specific amount, but it seems like a nice feature to have since its already part of an existing standard.
2. Why use the noun operator? I understand this is stupid-picky and certainly hair-splitty, but the work spender is, IMO, a really good descriptor of that particular actor. Operator just sounds like the person has more capability than they do (they aren't really "operating" on the tokens).

Anyways, big 👍. ERC20 needs an upgrade.

Public state variable for decimal is string public decimals;?
I think that should be uint8 public decimals; based on function decimals() public constant returns (uint8). Prolly a typo.

As I have mentioned in other threads, I strongly recommend removing decimals. Here is a cross post of what I have said elsewhere:

Unfortunately quite a few coins have a very good reason for selecting a different number of decimals. Many of them are in the wild already. Forcing all 10 n decimals would require internal restrictions that would, for example, force rounding of values or revert if an incorrect amount is specified.

Our objective is seldom to expect people to interact directly with the blockchain but, as an example, MEW does a good job of removing the decimal confusion.

Should the ITokenRecipient contract also have a function that always returns true stating it's capable of this? It's a way to allow wallet implementers to know which function to use, and therefore save gas.

function isITokenRecipient() returns (bool) { return true};

Great stuff!

1- initially I too thought as @sohkai that authorizeOperator() would need a form of limiting the amount. In the end the ERC20 approve (which is a confusing name) does have a value up to which the spender is allowed.

I understand and share what you say

The idea o authorizeOperator is mainly to authorise a contract.
The maximum allowed limitation and many others limitations, like a daily limits, should be implemented in the operator contract and keep this standard as clean as possible

But I also think that it's an interesting addition to remind implementers to include optional limitation logic.

2- operatorSend userData vs operatorData
what is the scenario you are imagining for userData?
in any case it's a data that the operator has to input when calling the operatorSend function. Why couldn't both data points be contained in one?

3- Backwards Compatibility
I also found this a bit confusing

The only difference for new contracts implementing ERC20 is that registration of ITokenRecipient via EIP-672 takes precedence over ERC20. This means that even with on a ERC20 transfer call, the token contract MUST check via EIP-672 if the to address implements tokensReceived and call it if available.

I understand that new smart contracts will detect the right function to call (right?)
but what about users interacting directly with the contract? It will be confusing to see 2 functions that supposedly do more or less the same thing but have different names.
confusing UX and a potential source of problems if you say that "tokens will probably be locked"

@lyricalpolymath
3- New contracts that use new tokens must use send() and not transfer(). transfer() is just for backwards compatibility. mainly old smart contracts, as I expect that UI will be upgraded at some point.
Stay tunned for (1 & 2)

@alexvandesande To know if a contract implements ITokenRecipient, the reverseENS is used (EIP672) which will never throw and you will know if it implements or not the Interface. The gas cost should be the same as the one you propose.

@GoldenDave Others have made the same argument in the past but were unable to provide (IMO) a compelling argument as to why forcing the humanizing divisor to the same for all tokens is bad. The most common cited example is "what if I have a token that is pegged to USD (or similar), which only has 2 decimals?" In this case, you can still have 24 decimals (or whatever the standard defines) exposed to the user and the contract can internally store however it likes. In this case, you would simply multiply whatever internal value you have by 10^22 when it is returning to the user. In all cases I have seen people come up with (including the USD peg) nothing is hurt by having a token be more divisible. There is really nothing fundamentally wrong with having 1 attousd.

@jbaylina I support reverse ENS, but I don't see why not also add this to the contract itself. Is simpler to build, will work on any network, including test networks etc. Also, to check ens resolver you need to have multiple calls (see if there's a resolver, then check the resolver etc) AND to have an extra function on the constructor function to set the ens resolver info.

Again, I'm all for ENS, but why not add on the contract simple info like that? Reminds me of the debate on either tokens should have symbol and names on the contract or on a token registry: in contract won by the simplicity of it.

Also: I'd like to propose to add a provable standard to this token. One of the most requested features I get from token creators is how to send tokens without having ether and I think it makes sense that should be a core function of whatever is the next big token version.

Others have made the same argument in the past but were unable to provide (IMO) a compelling argument as to why forcing the humanizing divisor to the same for all tokens is bad.

During the HelloGold token sale, contributors received HGT which entitled them to a share of a reward token GBT (our gold backed token) which is related to the amount of management fees that we receive for storing clients' gold pro rated to the person's HGT holding.

In order that anybody holding the minimum amount of HGT should receive GBT during a distribution we calculated that GBT would work with 18 decimals but as a result HGT would need to have 8 d.p. Any more precision would be pointless and misleading.

It it rather dictatorial to say that everybody needs to normalise everything to meet a number of decimal points that do not particularly agree with them, especially when we already have a method of handling it.

Should the ITokenRecipient contract also have a function that always returns true stating it's capable of this? It's a way to allow wallet implementers to know which function to use, and therefore save gas.

It is great idea - but when I ran a quick test on remix, a contract with a simple fallback function would falsely satisfy your requirements.

function(){
}

appears to return true when a non existent function xyz() returns (bool) is called.

https://gist.github.com/DaveAppleton/ef44e9745b1f57c7ae0d6744a15bc5c6

@alexvandesande One of the nicest think of this standard is that not only you can have functionality in smart contract recipients, but also in any regular account. You can program for examle that you don't accept tokens sent to your public regular account. Or that you send half of it to a charity.
I agree that using EIP672 is a little complicated, and what's the worst, ENS still is centralised in some way. So that is why we plan to use EIP #820 which is equivalent to EIP672 but much more simpler and pure decentralised contract. (It still is a work in progress).

@alexvandesande Regarding the provable functionality, the idea is to do that via an operator. The operator can, for example, accept signed checks, which they are very much provable transfers.

This standard should allow for token contract creators to set some default operators to be authorised for everybody.

@DaveAppleton I just tested your code and got

{
	"0": "bool: false"
}

So it seems it should work.

I need to understand the value that can be passed in data and operatorData parameters of the Send function in ERC777. Can someone brief me about that with an example. I know that it is bytes datatype. My question is about what should be converted to bytes datatype.

Thanks in advance

This is a finalized EIP. Please open questions like this on Stack Exchange or similar website. You will get great answers there, I promise. You can ping me @fulldecent and I will check it out.

This thread here is for discussing the standard itself and any serious problems with the specification (since it is already final).

Hello. There is a mistake in the description.

In the first paragraph of ERC777TokensRecipient section (https://eips.ethereum.org/EIPS/eip-777#erc777tokensrecipient-and-the-tokensreceived-hook) ERC777TokensRecipient should be used instead of ERC777TokensSender.

@Revinand For non-normative changes (like typo fixes and such) you can just submit a PR against the EIP. Just go to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-777.md and click the little edit pencil at the top right-ish.

@MicahZoltu Ok, sure. My bad

Is ERC777 vulnerable to short address attack? How to avoid it?

@Revinand thanks. I saw the PR. I can't merge it but I hope an EIP editor will do it soon.

@yuwiggin short address attack is more of a vulnerability in Solidity itself. There is not much to be done at the standards level.

If you want to protect yourself against short address attack you can always check for the length of msg.data. Note hover that the send methods have bytes parameters. So you can check a minimum length to avoid the attack on operator, holder address, and the amount.

Latest version of Solidity has built in checks for incorrect calldata size IIRC.

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

EIP-777 specifies:

| The token contract MUST call the tokensToSend hook before updating the state.

This violates Checks-Effects-Interactions, and introduces a very real risk of vulnerability via sender hook, for any contract that implements ERC777.

This should be changed from before to after, so that both sender.tokensToSend and recipient.tokensReceived are called after updating the state.

OpenZeppelin implementers agreed that this was an issue, and they were planning to break with the ERC777 standard to make this change, although the change was not yet made in the OpenZeppelin implementation of ERC777.

OpenZeppelin/openzeppelin-contracts#1749 (comment)

EIP-777 is final, so it cannot be changed. One could propose a new standard that depends on EIP-777 and changes this, but it would have to go through the whole EIP process.

The issue @lukehutch pointed out is quite severe and the spec is lacking any indication of such. OpenZeppelin is now considering deprecating their implementation of ERC777 for the reasons mentioned, which is a decent start, but if the EIP doesn't explicitly warn about this danger, it could continue to be implemented as defined by those who fail to identify this issue independently.

Is this a case for a non-normative clarification-- as defined in EIP-1 (e.g., to add a warning about the dangers here)?

I wouldn't be opposed to the authors adding something to the security considerations section, but the specification itself should not be changed/updated.

@MicahZoltu EIP-1 gives room for EIP errata:

Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.

ERC777 was finalized on 2017-11-20, and as far as I know, Checks-Effects-Interactions wasn't strongly promoted as a way to mitigate the largest class of smart contract attacks until a bit later. (The DAO attack was June 2016, but I don't think there was a consensus on how to mitigate this in Nov 2017?)

Anyway I believe ERC777's violation of Checks-Effects-Interactions could definitely be considered strong grounds for a security errata for EIP777. It seems that that would be much better than deprecating the whole EIP, especially since it is quite popular.

A normative change to the specification would require a new EIP. The technical standard side of things is meant to be immutable, and that immutability gives people guarantees about what they are communicating with. You could have a new EIP that is essentially just EIP-777 but with one minor change if you otherwise like it.

It is also worth noting, there is no deprecation process for standards. People can voluntarily stop using standards, but we don't take any actions to decide which standards people should follow and which they shouldn't. There are many standards in this repository that I personally think are terrible and shouldn't be followed, but my role (and the role of all editors) is not to pass those sorts of judgements.

@MicahZoltu Issuing a security erratum for EIP777 does not constitute a normative change.

People need to be warned that if they implement EIP777 as it is defined, they risk putting their users at risk of a reentrancy attack.

The ERC-777 specification was finalized on 2019-05-07.

b0240fc

The check-effects-interactions best practice was documented in 2016-07-04.

https://github.com/ethereum/solidity/blame/develop/docs/security-considerations.rst

I would not be opposed to adding a Security Considerations section that just comments on the integration risk faced by people who integrate with ERC-777 tokens. I would like to see author approval though as I try to avoid making any changes to final EIPs without author approval other than just typo fixes.

Fulldecent is correct here though, the checks-effect-pattern was known at the time of ERC-777 creation, I think to the authors even.

@lukehutch @MicahZoltu thanks for your messages. I'm personally happy to add a warning about this if there are no oppositions from @tshabs and @jbaylina. I can make a PR this weekend (bit busy ATM) with the message and @MicahZoltu @tshabs @jbaylina can review it.

As a side note, I was personally never a fan of the sender hook, but we had to compromise based on the community requests. I would actually be in favor of a newer simpler ERC-777 standard with a receiver hook only, directly on the receiver contract (bypassing ERC-1820). If anyone is interested with this, let me know.

Hik

Yes yes

I'm personally happy to add a warning about this

Thanks :)

I would actually be in favor of a newer simpler ERC-777 standard with a receiver hook only, directly on the receiver contract (bypassing ERC-1820).

This sounds a lot like ERC4524, if the operator framework of ERC777 was also removed. (The operator system in ERC777 is overly complex and should probably at least be simplified or reworked.) Is what you're envisioning already handled by ERC4524?