{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/223","repository_url":"https://api.github.com/repos/ethereum/EIPs","labels_url":"https://api.github.com/repos/ethereum/EIPs/issues/223/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/EIPs/issues/223/comments","events_url":"https://api.github.com/repos/ethereum/EIPs/issues/223/events","html_url":"https://github.com/ethereum/EIPs/issues/223","id":211957086,"number":223,"title":"ERC223 token standard","user":{"login":"Dexaran","id":26142412,"avatar_url":"https://avatars1.githubusercontent.com/u/26142412?v=4","gravatar_id":"","url":"https://api.github.com/users/Dexaran","html_url":"https://github.com/Dexaran","followers_url":"https://api.github.com/users/Dexaran/followers","following_url":"https://api.github.com/users/Dexaran/following{/other_user}","gists_url":"https://api.github.com/users/Dexaran/gists{/gist_id}","starred_url":"https://api.github.com/users/Dexaran/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Dexaran/subscriptions","organizations_url":"https://api.github.com/users/Dexaran/orgs","repos_url":"https://api.github.com/users/Dexaran/repos","events_url":"https://api.github.com/users/Dexaran/events{/privacy}","received_events_url":"https://api.github.com/users/Dexaran/received_events","type":"User","site_admin":false},"labels":[{"id":290507092,"url":"https://api.github.com/repos/ethereum/EIPs/labels/ERC","name":"ERC","color":"d4c5f9","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":301,"created_at":"2017-03-05T14:43:51Z","updated_at":"2017-09-13T06:10:52Z","closed_at":null,"author_association":"NONE","body":"ERC: 223\r\nTitle: Token standard\r\nAuthor: Dexaran, dexaran820@gmail.com\r\nStatus: Draft\r\nType: ERC\r\nCreated: 5-03.2017\r\nResolution: https://github.com/Dexaran/ERC223-token-standard\r\nRecommended implementation: https://github.com/Dexaran/ERC223-token-standard/tree/Recommended\r\n\r\n## Abstract\r\n\r\nThe following 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.\r\n\r\n## Motivation\r\n\r\nProblems of ERC20 that ERC223 will solve: \r\n1. Impossibility of handling incoming transactions in receiver contract.\r\n2. Tokens could be sent to contract that is not designed to work with tokens without handling and potentially could be lost. At least $400 000 are lost at the moment. This problem is described [here](https://www.reddit.com/r/ethereum/comments/60ql37/attention_be_careful_using_ethereum_tokens/).\r\n3. Token-transactions should match Ethereum ideology of uniformity. When a user needs to transfer his funds, he must always perform `transfer`. Doesn't matter is user depositing in contract or sending to an externally owned account.\r\n\r\nThose will allow contracts to handle incoming token transactions and prevent accidentally sent tokens from being accepted by contracts.\r\nFor example decentralized exchange will no more need to force users to call `approve` at token contract then call `deposit` that is calling `transferFrom` taking allowed tokens. Token transaction will automatically be handled inside the exchange contract.\r\n\r\nThe most important here is a call of `tokenFallback` when performing a transaction to a contract.\r\n\r\n## Specification\r\n\r\nToken\r\nContracts that work with tokens\r\n\r\n## Methods\r\n\r\nNOTE: An important point is that contract developers must implement `tokenFallback` if they want their contracts to work with the specified tokens.\r\n\r\nIf the receiver does not implement the `tokenFallback` function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement `function() payable`.\r\n\r\n\r\n#### totalSupply\r\n\r\n```js\r\nfunction totalSupply() constant returns (uint256 totalSupply)\r\n```\r\nGet the total token supply\r\n\r\n#### name\r\n\r\n```js\r\nfunction name() constant returns (string _name)\r\n```\r\nGet the name of token\r\n\r\n#### symbol\r\n\r\n```js\r\nfunction symbol() constant returns (bytes32 _symbol)\r\n```\r\nGet the symbol of token\r\n\r\n#### decimals\r\n\r\n```js\r\nfunction decimals() constant returns (uint8 _decimals)\r\n```\r\nGet decimals of token\r\n\r\n#### balanceOf\r\n\r\n```js\r\nfunction balanceOf(address _owner) constant returns (uint256 balance)\r\n```\r\nGet the account balance of another account with address _owner\r\n\r\n\r\n#### transfer(address, uint)\r\n\r\n```js\r\nfunction transfer(address _to, uint _value) returns (bool)\r\n```\r\nNeeded due to backwards compatibility reasons because of ERC20 transfer function doesn't have `bytes` parameter. This function must transfer tokens and invoke the function `tokenFallback(address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenFallback` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. \r\n\r\nIMPORTANT: Token fallback function that will be called at receiver contract must be named `tokenFallback` and take parameters` address`, `uint256`,` bytes`. This function must have `0xc0ee0b8a`  [signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a).\r\n\r\n\r\n#### transfer(address, uint, bytes)\r\n\r\n```js\r\nfunction transfer(address _to, uint _value, bytes _data) returns (bool)\r\n```\r\nfunction that is always called when someone wants to transfer tokens.\r\nThis function must transfer tokens and invoke the function `tokenFallback (address, uint256, bytes)` in `_to`, if _to is a contract. If the `tokenFallback` function is not implemented in ` _to` (receiver contract), then the transaction must fail and the transfer of tokens should not occur. \r\nIf `_to` is an externally owned address, then the transaction must be sent without trying to execute ` tokenFallback` in `_to`.\r\n `_data` can be attached to this token transaction and it will stay in blockchain forever (requires more gas). `_data` can be empty.\r\n\r\nNOTE: The recommended way to check whether the `_to` is a contract or an address is to assemble the code of ` _to`. If there is no code in `_to`, then this is an externally owned address, otherwise it's a contract.\r\n\r\nIMPORTANT: Token fallback function that will be called at receiver contract must be named `tokenFallback` and take parameters` address`, `uint256`,` bytes`. This function must have `0xc0ee0b8a` [signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a).\r\n\r\n## Events\r\n\r\n#### Transfer\r\n\r\n```js\r\nevent Transfer(address indexed _from, address indexed _to, uint256 indexed _value, bytes _data)\r\n```\r\nTriggered when tokens are transferred.\r\n\r\n## Contract to work with tokens\r\n\r\n```js\r\nfunction tokenFallback(address _from, uint _value, bytes _data)\r\n```\r\nA function to handle token transfers that is called from token contract when token holder is sending tokens. `_from` is a token sender, `_value` is amount of incoming tokens and `_data` is attached data similar to data in Ether transactions. Works like fallback function for Ether transactions and returns nothing.\r\n\r\nNOTE: `msg.sender` will be a token-contract inside the `tokenFallback` function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be `_from` inside the` tokenFallback` function.\r\n\r\nIMPORTANT: This function must be named `tokenFallback` and take parameters` address`, `uint256`,` bytes` to match the [function signature](https://www.4byte.directory/signatures/?bytes4_signature=0xc0ee0b8a) `0xc0ee0b8a`.\r\n\r\n## Recommended implementation\r\nThis is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC23-tokens/tree/Recommended"},"comment":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/comments/329069061","html_url":"https://github.com/ethereum/EIPs/issues/223#issuecomment-329069061","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/223","id":329069061,"user":{"login":"mcdee","id":511384,"avatar_url":"https://avatars2.githubusercontent.com/u/511384?v=4","gravatar_id":"","url":"https://api.github.com/users/mcdee","html_url":"https://github.com/mcdee","followers_url":"https://api.github.com/users/mcdee/followers","following_url":"https://api.github.com/users/mcdee/following{/other_user}","gists_url":"https://api.github.com/users/mcdee/gists{/gist_id}","starred_url":"https://api.github.com/users/mcdee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mcdee/subscriptions","organizations_url":"https://api.github.com/users/mcdee/orgs","repos_url":"https://api.github.com/users/mcdee/repos","events_url":"https://api.github.com/users/mcdee/events{/privacy}","received_events_url":"https://api.github.com/users/mcdee/received_events","type":"User","site_admin":false},"created_at":"2017-09-13T06:10:52Z","updated_at":"2017-09-13T06:10:52Z","author_association":"NONE","body":"The issue with discarding decimals is that it means that tokens cannot represent both discrete and continuous values.\r\n\r\nAn example of a discrete token might be LicenseToken, where the token creator uses tokens to represent a license to use a product they have built.  A license is directly equivalent to 1 token, and today they would create an ERC20 token with decimals set to 0.\r\n\r\nAn example of a continuous token might be GoldToken, where the token creator wants 1 token to represent 1Kg of gold.  They want people to be able to trade GoldToken in quantities far less than 1KG, and today they would create an ERC20 token with decimals set to 18 (for example).\r\n\r\nIf decimals is hard-coded to 18 then the first token will be made significantly more complex for the developer. The developer would have to guard each call that moves tokens to ensure that it is a multiple of 10^18, and without any way of telling the outside world this is what they are doing it would cause many thrown transactions.\r\n\r\nIf decimals is hard-coded to 0 then the second token will be made significantly more complex for the user.  Rather than having their desired \"1 token == 1KG of gold\" they would end up with \"1 token == 10^-15g of gold\", a value which begs for users to miss the value they want by one or two orders of magnitude when typing in real-world values for transfers of gold.\r\n\r\n@MicahZoltu I don't think that anecdotes are the way to justify this change.  Sure I've seen people in Gitter confused by decimals, but then I've seen people in Gitter confused by pretty much everything within Solidity and Ethereum.  Yesterday there were two separate people who were in Gitter confused about how inheritance worked; should we remove that as well?  In the meantime there are hundreds of ERC20 tokens that have been released successfully so it doesn't appear to be a show stopper.\r\n\r\nAs for user confusion, it sounds like issues of documentation and/or tooling.  Documentation explaining that \"decimals\" is related to the divisibility of the token, and the number is how divisible the token is, could be added to the relevant locations.  And with a bit more effort such webpages could just ask for the token's address and fetch symbol, decimals etc. directly from the blockchain without the user ever being aware of it.  Or they could use a registry like MEWs or thetoken.eth to obtain the data.  There are certainly solutions to stop users having to enter token information manually, though.\r\n\r\nThere needs to be a way to represent both discrete and continuous values with tokens, or else we lose a chunk of their utility.  If there really are good reasons to get rid of decimals as an entity then at the least allow the choice of two options (0 or 18) to retain this ability."}}
{"actor":{"display_login":"mcdee"}}