A New Advanced Token Standard

[jbaylina]

Please, see https://eips.ethereum.org/EIPS/eip-777 for further discussion.

---

[tjayrush]

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.

[3esmit]

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?

[jbaylina]

@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...

[3esmit]

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

[jbaylina]

@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.

[izqui]

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!

[onbjerg]

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 😊

[jbaylina]

@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).

[sohkai]

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().

[jbaylina]

@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.

[MicahZoltu]

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".

[MicahZoltu]

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?

[MicahZoltu]

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.

[bwheeler96]

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.

[nepalbitcoin]

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.

[GoldenDave]

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.

[alexvandesande]

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};

[lyricalpolymath]

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"

[jbaylina]

@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)

[jbaylina]

@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.

[MicahZoltu]

@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.

[alexvandesande]

@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.

[DaveAppleton]

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.

[DaveAppleton]

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

[jbaylina]

@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).

[jbaylina]

@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.

[alexvandesande]

@DaveAppleton I just tested your code and got

{
	"0": "bool: false"
}

So it seems it should work.

[mcdee]

@lrgeoemtry the issue is with whatever code is attempting to construct the token rather than the token code itself; the solidity code is fine. If you send me a link to your github repository with the tests/depoyment code I can take a look to see where the problem is (but this isn't really the place to discuss the issue so please use gitter or similar to discuss further)

[lrgeoemtry]

ill email you at your Jim@mcdee.net. thanks @mcdee :)

[catageek]

There is a security issue with this contract. This contract does not protect against reentrancy regarding tokensSend() and tokensReceived().

Let say a malicious contract implements tokensSend() and calls back the token contract using delegatecall. The resulting call will have address(this) as msg.sender and will act on behalf on the contract itself.
So the malicious user can add or remove operators for the contract token account, send tokens on behalf of the token contract, or operates on any account for which the token contract is an operator.

The simplest fix would be to forbid address(this) to be an operator, even for itself, so prevent the insertion of address(this) in defaultOperators in constructor and in authorizeOperator()

[mcdee]

@catageek the address holder would need to set the malicious contract themselves, so there is a level of protection there. Also, if the malicious tokensToSend()/tokensReceived() uses delegatecall won't it retain the storage of the calling contract and hence not be able to carry out the actions you are suggesting?

If you could put together a proof of concept malicious tokensReceived() this could be looked at in more detail.

[catageek]

@mcdee You're right, I missed the point that the token contract storage would not be accessible in a delegate call. Thanks.

[lrgeoemtry]

are there any successful deployments of 777 ?
https://gcalliance.io/ these guys are pretending to be but there's 55 static warnings on their code on etherscan and its deprecated.
I can successfully deploy to roosten, but then transactions start to fail.
I'm at wits end,
I know @mcdee told me to just deploy a 20 but I feel like I'll be giving up a lot of potential with this.

currently Rinkeby won't deploy and the main net is certainly not going to take this.
https://gist.github.com/lrgeoemtry/f32c615a1e39474bb3f906bdcd52707a
the code I'm attempting to deploy

HALP q_q

[lrgeoemtry]

I'm deploying an ERC20 and putting this to rest until you wizards can solidify this standard
thank you @mcdee for the help and advisement to do this as I was at wits end trying to make 777 work

[irdd]

@lrgeoemtry
Please before you try to discredit something do the proper homework. Your code is not working not because ERC777 is fault but rather because you did not understand how this standard works.
The Call token code is already deployed in the mainnet and working properly also the codebase has been through a code “audit” with non-alarming results. As of the errors, there are no errors during the compilation of the code nor the deployment if you take into account the proper parameter tweaking based on the target ethereum network.

[bluerosss]

@lrgeoemtry : CALL token from GCAlliance works perfectly

[mcdee]

@irdd @bluerosss I would suggest that the issue around implementing ERC777 at the moment is that it has not been finalised. Perhaps more importantly, ERC820 has not been finalised and due to its deployment method any changes to that codebase will result in a different contract address. It is, of course, up to each party to decide if they want to deploy at this time but personally I'd be wary until at least ERC820 is locked down.

