7 min read - Posted 20 Oct 19

ERC-20 and Its Discontents: The Rise of Comrades ERC-777 & ERC-1820

ERC-20 and Its Discontents: The Rise of Comrades ERC-777 & ERC-1820

The most well-known Ethereum Request for Comment (ERC) is the ERC-20, which enabled the growth of Decentralized Apps (dApps), tokens, and token standards that serve the blockchain community as the blueprint for creating tokens.

One of the most significant promises of Ethereum is to remove intermediaries, in essence, our ability to directly interact with one another without a central authority, which is a principle built into ERC-20. However, this ability doesn't come without fallibility, ones that we didn't foresee as clearly as we do today – namely that not all contracts can accept all ERC-20 tokens, resulting in a substantial number of tokens lost, forever.

Under ERC-20, we can send tokens to any Ethereum address, which means we can also send them to contracts that do not support them or do not have private keys, locking, and losing them forever. According to some estimates, there are tens of millions of dollars' worth of lost tokens. With the rise of non-fungible tokens (NFTs), we can ideally purchase an NFT with one transaction, which wasn't possible until now. Previously, to buy an NFT, we'd have to complete two transactions. One to change the balance on the ledger and a second one to transfer it to the smart contract.

  1. approve() – on your coin.
  2. transfer() – on the contract side.

Thanks to recent efforts, it's now possible to purchase an NFT within a single transaction.

The Efforts of ERC-223

ERC-223 has all the features of ERC-20, but it also checks to see if the smart contract can accept tokens. The ERC-223 receiver can call a function, so it can also be used for purchasing NFTs.

Under ERC-223, for a contract to be able to receive tokens, it has to implement the ERC-223 receiver interface. However, it still isn't as complete as ERC-777, which is built with the goal of backward compatibility with ERC-20; solving its main hurdles and avoiding the weaknesses of EIP-223.

The Introduction of ERC-777

ERC-777 is a substantial evolution over ERC-20. More than just sending tokens, ERC-777 defines the lifecycle of a token, starting with the minting process, followed by the sending process, and ending with the burn process. It allows for the management of funds by others, called "operators".

From transfer (to, amount) to send (to, amount, data)

EIP-777 does not use transfer and transferFrom functions, instead, it uses send and operatorSend to avoid interface confusion. Similar to the notes field when completing a bank transfer, the "data" in an ERC-777 token transfer can be full or empty. The tokensReceived hook allows for both sending and notifying a contract in a single transaction. Whereas ERC-20 required a double call (approve/transferFrom) to achieve this.

From Approve to Operators

Another difference in the Solidity contract of ERC-777 is the use of the operators function instead of approve(). ERC-777 allows holders of an address to authorize others to send and burn tokens on their behalf. Furthermore, token holders are notified when their address is used.


ERC-1820 is a registry for checking which address supports which interface. Unlike ERC-777, ERC-1820 is not a token standard; it is a standard for a registry.

While there might be disadvantages to relying on a separate standard, ERC-1820 offers benefits that are important to acknowledge. For example, it allows ERC-777 to remain relatively simple, without the added overcomplication of adding a registry to it. Perhaps more importantly, it allows other EIPs and smart contract infrastructures to take advantage of the registry for their use cases.

The authors of the protocol had a choice between either making the protocol more complex or creating a separate protocol, which would result in a dependency issue; the parity hack is an obvious example of what problems such dependencies can create.

The ERC-777 Code and Explanation

The code below is a basic example of an ERC-777 contract, from

interface ERC777Token {
    function name() external view returns (string memory);
    function symbol() external view returns (string memory);
    function totalSupply() external view returns (uint256);
    function balanceOf(address holder) external view returns (uint256);
    function granularity() external view returns (uint256);

    function defaultOperators() external view returns (address[] memory);
    function isOperatorFor(
        address operator,
        address holder
    ) external view returns (bool);
    function authorizeOperator(address operator) external;
    function revokeOperator(address operator) external;

    function send(address to, uint256 amount, bytes calldata data) external;
    function operatorSend(
        address from,
        address to,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external;

    function burn(uint256 amount, bytes calldata data) external;
    function operatorBurn(
        address from,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external;

    event Sent(
        address indexed operator,
        address indexed from,
        address indexed to,
        uint256 amount,
        bytes data,
        bytes operatorData
    event Minted(
        address indexed operator,
        address indexed to,
        uint256 amount,
        bytes data,
        bytes operatorData
    event Burned(
        address indexed operator,
        address indexed from,
        uint256 amount,
        bytes data,
        bytes operatorData
    event AuthorizedOperator(
        address indexed operator,
        address indexed holder
    event RevokedOperator(address indexed operator, address indexed holder);

ERC-777 defines the entire lifecycle of a token, including the minting (4), sending (3), and burning (5) of tokens. Below are the functions and events of the protocol. For more detail, read the official EIP-777 Github page.

View Functions
  • name
  • symbol
  • totalSupply
  • balanceOf
  • granularity
  • AuthorizedOperator event
  • RevokedOperator event
  • defaultOperator function
  • authorizeOperator function
  • revokeOperator function
  • isOperatorFor function
Sending Tokens
  • Sent event
  • Send function
  • operatorSend function
Minting Tokens
  • Minted event
Burning Tokens
  • Burned event
  • burn function
  • operatorBurn function

Further Reading

Created with Sketch.Content is"CC-BY-SA 4.0" licensed
Article On-chain
Article Author

Shayan Shokrgozar





Related Articles
ERC-20 Token Standard

Simple Summary A standard interface for tokens. Abstract The following standard allows for the implementation of a standard API for tokens within smart contracts. This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party. Motivation A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges. Specification Token Methods NOTES: - The

Kauri Team

16 Apr 19

Gamifying Crypto Assets with the ERC998 Composables Token Standard

Assets can be complex. Take a house, for example; youre not just selling the ownership of the land it sits on, but also the physical attributes of the building - the foundation, the wood, the interior walls, the roof, the stairs. Sometimes, if youre selling a fully furnished house, that asset will also include expensive furniture pieces such as couches, dining tables, bed frames and more. When it comes to crypto, attributing an ERC721 token to any non-fungible asset doesnt give you the space to

Ramy Zhang

08 Aug 19