Exhaustive list of all token related standards proposed for the Ethereum network. Feel free to create pull requests or open an issue if you would like to add new or missed token standards to this list. Feel free to also suggests better description and other relationships between standards. Many of the descriptions are taken from the proposals themselves.
To contribute, please follow the list element template before making a pull requests. You can also open an issue if you disagree with some of the information in this list.
I personally encourage proposals that are strongly related in their intentions to collaborate and merge in order to improve adoption success. For the sake of transparency, no judgment was made on the content and all proposals that had sufficient information were included. Included proposals that are considered insecure or mediocre should be encouraged to be closed and will then be removed from this list. Sufficient support for the removal of a proposal in the issues could lead to removal from this list.
ERC-20 : Standard Fungible Token (EIP-20)
Standard API for fungible tokens, including transfer and balance tracking functionalities.
ERC-223 : Protecting Users From Accidental Contract Transfers (ERC-223)
ERC20 token standard is leading to money losses for end users. The main problem is lack of possibility to handle incoming ERC20 transactions, that were performed via transfer function of ERC20 token. ERC-223 describes standard functions a token contract and contract working with specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.
ERC-667 : transferAndCall Token Standard (ERC-667)
transferAndCall behaves similarly to transfer(address,uint256,bytes), but allows implementers to gain the functionality without the risk of inadvertently locking up tokens in non-ERC223 compatible contracts. It is distinct from ERC223's transfer(address,uint256,bytes) only in name, but this distinction allows for easy distinguishability between tokens that are ERC223 and tokens that are simply ERC20 + ERC667.
ERC-721 : Non-fungible Token Standard (EIP-721)
While fungible tokens can be divided, non-fungible tokens (NFTs) can not. NFTs can be owned and transacted by individuals as well as consigned to third party brokers/wallets/auctioneers ("operators"). NFTs can represent ownership over digital or physical assets.
ERC-777 : Operator Based Token Standard (ERC-777)
Instead of using uints for approving third parties to transfer tokens on the users behalf, ERC-777 proposes to use a boolean mapping between users and operators. This simplifies the language, the approval process and decreases gas cost. 777 also includes data passing functions.
ERC-809 : Renting Standard for Rival, Non-Fungible Tokens (ERC-809)
Rival good: a good is rival if its consumption by one individual prevents simultaneous consumption by other individuals. For example, driving a car is rival but watching the sunset is non-rival.
Non-Fungible good: a good is non-fungible if it is not interchangeable. For example, cars are non-fungible but Ether is fungible.
ERC-809 allows an owner to rent access to their rival NFTs using a standard set of commands, thus allowing users to view all past and current rental agreements from a single wallet interface.
ERC-827 : transferFromAndCall & approveAndCall (ERC-827)
Insecure, removed.
ERC-864 : NFTs Shared Ownership (ERC-864)
This proposal aims to enable shared ownership of NFTs natively in the NFT contract.
ERC-865 : TransferPreSigned (ERC-865)
This proposal 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.
ERC-874 : Weighted Non Fungible Tokens (ERC-874)
Not all NFTs are created equal. Nothing exists to distinguish one NFT from another. Weight allows a DAO or other external actors to recognize some value for unique asset holdings.
ERC-888 : MultiDimensional Token Standard (ERC-888)
Proposing a model for multidimensional tokenization, which utilizes identifiers to refer to balances & data.
ERC-918 : Minable Token Standard (EIP-918)
A specification for a standardized Mineable Token that uses a Proof of Work algorithm for distribution.
ERC-965 : sendByCheque (ERC-965)
This proposal aims to allow pre-signing messages that will permit third parties to execute a token transfer without the original sender needing to do an on-chain transaction in the first place. The sender would simply need to sign a message and the third party would call sendByCheque() with the signature.
ERC-981 : Partial Ownership Standard (ERC-981)
This proposal serves to describe a new Ethereum Interface for issuing tokens for asset owners who come to a marketplace with a finite quantity of their asset to trade, representing 100% ownership of that particular issue. They then choose to divide the asset into divisible units that increase fungibility of that asset.
ERC-994 : Delegated Non-Fungible Token Standard (ERC-994)
Delegated Non-Fungible Tokens (DNFTs) are a proposed extension of the ERC721 standard designed with the use case of Ethereum-based registration of land and physical property in mind. NFTs are arranged in a federated, tree-like format (similar to DNS) where NFTs can delegate and sub-contract NFTs within a certain geospace.
Unlike digital assets (like CryptoKitties) physical property requires more than just an accurate identification in a database- it also requires legal validity within the context of physical sovereignty. DNFT zones can established by land registry authorities as a root DNFT encompassing a wide area, and can delegate DNFTs as subdivisions of the root zone to existing property holders as a way to upgrade land registries.
ERC-995 : Pre and Post Transfer Calls (ERC-995)
This standard provides an augmented token transfer functionality besides legacy proven ERC20 functionality. It allows to execute calls on transfers and approvals both before and after tokens are transferred regardless if the receiving address is a contract or not.
ERC-998 : Composable Non-Fungible Token Standard (ERC-998)
A standard extension for any non-fungible token to own another non-fungible ERC-721 or standard fungible ERC-20 tokens. Transferring the token composition means transferring the entire hierarchy of items. For example, a cryptokitty may own a scratching post and a feeding dish; the dish may contain some amount of fungible “chow” tokens.
ERC-1003 : Safe Transfer To Contract Extension (ERC-1003)
Removed, insecure.
ERC-1067 : Upgradeable Token Contract Standard (ERC-1067)
The following proposal describes a more distributed token contract architecture that has a simple upgrade-ability protocol and allows to bring in new functions after being deployed.
ERC-1132 : Token Locking Capability Standard (ERC-1132)
This proposal provides basic functionality to time-lock tokens within a contract for multiple utilities without the need of transferring tokens. It also allows fetching token balances of locked and unlocked tokens (tokens available for transfer).
ERC-1155 : Multi-Tokens Standard (ERC-1155)
Contract that keep tracks of multiple token balances and ownership to improve batch transfer efficiency.
ERC-1178 : Multi-Class Token Standard (ERC-1178)
Standard interface for token contract with multiple token classes.
ERC-1190 : Non-Fungible Royalty Token Standard (ERC-1190)
A standard interface for non-fungible tokens that pay royalties for a digital asset to the original creator(s) and/or owner(s).
ERC-1203 : Multi-Class Token Standard (ERC-20 Extension) (ERC-1203)
Standard interface for token contract with multiple token classes that is also ERC-20 compatible.
ERC-1238 : Non-Transferrable Tokens AKA Badges (ERC-1238)
Non-transferable tokens that represent "badges".
Minime Token (https://github.com/Giveth/minime)
ERC-20 token with additional features: Easy to clone tokens, balance transfer history & token controller.
Yoga Token (https://github.com/Giveth/yogatoken)
Minime token with ERC-223 functions.