[
  {
    "path": ".github/ISSUE_TEMPLATE.md",
    "content": "## 🎉 Description\n\n<!-- Describe the issue you have with the current list. Description should include relevant ERCs -->\n\n## 📝 Recommended Changes\n\n<!-- Describe what changes you propose to the current list. -->\n"
  },
  {
    "path": ".github/NEW_LIST_ELEMENT_TEMPLATE.md",
    "content": "// Token Related ERC List Template    \n// Remove comments starting with \" // \"\n\n## ERC-XXXX : Short, Informative Title (URL to proposal)\nFew sentences describing the standard\n\n\n// If applicable (almost certainly is), add one or both of the following sections :\n#### Related to:\n// When the ERCs are trying to tackle similar issues \n+ ERC-XXXX (URL) \n\n#### Strongly related to:\n// When the ERCs are almost identical in their intentions\n+ ERC-XXXX (URL) \n\n"
  },
  {
    "path": ".github/PULL_REQUEST_TEMPLATE.md",
    "content": "<!-- 0. 🎉 Thank you for submitting a PR! -->\n\n<!-- 1. **Does this close any open issues?** If so, list them here.-->\n\n\n# 🚀 Description\n\n<!-- 2. Describe the changes introduced in this pull request -->\n<!--    Include any context necessary for understanding the PR's purpose. -->\n\n<!-- 3. Before submitting, please review the following checklist: -->\n\n- [ ] 📘 If adding a new standard, I've made sure this standard was not already mentionned.\n- [ ] ✅ If adding a new standard, I've made sure to include the correct links.\n- [ ] 📖 If modifying the description, I've made sure to describe and explain the changes under *Description* above.\n"
  },
  {
    "path": "LICENSE",
    "content": "MIT License\n\nCopyright (c) 2018 Philippe Castonguay\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n"
  },
  {
    "path": "README.md",
    "content": "### Ethereum Token Standards Exhaustive List\nExhaustive 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. \n\nTo contribute, please follow the [list element template](https://github.com/PhABC/ethereum-token-standards-list/blob/master/.github/NEW_LIST_ELEMENT_TEMPLATE.md) before making a pull requests. You can also open an issue if you disagree with some of the information in this list.\n\n**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](https://github.com/PhABC/ethereum-token-standards-list/issues) could lead to removal from this list.\n\n# List of Ethereum Tokens Standards\n## ERC-20 : Standard Fungible Token ([EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md))\nStandard API for fungible tokens, including transfer and balance tracking functionalities. \n\n## ERC-223 : Protecting Users From Accidental Contract Transfers ([ERC-223](https://github.com/ethereum/EIPs/issues/223))\nERC20 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.\n\n#### Related to:\n+ [ERC-667](https://github.com/ethereum/EIPs/issues/667)\n+ [ERC-777](https://github.com/ethereum/EIPs/issues/223)\n+ [ERC-995](https://github.com/ethereum/EIPs/issues/995)\n\n## ERC-667 : transferAndCall Token Standard ([ERC-667](https://github.com/ethereum/EIPs/issues/677))\n`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.\n\n#### Strongly Related to:\n+ [ERC-223](https://github.com/ethereum/EIPs/issues/223)\n+ [ERC-777](https://github.com/ethereum/EIPs/issues/777)\n+ [ERC-995](https://github.com/ethereum/EIPs/issues/995)\n\n## ERC-721 : Non-fungible Token Standard ([EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md))\nWhile 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.\n\n## ERC-777 : Operator Based Token Standard ([ERC-777](https://github.com/ethereum/EIPs/issues/777))\nInstead 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. \n\n#### Strongly Related to:\n+ [ERC-223](https://github.com/ethereum/EIPs/issues/223)\n+ [ERC-667](https://github.com/ethereum/EIPs/issues/667)\n+ [ERC-995](https://github.com/ethereum/EIPs/issues/995)\n\n#### Related to:\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n## ERC-809 : Renting Standard for Rival, Non-Fungible Tokens ([ERC-809](https://github.com/ethereum/EIPs/issues/809))\nRival 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.\n\nNon-Fungible good: a good is non-fungible if it is not interchangeable. For example, cars are non-fungible but Ether is fungible.\n\nERC-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.\n\n## ~~ERC-827 : transferFromAndCall & approveAndCall ([ERC-827](https://github.com/ethereum/EIPs/issues/827))~~\nInsecure, removed.\n\n## ERC-864 : NFTs Shared Ownership ([ERC-864](https://github.com/ethereum/EIPs/issues/864))\nThis proposal aims to enable shared ownership of NFTs natively in the NFT contract. \n\n#### Related to:\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Strongly related to :\n+ [ERC-981](https://github.com/ethereum/EIPs/issues/981)\n\n## ERC-865 : TransferPreSigned ([ERC-865](https://github.com/ethereum/EIPs/issues/865))\nThis 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.\n\n#### Related to:\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n#### Strongly related to:\n+ [ERC-965](https://github.com/ethereum/EIPs/issues/965)\n\n## ERC-874 : Weighted Non Fungible Tokens ([ERC-874](https://github.com/ethereum/EIPs/pull/874))\nNot 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.\n\n#### Related to:\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n## ERC-888 : MultiDimensional Token Standard ([ERC-888](https://github.com/ethereum/EIPs/pull/888))\nProposing a model for multidimensional tokenization, which utilizes identifiers to refer to balances & data.\n\n#### Related to :\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Strongly related to :\n+ [ERC-994](https://github.com/ethereum/EIPs/issues/994)\n+ [ERC-998](https://github.com/ethereum/EIPs/issues/998)\n+ [ERC-1155](https://github.com/ethereum/EIPs/pull/1155)\n+ [ERC-1178](https://eips.ethereum.org/EIPS/eip-1178)\n+ [ERC-1203](https://eips.ethereum.org/EIPS/eip-1203)\n\n## ERC-918 : Minable Token Standard ([EIP-918](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-918.md))\nA specification for a standardized Mineable Token that uses a Proof of Work algorithm for distribution.\n\n#### Related to:\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n## ERC-965 : sendByCheque ([ERC-965](https://github.com/ethereum/EIPs/issues/965))\nThis 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.\n\n#### Related to:\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n#### Strongly related to:\n+ [ERC-865](https://github.com/ethereum/EIPs/issues/865)\n\n## ERC-981 : Partial Ownership Standard ([ERC-981](https://github.com/ethereum/EIPs/issues/981))\nThis 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.\n\n#### Related to:\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Strongly related to : \n* [ERC-864](https://github.com/ethereum/EIPs/issues/864). \n\n## ERC-994 : Delegated Non-Fungible Token Standard ([ERC-994](https://github.com/ethereum/EIPs/issues/994))\nDelegated 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.\n\nUnlike 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. \n\n#### Related to:\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Related to:\n+ [ERC-888](https://github.com/ethereum/EIPs/pull/888)\n+ [ERC-998](https://github.com/ethereum/EIPs/issues/998)\n+ [ERC-1155](https://github.com/ethereum/EIPs/issues/1155)\n+ [ERC-1178](https://eips.ethereum.org/EIPS/eip-1178)\n+ [ERC-1203](https://eips.ethereum.org/EIPS/eip-1203)\n\n## ERC-995 : Pre and Post Transfer Calls ([ERC-995](https://github.com/ethereum/EIPs/issues/995))\nThis 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.\n\n#### Strongly related to:\n+ [ERC-223](https://github.com/ethereum/EIPs/issues/223)\n+ [ERC-667](https://github.com/ethereum/EIPs/issues/667)\n+ [ERC-777](https://github.com/ethereum/EIPs/issues/223)\n\n## ERC-998 : Composable Non-Fungible Token Standard ([ERC-998](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md))\nA 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.\n\n#### Related to :\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Strongly related to:\n+ [ERC-888](https://github.com/ethereum/EIPs/pull/888)\n+ [ERC-994](https://github.com/ethereum/EIPs/issues/994)\n+ [ERC-1155](https://github.com/ethereum/EIPs/issues/1155)\n+ [ERC-1178](https://eips.ethereum.org/EIPS/eip-1178)\n+ [ERC-1203](https://eips.ethereum.org/EIPS/eip-1203)\n\n## ~~ERC-1003 : Safe Transfer To Contract Extension ([ERC-1003](https://github.com/ethereum/EIPs/issues/1003))~~\nRemoved, insecure.\n\n## ERC-1067 : Upgradeable Token Contract Standard ([ERC-1067](https://github.com/ethereum/EIPs/issues/1067))\nThe 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.\n\n#### Related to :\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n## ERC-1132 : Token Locking Capability Standard ([ERC-1132](https://github.com/ethereum/EIPs/issues/1132))\nThis 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).\n\n#### Related to :\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n\n## ERC-1155 : Multi-Tokens Standard ([ERC-1155](https://github.com/ethereum/EIPs/issues/1155))\nContract that keep tracks of multiple token balances and ownership to improve batch transfer efficiency. \n\n#### Related to :\n+ [EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md)\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n#### Strongly related to:\n+ [ERC-888](https://github.com/ethereum/EIPs/pull/888)\n+ [ERC-994](https://github.com/ethereum/EIPs/issues/994)\n+ [ERC-998](https://github.com/ethereum/EIPs/issues/998)\n+ [ERC-1178](https://eips.ethereum.org/EIPS/eip-1178)\n+ [ERC-1203](https://eips.ethereum.org/EIPS/eip-1203)\n\n## ERC-1178 : Multi-Class Token Standard ([ERC-1178](https://eips.ethereum.org/EIPS/eip-1178))\nStandard interface for token contract with multiple token classes.\n\n#### Strongly related to:\n+ [ERC-888](https://github.com/ethereum/EIPs/pull/888)\n+ [ERC-994](https://github.com/ethereum/EIPs/issues/994)\n+ [ERC-998](https://github.com/ethereum/EIPs/issues/998)\n+ [ERC-1155](https://github.com/ethereum/EIPs/issues/1155)\n+ [ERC-1203](https://eips.ethereum.org/EIPS/eip-1203)\n\n## ERC-1190 : Non-Fungible Royalty Token Standard ([ERC-1190](https://github.com/ethereum/EIPs/issues/1190))\nA standard interface for non-fungible tokens that pay royalties for a digital asset to the original creator(s) and/or owner(s).\n\n#### Related to :\n+ [EIP-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md)\n\n## ERC-1203 : Multi-Class Token Standard (ERC-20 Extension) ([ERC-1203](https://eips.ethereum.org/EIPS/eip-1203))\nStandard interface for token contract with multiple token classes that is also ERC-20 compatible. \n\n#### Strongly related to:\n+ [ERC-888](https://github.com/ethereum/EIPs/pull/888)\n+ [ERC-994](https://github.com/ethereum/EIPs/issues/994)\n+ [ERC-998](https://github.com/ethereum/EIPs/issues/998)\n+ [ERC-1155](https://github.com/ethereum/EIPs/issues/1155)\n+ [ERC-1178](https://eips.ethereum.org/EIPS/eip-1178)\n\n## ERC-1238 : Non-Transferrable Tokens AKA Badges ([ERC-1238](https://github.com/ethereum/EIPs/issues/1238))\nNon-transferable tokens that represent \"badges\".\n\n# Additional resources\n\n## Minime Token (https://github.com/Giveth/minime)\nERC-20 token with additional features: Easy to clone tokens, balance transfer history & token controller.\n\n## Yoga Token (https://github.com/Giveth/yogatoken)\nMinime token with ERC-223 functions. \n"
  }
]