ERC777 Token Standard #777
Comments
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 I would find better to stick to the needed stuff, such as:
Can you describe situations where |
@3esmit The For the May be a good alternative would be to integrate this 2 parameters in |
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. |
I propose renaming 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
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
One could use
I find this somewhat confusing and unexpected. We'll have a dichotomy of "ERC20" tokens: ones that will never call the 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. I kind of like and dislike the I guess an alternative could be |
@sohkai: 2.- The idea is that the receiver should have the warranty that the 3.- The big problem of maintaining |
As I have mentioned in other threads, I strongly recommend removing 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:
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 |
I recommend splitting
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:
Anyways, big |
Public state variable for decimal is |
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
|
Great stuff! 1- initially I too thought as @sohkai that I understand and share what you say
But I also think that it's an interesting addition to remind implementers to include optional limitation logic. 2- 3- Backwards Compatibility
I understand that new smart contracts will detect the right function to call (right?) |
@lyricalpolymath |
@alexvandesande To know if a contract implements |
@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 |
@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. |
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. |
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.
appears to return true when a non existent 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. |
@alexvandesande Regarding the 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
So it seems it should work. |
The last call of ERC777 ended yesterday. Therefore I would like to move ERC777 to final. The last call period was extend by a week, for a total of 3 weeks, to deal with last minute feedback. There was no significant and no functional changes but mostly clarifications and corrections.
Details on the changes during the last call period can be checked at #1945. A huge thanks to everyone who provided feedback and supported the development of the standard. @nicksavers , could you please merge #1999 to mark ERC777 as final. Thank you. @frangio That is correct: ERC777's operators and ERC20's You can have a look at the backward compatibility section for further details:
Regarding your second point, the SHOULD is correct. The MUST indicated that the table below it has to be respected. |
@0xjac Thanks a lot for your work on ERC777! |
@guylando Whether you want to use ERC20 or ERC777 is subjective. I believe ERC777 has significant improvements over ERC20, however it is very new and there is almost no support for it yet. I would (obviously) encourage the Ethereum community to start using ERC777 if it matches their use cases but I would also highly recommend to make any ERC777 token compatible with ERC20. I am not yet aware of a token implementing the final version of the specs. I had contacts with people behind the "CALL token", they used a now outdated draft of the standard. They are aware of it and I can only hope they will update their token. I also had contacts with other people interested in making ERC777 tokens and I have a backlog of emails related to ERC777 which I have to go through and answer. edit: I am currently working on the reference implementation and a new version will be released soon |
Hello Jacques, |
Great to see this reach final. I wrote an article explaining some of the features of ERC-777; it's available at https://www.wealdtech.com/articles/understanding-erc777-token-contracts/ and a companion piece focusing on operators is available at https://www.wealdtech.com/articles/understanding-erc777-token-operator-contracts/ |
We've now finished the OpenZeppelin implementation, including ERC20 compatibility by default. It's released now in Also available on npm: We'll be doing a final internal security review in the coming days before the final 2.3 release. An independent security audit has not been done yet. |
@frangio any reason the OpenZeppelin implementation hard-codes granularity to |
@mcdee Good question. The EIP says the following about granularity:
Keeping this in mind, we decided to go with a hardcoded granularity if 1 for our first release of the ERC. It makes the code simpler to understand, and simpler for people to use, which might help adoption. However, it's very easy to add granularity on top as an extension and we plan to do this once we see some demand for it. The same applies to opting out of ERC20 compatibility. It's not possible in this first release but we may add it as a feature down the road. |
@frangio ERC-20 functionality is orthogonal to ERC-777, but granularity is part of the spec. I would urge you to add this before releasing the token. (This is another good example of why SHOULD is a horrible designator in an ERC). |
I posted here some questions on the ERC777 implementation: OpenZeppelin/openzeppelin-contracts#1749 |
Maybe it could be a good idea to somehow contribute to EIP 1155 for it to add built in support to ERC777 like it adds to ERC20 and ERC721: #1155 |
ERC1155 does not have in-built support for ERC20 or ERC721 so it does not need to add in ERC777 as a dependency either. ERC1155 differs to ERC777 in that it supports multiple token types (if needed) and the possibility of mixing of NFT and FT so they are targeting different scenarios imho. |
Even if the idea of ERC1155 is for game items, the implementation has nice things which can contribute to ERC777 and on the other hand ERC777 has nice things which can contribute to ERC1155. If the idea of ERC1155 is to ONLY be an encapsulation of adding the ability to hold multiple tokens then it adding batch functions seems to contradict that as those are an enhancement for the tokens and not just part of the ability to hold multiple tokens. |
erc777 much like erc721 and erc20 does not include the "_id" designation in key functions like balanceOf, so merging them and erc1155 together just isn't going to fit very well. An example is erc777 uses this signature:
and erc1155 uses:
they both can have "operators" that have permission to move tokens from one spot to another but erc1155 has that specific _id param to also say which type this transfer is attempting to move. Now if erc777 could introduce some form of type into that signature and all its others, one or the other standard is potentially redundant. The issue is that erc777 has to have backwards compatibility and is designed to be additive to erc20, so I can't see this happening personally but I suppose it is possible. What is possible also is that the receiver signatures are unified if erc777 was to add in an "_id" param and erc1155 was to add in the "_operatorData" param, but if you are proposing that the receivers are merged (without the entire standards being merged) then there has to be a way to also know "this is an ERC-X token you are receiving" which also necessitates a param to make this a generic solution like a data param that accepts keccak256("ERC1155") and keccak256("ERC777") perhaps so that it may act accordingly based on the type it is receiving (for eg. a contract may be an erc1155 receiver only that may only want to allow acceptance of _id==0x123). It all sounds a little cumbersome/wasteful in usage, and in the logistics of getting two standards over the finish line; Arguably for little benefit when they are seemingly standards designed for different motivations and use cases. I mean sure, a generic smart wallet that wants to be able to hold and send every standard out there may now have to have two receiver function sets implemented, but even if the receivers are unified they would still have to potentially branch in the logic on the receiver function for the erc type and definitely do on the dapp side with the knowledge the source contract for the send is an impl of a particular standard, so it doesn't really save anything. With respect, instead of coming onto both standards pages and asking us to change things right at the last minute of both the standards being final after months of discussions, if you could propose an actual working solution in a fork that covers both our problem domains I think it would be far more productive. Otherwise I imagine we will both go final fairly soon. edit: I see after looking through the comments 777 is already final as of a few days ago. Congrats! |
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 |
@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 |
Latest version of Solidity has built in checks for incorrect calldata size IIRC. |
Please, see https://eips.ethereum.org/EIPS/eip-777 for further discussion.
The text was updated successfully, but these errors were encountered: