Ethereum Watch

Move over, ERC20, and make way for ERC777. The new token standard created by Jordi Baylina, Jacques Dafflon, and Thomas Shababi will be finalized soon.

The EIP for ERC777 was posted November 20, 2017, and has been open for community feedback and criticism ever since. Last week, Baylina and Dafflon gave talks about the new token at DappCon, wherein they gave a clear, mostly public-facing explanation of the merits and functionality of the standard. At the end of his talk, Baylina stated that the token standard would soon enter the last call stage of development, and that he expected it to be finalized sometime in August. Though, this is of course pending community will. Once the ERC777 standard is finalized, he said, it will be up to developers to implement it as they see fit.

The developers advertise the ERC777 standard as more customizable than ERC20, and say it allows for faster, smoother transactions. It is also apparently backward compatible with ERC20, which may encourage developers to widely adopt it. While there has been no shortage of token standards, this one appears to have significant community support.

If you’d like to check out the code for yourself, it is open source and available on GitHub. For those of you who aren’t developers and didn’t get the chance to see Baylina and Dafflon talk at Dappcon, here’s a rundown of what to expect from the new token standard.

More Intuitive Interaction with Contracts

The ERC777 Ethereum improvement proposal (EIP) explains how ERC777 tokens will employ a “send” function (similar to how Ether operates), which allows for direct transactions and exchanges with EDCCs (or smart contracts). This varies from ERC20 tokens, which only allow for a “transfer” function and require two transactions to exchange one token for another (a function executed through an EDCC). The first transaction, under the ERC20 standard, is a request for approval. The second call allows a token contract to make a transaction on your behalf.

Under the ERC777 standard, things work differently. With the “send” function, ERC777-based tokens will call on a universal ownerless trusted contract, the ERC820, which is basically a registry that will tell the token whether the contract it is attempting to interact with is compatible. If it is an incompatible contract or the contract is not registered, the transaction will get thrown. In that case, the token sender can fall back on the ERC20 transfer function and request acceptance. However, a contract or address only needs to register with the ERC820 contract once – it can be registered by anyone and then that information will be available to everyone.

Besides being designed to streamline transactions, this “send” function should allow ERC20 token holders to transfer tokens to smart contracts without first sending a request for approval.

What’s the Hook?

Another advantage ERC777 purportedly has over ERC20 is that the new standard will allow “hooks.” Baylina explained in his DappCon talk that “hooks are functions that can be called during a transfer.” In other words, a hook specifies the parameters of a transaction. Among other things, it can require notifications to be sent to senders or recipients before or after a transaction is complete.

More than simply allowing for notifications, an ERC777 token’s contract can be written to control the behavior of a token in a particular transaction circumstance, or to allow the sender or recipient to intervene in the transaction. For example, a hook can be written to notify a sender before a transaction is sent, allowing the sender to cancel the transaction. Similarly, the token contract can be written to block certain addresses or types of tokens.

Hooks can also specify that received tokens are to be dealt with in a particular way: the example Baylina gave was that a contract could specify a percentage of each transaction to be allocated to a charitable cause.

These hooks are reliant upon the ERC820 registry mentioned earlier. For example, if a token contract is designed to refuse tokens with a particular function, the token contract will call upon the ERC820 to assess whether the token being received possesses that function. If the incoming token is not listed on the registry, then the transaction will be thrown. In that case, the token sender will have to transfer the token using the ERC20 two-transaction model. In this way, the ERC777 has all of the functionality of the ERC20, so even if it is not yet (or never is) widely adopted, it will still be fully functional. Because of this backward compatibility, it seems relatively risk-free for a developer to choose this new token standard over the old one.

Smooth Operators

Another significant difference between the ERC20 and the ERC777 token standards is that the ERC777 allows for the use of operators. As explained in the EIP, “an operator is an address which is allowed to send and burn tokens on behalf of another address.” An operator can be set by the token holder, and can be either a contract or a regular address. Before anyone loses their marbles about the security risks this may pose, it is important to note that token holders can always disable an operator at any time.

This would allow for a number of different functions, including automatic payments to an EDCC or a trusted address. For example, Baylina stated that you could set up a sort of “bill pay” feature for a subscription, or you could transfer tokens from your cold wallet to a hot wallet. Again, the standard allows for token holders to disable an operator at any time.

The token standard also allows for what are called “default operators.” A default operator is defined in the EIP as “an operator which is implicitly authorized for all token holders.” One could imagine, though it is not explicitly stated, that this function could be used by charitable organizations or financial service providers to help distribute token holders’ assets: for example, a Dapp’s EDCC could be written so that certain transactions by token holders trigger a donation.

An example Baylina gave was a default operator could extract gas costs automatically, easing transactions for the sender. While the default operators are set at the time of creation, a token holder can revoke authorization of default operators at any time. However, it is unclear to what extent the novice token holder would be aware of the existence or function of a given default operator, which could certainly pose some security and ethical concerns. 

Alison is an editor and occasional writer for ETHNews. She has a Master’s in English from the University of Wyoming. She lives in Reno with her spouse and growing animal family. Her favorite things to do include binge listening to podcasts, getting her chuckles via dog memes, and spending as much time outside as possible.

ETHNews is committed to its Editorial Policy

Like what you read? Follow us on Twitter @ETHNews_ to receive the latest Ethereum, Ether or other Ethereum ecosystem news.