(And @jbaylina @jacquesd if you're at Devcon it would be good to discuss my proposed tweak to ERC777 so that I can answer any questions you have about it).

[irdd]

@mcdee
We will update (644 ftw) our token contract with the final erc820 address when it’s deployed/finalized.

[AdrianClv]

@lrgeoemtry We have an erc777 deployed on Kovan and it works fine. It will also be on Mainnet soon.

[chompomonim]

@lrgeoemtry We have an erc777 deployed on Kovan and it works fine. It will also be on Mainnet soon.

There is recommendation to not deploy into mainnet until ERC820 will be finalised. ERC777 is closely coupled with ERC820, and official address of ERC820 will be changes after it will be finalised.

[catageek]

Hi, it's me again. I think there is a possibility of a front run attack that should be documented or fixed.

Here is how I think the attack could be performed : An operator authorized for a token holder can watch the transactions from this token holder, and if they see a revokeOperator() transaction that remove their rights, they send a transaction executing operatorSend() to withdraw an amount of tokens from the token holder's balance, with a high gas price to be executed before the token holder transaction.

One can argue that the token holder can implement tokensToSend() interface and revert when the transaction is sent by the operator that has to be revoked, but again the operator can watch the implementer contract transactions, detect that a change will make its own transactions reverted and can act as described above.

I think this attack is plausible if an operator becomes malicious and a token holder wants to remove their operator rights but get their balance emptied as a punishment.

So there should be a way for any token holder to remove any operator in a way that prevent the operator to punish the token holder, but I am not sure it should be considered in this standard or if it's the token holder responsibility.

At least it should be documented that the token holder may be punished by an operator if it revokes it before making tokensToSend() revert, and that a front run attack protection must be implemented on the tokensToSend() function.

What is your opinion about it ?

[mcdee]

@catageek your attack is predicated on the idea that the operator has been authorised. It is incumbent on the token holder to consider the ramifications of authorising an operator. Note that most operators will be either pseudonyms of the holding address (i.e. another address that is controlled by the same entity) or a smart contract with well-defined functionality, so the chance of an operator "becoming malicious" is 0.

[lsaether]

Heads up -- it looks like Vyper reserves send as a keyword for its built-in function to send ether. This means that under the current specification, ERC777 would not be possible to implement in Vyper. Thoughts?

[jacquesd]

@lsaether Thanks for your comment I'll definitely look into it. We already removed function overloading to make it compatible with Vyper and we don't want ERC777 to be Solidity only.

[mudgen]

What do you think about using the ERC1538 contract architecture to implement ERC777 tokens?

[MicahZoltu]

I feel like Vyper, which came second, should stop using incredibly common words as reserved words. I argue that we should pressure Vyper to choose better reserved words that aren't incredibly common in this space (like send).

[mcdee]

@lsaether @jbaylina @MicahZoltu looking at the Vyper docs it appears that sending Ether uses a keyword style send <address> whereas contract methods use an object style <contract>.<method>(), in which case I would hope that send would be considered a valid method. There doesn't appear to be an clash here, although admittedly i haven't tried it.

[lsaether]

@mcdee Should have mentioned before that I have tried it since I was trying out to implement ERC777 in Vyper. The vyper compiler will not allow a function to be defined within a contract that is named send and throws the following error:

vyper.exceptions.FunctionDeclarationException: Function name invalid: send

I'll go ahead and open an issue on the Vyper repository as well so that they are aware of the issue and hopefully a simple resolution can be found!

[wighawag]

Why not name-spacing all function and event names (except for erc20 compatibility) ?

I created an ERC to start a discussion on a possible implementation. (see #1407 )

We could for example prefix functions and event name with erc777_

When #1407 get accepted and implemented in smart contract language via namespace directive (a la c++ for example) we would be able to use simpler names if desired.

As more standard comes into being the chance of having a use case for implementing 2 incompatible standard in one smart contract increase. Namespacing ensure your standard will be compatible with such use cases.

This would also allow smart contract language to freely reserve name for their built-in function

[wighawag]

Hi,

I have reviewed the current reference implementation and I have few comments:

The reference implementation have a way to disable ERC20 interface

While I understand the idea of disabling ERC20 interface to block the use of transfer to protect users of potential token loss. it also brings a potential issue:
Let say there is an ERC777 Token
Imagine a user approve some of these tokens to some entity X (via ERC20 approve)
The owner of ERC777 could disable ERC20 to make X unable to use the user's tokens. This could cause issues with the user who was expecting a service to be given based on a subscription mechanism for example.

This might be fixable though as we could add some functionality in the reference implementation to allow X to keep using its allowance until it depletes (and still allow the user to revoke such allowance) even when ERC20 interface is disabled.

Though I am not sure the complexity is worth the benefit.

Is the ability to disable ERC20 interface that important? If we assume applications start using ERC777, they would simply stop using the ERC20 interface, no ? In that case there would be no need to provide a mechanism to disable the ERC20 interface..

It also has way to re-enable ERC20 interface

While this could be possible the current reference implementation cannot comply with ERC20 as it does not trigger the Transfer event when the erc20 interface is diabled.

ERC20 standard specify that the transfer function Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.
It is not important here as such transfer function would not be accessible but the standard also specify that Transfer event MUST trigger when tokens are transferred, including zero value transfers.

As such as soon as some transfers happen while the erc20 interface is disabled, it is not possible to enabled it again and claim it is a valid ERC20 token since some Transfer event would be missing.

For that to be the case, the reference implementation would need to keep triggering the Transfer event (even when erc20 interface is disabled)

But it might be simpler to simply prevent the smart contract to be ERC20 compatible ever again ?

[mcdee]

@jacquesd why does the reference implementation have the ERC-20 functionality in it? There used to be a standalone ERC-777 token; surely it makes more sense for that to be the reference implementation.

(I understand why someone might want a token contract with functions from both ERCs in it, but I don't think that the reference implementation is the place to put it).

[ssteiger]

Missing word in section 'Rationale': `Note that, the usage of ERC820 provides backward compatibility with wallets and existing contracts without having to be redeployed thanks to proxy contracts implementing the hooks.'