ERC(Ethereum Request for Comments)-777
A New Advanced #Token Standard was introduced to establish an evolved Token standard which learned from misconceptions like approve() with a value and the aforementioned send-tokens-to-contract-issue.
Additionally, the #ERC-777 uses the new standard #ERC-820: Pseudo-introspection using a registry contract which allows for registering meta-data for contracts to provide a simple type of introspection. This allows for backwards compatibility and other functionality extensions, depending on the ITokenRecipient returned by a EIP-820 lookup on the to address, and the functions implemented by the target contract.
ERC-777 adds a lot of learnings from using ERC-20 Tokens, eg. white-listed operators, providing Ether-compliant interfaces with send(…), using the ERC-820 to override and adapt functionality for backwards compatibility.
This standard tries to improve the widely used #ERC-20 token standard. The main advantages of this standard are:
Uses the same philosophy as Ether in that tokens are sent with send(dest, value, data).
A tokensReceived can be defined in any contract and in any regular address in a way that this code is triggered when tokens are received. This avoids the double call needed in the ERC-20 standard.
Both contracts and regular address can control and reject which token they send by registering a tokensToSend function which throws block the send.
Both contracts and regular addresses can control and reject which tokens they receive by registering a tokensReceivedfunction which throws to refuse the reception of tokens.
The token holder can “authorize” and “revoke” operators who can manage their tokens. These operators generally are going to be verified contracts like an exchange, a cheque processor or an automatic charging system.
Every token transaction contains a userData bytes field and a similar operatorData -- in case of an operator transaction -- to be used freely by the user (sender) and the operator respectively to pass data to the recipient.
It can be used in a backwards compatible way with wallets that do not contain the tokensReceived function.
Specification
ERC-777 Token (Token Contract)
interface ERC777Token {
function name() public constant returns (string);
function symbol() public constant returns (string);
function totalSupply() public constant returns (uint256);
function granularity() public constant returns (uint256);
function balanceOf(address owner) public constant returns (uint256);
// transfer is modified to send in ERC-777
function send(address to, uint256 amount) public;
function send(address to, uint256 amount, bytes userData) public;
function authorizeOperator(address operator) public;
function revokeOperator(address operator) public;
function isOperatorFor(address operator, address tokenHolder) public constant returns (bool);
function operatorSend(address from, address to, uint256 amount, bytes userData, bytes operatorData) public;
event Sent(
address indexed operator,
address indexed from,
address indexed to,
uint256 amount,
bytes userData,
bytes operatorData
);
event Minted(address indexed operator, address indexed to, uint256 amount, bytes operatorData);
event Burned(address indexed operator, address indexed from, uint256 amount, bytes userData, bytes operatorData);
event AuthorizedOperator(address indexed operator, address indexed tokenHolder);
event RevokedOperator(address indexed operator, address indexed tokenHolder);
}
The token-contract MUST register the ERC777Token interface via ERC-820.
The basic unit token MUST be 10¹⁸
Logo
The logo is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License with the added restriction that the logo MUST NOT be used to advertise, promote or associate in any way technology — such as tokens — which is not ERC-777 compliant.
Rationale
This standard solves some of the problems of the EIP-223 and goes an step further by allowing operators (generally contracts) that can manage the tokens in the same way that the ERC-20 with infinite approve was allowed.
Also the usage of ERC-820 allows backwards compatibility with wallets and proxy contracts without having to be redeployed.
Backwards Compatibility (ERC-20 Token)
This EIP does not introduce backward incompatibilities and is compatible with the older ERC-20 token standard.
This EIP does not uses transfer and transferFrom and uses send and operatorSend to avoid mistakes in knowing which interface you are using.
This standard allows the implementation of ERC-20 functions transfer, transferFrom, approve and allowance to make a token compatible with ERC-20.
The token can implement decimals() for backwards compatibility. If implemented, it MUST always return 18.
Therefore a token contract can implement both ERC-20 and ERC-777 in parallel. Read-only functions (such as name, symbol, balanceOf, totalSupply) and internal data (such as the mapping of balances) overlap without problem. Note however that the following functions are mandatory in ERC-777 and MUST be implemented: name, symbol. (decimal is not part of the ERC-777 standard.)
The write methods from both standards are decoupled and can operate independently from each other. Note that ERC-20 functions SHOULD be limited to only being called from old contracts.
If the token-contract implements ERC-20, it MUST be register the ERC20Token interface via ERC-820. If the contract has a switch to enable or disable ERC-20 methods, every time the switch is triggered, the token contract MUST register or unregister accordingly the ERC20Token interface via ERC-820.
The only difference for new contracts implementing ERC-20 is that registration of ERC777TokensSender and ERC777TokensRecipient via ERC-820 takes precedence over ERC-20. This means that even with on a ERC-20 transfer call, the token contract MUST check via ERC-820 if the from/to address implements tokensToSend/tokensReceived and call it if available. Note that when calling ERC-20 transfer on a contract, if the contract does not implement tokensReceived, the transfer call SHOULD still be accepted even if this means the tokens will probably be locked.
The table below summarize the different actions the token contract must take when sending, minting and transferring token via ERC-777 and ERC-20:
There is no particular action to take if tokensToSend is not implemented. The transfer MUST proceed and be cancelled only if another condition is not respected such as lack of funds or a throw in the tokensReceived.
PROS:
Well thought and evolved interface for tokens, learning from ERC-20 usage
Uses the new standard request ERC-820 for introspection, allowing for added functionality
White-listed operators are very useful and are more necessary than approve/allowance, which was often left infinite
CONS:
Is just starting, complex construction with dependent contract calls
Dependencies raise the probability of security issues: first security issues have been identified (and solved) not in the ERC-777, but in the even newer ERC-820
Problems with the ERC20 Token:
How to transfer tokens to contracts?
We can send tokens to any Ethereum Address, which means we can also send them to contracts which do not support them, locking them forever.
Worse than that: even if the tokens can be manually moved, it’s very hard to tell which tokens came from who, and try sending them back.
Solution: ERC20 used to have a “approve” function that would allow you to approve the transfer to a contract and a second transaction is created to let the contract know that it has been approved.
ERC777 allows off-chain signing to transfer without needing ether, or private transfers that use zksnarks or ring signatures to add privacy to tokens.
Features of ERC777:
Sets decimal to default 18
Adds approved operators
References:
Github EIP Issues 777: https://github.com/ethereum/EIPs/issues/777
Github official repository for this standard: https://github.com/jacquesd/ERC777