Ethereum ERC Standards You Should Know AboutSunday, 14 April 2019 · 51 min read · ethereum
The ERC20 token standard has achieved near-complete industry adoption. It defined six minimal requirements for the way tokens behave on the Ethereum blockchain. Anyone could comply with the token standard and implement additional functions as needed. This standard ignited the ICO wave, allowing for the creation of core infrastructure and exchanges that is the backbone of the crypto ecosystem today.
Let’s look at Ethereum ERC standards you should know about - including some you’ve never seen before!
📬 Get updates straight to your inbox.
Subscribe to my newsletter so you don't miss new content.
What’s an ERC?
An ERC (Ethereum Request for Comment) decribes application-level blueprints and conventions in the Ethereum ecosystem. This includes smart contract standards such as token standards (ERC20) and are usually accompanied by a reference implementation. The ERC authors are responsible for building consensus within the Ethereum community for it to be accepted. Once peer reviewed and vetted by the developer community, the proposal becomes a standard.
You can see a list of recent ERCs here. In the following sections, we’ll examine several categories of ERCs: Token Standards, Pseudo-Introspection, Decentralized Identity, Recurring Payments, and Meta Transactions.
ERC20 Token Standard
The ERC20 token standard is a set of functions that an Ethereum-based token has to implement. The majority of tokens on exchanges are ERC20 tokens. ERC20 tokens implement the following interface:
The functions are:
totalSupply: Returns the total circulating amount of tokens.
balanceOf: Returns how many tokens exist in an account.
transfer: Transfer an amount of tokens from token owner’s account to another account.
approve: A token owner can approve for
transferFromtokens from the token owner’s account.
allowance: Returns the amount of tokens approved by the owner that can transferred to the spender’s account.
transferFrom: Allows a spender account to transfer an amount of tokens on behalf of the token owner to another account.
ERC20 remains the most widely adopted standard in the Ethereum ecosystem.
Solidity smart contracts can listen to and react to Ether transfers using the
payable fallback function like so:
However, you can’t do the same for ERC20 tokens. A major limitation of the ERC20 token standard is the lack of a way to ‘react’ to ERC20 transfer events. This results in ERC20 tokens forever trapped in contracts when users accidentally sent tokens to the wrong address.
ERC223 is a superset of the ERC20 token standard. It allows the use of tokens as first class value transfer assets in smart contract development by extending the token
transfer function to check the destination address explicitly accepts tokens:
ERC223 disallows token transfers to contracts that don’t support token receiving and handling. It requires contracts to implement the ERC223Receiver interface in order to receive tokens. If a user tries to send ERC223 tokens to a non-receiver contract the function will throw in the same way that it would if you sent Ether to a contract without the called function being
In the above snippet, functions have a
tokenPayable modifier and inside the functions you have access to the
tkn struct that tries to mimic the
msg struct used for ether calls.
ERC721 Non-Fungible Token Standard
ERC20 tokens are fungible, meaning that a balance of tokens in one account and tokens in another are interchangeable. Every ERC20 token is the same as every other ERC20 token.
In contrast, Non-fungible tokens (NFT) are all unique, a property used to create scarce digital assets called cryptocollectibles. You can think of ERC20 as the token type for things that are currency (paper bills) and ERC721 as the token type for collectibles (Pokemon cards, beanie babies.)
Cryptokitties is the most well-known example of an ERC721 token. CryptoKitties are unique collectible digital artworks of cats. You can own and breed the cats to create new CryptoKitties.
The ERC721 token standard defines a minimum interface a smart contract must implement to allow cryptocollectibles to be managed, owned, and traded. An ERC721 token implements the following interface:
Users buy, sell, and discover cryptocollectibles on marketplaces that build on the ERC721 standard.
ERC777 Token Standard
ERC777 is a new token standard that aims to address the limitations of ERC20, while remaining backwards compatible. It defines advanced features to interact with tokens. Namely, operators to send tokens on behalf of another address and send/receive hooks to offer token holders more control over their tokens.
It takes advantage of ERC1820 to find out whether and where to notify contracts and regular addresses when they receive tokens as well as to allow compatibility with already-deployed contracts.
Features that sets ERC777 apart include:
- Both contracts and regular addresses can control and reject which token they send by registering a
- Both contracts and regular addresses can control and reject which token they receive by registering a
- The tokensReceived hook allows to send tokens to a contract and notify it in a single transaction, unlike ERC20 which require a double call (
transferFrom) to achieve this.
- The token holder can “authorize” and “revoke” operators which can send tokens on their behalf. These operators are intended to be verified contracts such as an exchange, a cheque processor or an automatic charging system.
- Every token transaction contains
operatorDatabytes fields to be used freely to pass data from the token holder and the operator, respectively.
ERC1155 Multi Token Standard
Tokens standards like ERC20 and ERC721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by separating each token contract into its own permissioned address. With the rise of blockchain games that uses NFTs as in-game items, the explosion of contracts would introduce performance and cost problems.
ERC1155 is a standard for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations.
With ERC1155, you can transfer multiple token types at once, saving on transaction costs. Trading of multiple tokens can be built on top of this standard and it removes the need to
approve individual token contracts separately. It’s also easy to describe and mix multiple fungible or non-fungible token types in a single contract.
Security Token Standards
Security tokens are cryptographic tokens that represent fractional ownership in an entity, pay dividends, and share profits to its token holders. On the Ethereum blockchain, several competing standards such as ERC1400 and R-Token are in development.
Learn more about the latest security token standards here.
This section highlights different approaches to define pseudo-introspection in Ethereum.
ERC165 Standard Interface Detection
It’s sometimes useful to query whether a contract supports an interface in order to adapt the way in which the contract is to be interacted with. ERC165 standardizes the concept and identification of contract interfaces.
According to this standard, an interface is a set of function selectors as defined by the Ethereum ABI. The interface identifier is the XOR of all function selectors in the interface. This code snippet shows how to calculate the interface identifier:
A contract that is compliant with ERC-165 implements the following interface:
Therefore the implementing contract will have a supportsInterface function that returns:
truefor any other
interfaceIDthis contract implements (e.g. Solidity101)
falsefor any other
ERC1820 Pseudo-introspection Registry Contract
The ERC1820 standard defines a universal registry smart contract where any address can register which interface it supports and which smart contract is responsible for its implementation. Anyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation.
Similar to ERC165, in ERC1820, ‘implementation’ contracts must implement the following interface:
Implementation addresses are then stored in a registry contract:
You can then query the registry to check if a given contract address implements an interface with
In this section, we’ll look at standards surrounding decentralized identity management.
Attestations are the backbone of trust and reputation in a decentralized identity system. In the real world, we attest our identity with documents like an identity card or passport. These documents, issued by a trusted authority, assert facts about us such as our name, age, address, and more. Identity cards don’t exist on the blockchain. Instead, we need a way to link real-world information to cryptographic addresses.
Some of the projects working on this space include uPort, Origin, Bloom, and Civic.
ERC725 Proxy Account & ERC735 Claim Holder
ERC725 is a proposed standard for blockchain-based identity on the Ethereum blockchain. It describes proxy smart contracts that can be controlled by multiple keys and other smart contracts. ERC735 is an associated standard to add and remove claims to an ERC725 identity smart contract. These identity smart contracts can describe humans, groups, objects, and machines.
The ERC725 standard allows for self-sovereign identity. An open, portable standard for identities enabless decentralized reputation, governance, and more without ceding ownership of identity to centralized organizations. Users will be able to take their identity across different dApps that support the standard.
The ERC725 proxy has 2 abilities:
- It can execute arbitrary contract calls, and
- It can hold arbitrary data through a generic key/value store. One of these keys should hold the owner of the contract. The owner may be an address or a key manager contract for more complex management logic.
The purpose of an identity proxy is to allow an entity to exist as a first-class citizen in Ethereum, with the ability to execute arbitrary contract calls. It further allows any information to be attached to that proxy.
ERC735 describes standard functions for adding, removing and holding of claims on identity proxies. These claims can be attested from third parties (trusted issuers) or self attested. Trusted third parties can make claims about a particular identity, such as their name and address. dApps and smart contracts can then query an ERC735 registry to check the claims about a claim holder.
ERC1056 Lightweight Identity
ERC1056 describes a standard for creating and updating identities with a limited use of blockchain resources. It specifies a contract called
EthereumDIDRegistry that is deployed once and can then be commonly used by everyone. The standard is DID compliant.
An ERC1056 identity can have an unlimited number of delegates (an address that is delegated for a specific time to perform some sort of function on behalf of an identity) and attributes (a piece of data associated with the identity) associated with it. Identity creation is as simple as creating a regular key pair ethereum account, which means that it’s fee (no gas costs) and all ethereum accounts are valid identities.
ERC1812 Ethereum Verifiable Claims
It is both dangerous and in some cases illegal (according to EU GDPR rules for example) to record Identity Claims containing Personal Identifying Information (PII) on an immutable public database such as the Ethereum blockchain.
ERC1812 Reusable Off-Chain Verifiable Claims enables the issuance of off-chain identity claims, based on the typed signing capabilities defined in EIP712. The standard provide an important piece of integrating smart contracts with real world organizational requirements such as meeting regulatory requirements such as KYC, GDPR, Accredited Investor rules etc.
ERC1337 Ethereum Subscription Standard
The key monetization channel for businesses on the legacy web are monthly subscriptions. ERC1337 offers a standard interface for recurring subscriptions on the blockchain, similar to existing SaaS business models.
ERC1620 Money Streaming
Money streaming represents the idea of continuous payments over a finite period of time. Block numbers are used as a proxy of time to continuously update balances. With blockchains, payments need not be sent in discrete chunks as there is much less overhead in paying-as-you-go.
ERC1620 describes a standard whereby time is measured using block numbers and streams are mappings in a master contract:
- A provider sets up a money streaming contract.
- A prospective payer can interact with the contract and start the stream right away by depositing the funds required for the chosen period.
- The payee is able to withdraw money from the contract based on its ongoing solvency. That is:
payment rate * (current block height - starting block height)
- The stream terms (payment rate, length, metadata) can be updated at any time if both parties pledge their signatures.
- The stream can be stopped at any point in time by any party without on-chain consensus.
- If the stream period ended and it was not previously stopped by any party, the payee is entitled to withdraw all the deposited funds.
Communicating with dApps currently requires paying ETH for gas, which limits dapp adoption to ether users. Therefore, contract owners may wish to pay gas on behalf of the user to reduce friction, or let their users pay for gas with fiat money or ERC20 token.
Meta transactions allow a third party to pay transaction costs on behalf of the user. Note that while users do not need to own Ether to broadcast such meta-transactions, someone else needs to spend Ether to allow the content of the transaction to be performed on the network.
EIP865 Gasless Transactions
Introducing wallets and transactions to end users is a challenge, and having to explain that token holders needs ETH to send tokens is adding some friction to the process. The goal of this EIP is to abstract the gas for the end user, by introducing a fee paid in ERC20 tokens. A third party can then bring the transaction on-chain, pay for the gas of that given transaction and get the fee from the user.
EIP865 describes one standard function a token contract can implement to allow a user to delegate transfer of tokens to a third party. The third party pays for the gas, and takes a fee in tokens.
ERC1077 Executable Signed Messages, 1078 Universal Login
Allowing Etherless accounts to sign messages to show intent of execution, but allowing a third party relayer to execute them is an emerging pattern being used in many projects. ERC1077 standardizes a common message format as well as a way in which the user allows the transaction to be paid in ERC20 tokens.
ERC1078 extends this idea further and presents a method to replace the usual signup/login design pattern with a minimal scheme that doesn’t require passwords, backing up private keys, nor typing seed phrases.
ERC1613 Gas Stations Network
The ERC1613 gas stations network is an EIP-1077 compliant effort to removing the user hassle of acquiring ETH. It does this by creating an incentive for nodes to run gas stations, where gasless transactions can be “fueled up”. The network consists of a single public contract trusted by all participating dapp contracts, and a decentralized network of relay nodes (gas stations) incentivized to listen on non-Ether interfaces such as web or whisper, pay for transactions, and get compensated by that contract.
Standards ERC20 have helped drive innovation in crypto. In this article we’ve examined a wide variety of ERC standards in the Ethereum ecosystem, from token standards to meta transactions.
I hope this exercise gives you a good overview of community efforts in the space. Be sure to keep an eye out for new EIPs.
📬 Get updates straight to your inbox.
Subscribe to my newsletter so you don't miss new content.