{"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":155,"created_at":"2017-03-05T14:43:51Z","updated_at":"2017-07-25T20:40:10Z","closed_at":null,"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/ERC23-tokens\r\nERC20 compatible example: https://github.com/Dexaran/ERC23-tokens/blob/ERC20_compatible/ERC23_token.sol\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 (string _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, bytes)\r\n\r\n```js\r\nfunction transfer(address _to, uint _value, bytes _data) returns (bool success)\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\r\n#### transfer(address, uint)\r\n\r\n```js\r\nfunction transfer(address _to, uint _value) returns (bool success)\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## Events\r\n\r\n#### Transfer\r\n\r\n```js\r\nevent Transfer(address indexed _from, address indexed _to, uint256 _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/317865292","html_url":"https://github.com/ethereum/EIPs/issues/223#issuecomment-317865292","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/223","id":317865292,"user":{"login":"Hackdom","id":5546555,"avatar_url":"https://avatars2.githubusercontent.com/u/5546555?v=4","gravatar_id":"","url":"https://api.github.com/users/Hackdom","html_url":"https://github.com/Hackdom","followers_url":"https://api.github.com/users/Hackdom/followers","following_url":"https://api.github.com/users/Hackdom/following{/other_user}","gists_url":"https://api.github.com/users/Hackdom/gists{/gist_id}","starred_url":"https://api.github.com/users/Hackdom/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Hackdom/subscriptions","organizations_url":"https://api.github.com/users/Hackdom/orgs","repos_url":"https://api.github.com/users/Hackdom/repos","events_url":"https://api.github.com/users/Hackdom/events{/privacy}","received_events_url":"https://api.github.com/users/Hackdom/received_events","type":"User","site_admin":false},"created_at":"2017-07-25T20:40:10Z","updated_at":"2017-07-25T20:40:10Z","body":"I'll go ahead and say actually while I have a moment, the approve function should act on the allowance delta rather than the allowance amount explicitly. It would be implemented in one of two ways. Either have two functions, addAllowance(uint amount) which would += the allowance and subAllowance(uint amount) which would -= the allowance with a check to assign zero if the amount is greater than currentAllowance. OR one function, changeAllowance(uint amount, bool addTo) That would wrap both functions in one and would add if addTo was true or subtract if addTo was false. This would negate the spend attack prior to the approval change."}}
{"actor":{"display_login":"Hackdom"}}