{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/677","repository_url":"https://api.github.com/repos/ethereum/EIPs","labels_url":"https://api.github.com/repos/ethereum/EIPs/issues/677/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/EIPs/issues/677/comments","events_url":"https://api.github.com/repos/ethereum/EIPs/issues/677/events","html_url":"https://github.com/ethereum/EIPs/issues/677","id":244131817,"number":677,"title":"ERC: transferAndCall Token Standard","user":{"login":"se3000","id":573827,"avatar_url":"https://avatars1.githubusercontent.com/u/573827?v=4","gravatar_id":"","url":"https://api.github.com/users/se3000","html_url":"https://github.com/se3000","followers_url":"https://api.github.com/users/se3000/followers","following_url":"https://api.github.com/users/se3000/following{/other_user}","gists_url":"https://api.github.com/users/se3000/gists{/gist_id}","starred_url":"https://api.github.com/users/se3000/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/se3000/subscriptions","organizations_url":"https://api.github.com/users/se3000/orgs","repos_url":"https://api.github.com/users/se3000/repos","events_url":"https://api.github.com/users/se3000/events{/privacy}","received_events_url":"https://api.github.com/users/se3000/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":46,"created_at":"2017-07-19T18:27:18Z","updated_at":"2017-12-25T14:10:09Z","closed_at":null,"author_association":"NONE","body":"## Preamble\r\n\r\n     ERC: 677\r\n     Title: transferAndCall Token Standard\r\n     Type: Informational\r\n     Category: ERC\r\n     Status: Draft\r\n     Created: 2017-07-17\r\n     Requires: ERC20\r\n\r\n## Simple Summary\r\n\r\nAllow tokens to be transferred to contracts and have the contract trigger logic for how to respond to receiving the tokens within a single transaction.\r\n\r\n## Abstract\r\n\r\nThis adds a new function to [ERC20](https://github.com/ethereum/EIPs/issues/20) token contracts, `transferAndCall` which can be called to transfer tokens to a contract and then call the contract with the additional data provided. Once the token is transferred, the token contract calls the receiving contract's function `tokenFallback(address,uint256,bytes)` and triggers an event `Transfer(address,address,uint,bytes)`, following the convention set in [ERC223](https://github.com/ethereum/EIPs/issues/223).\r\n\r\n## Motivation\r\n\r\nERC20 requires a multistep process for tokens to be transferred to a contract. First `approve` must be called on the token contract, enabling the contract to withdraw the tokens. Next, the contract needs to be informed that it has been approved to withdraw tokens. Finally, the contract has to actually withdraw the tokens, and run any code related to receiving tokens. This process typically takes two to three steps, which is inefficient and a poor user experience.\r\n\r\nWhile ERC223 solves the described problem with its `transfer(address,uint256,bytes)` function, it opens other problems. ERC223 changes the behavior of ERC20's `transfer(address,uint256)`, specifying that it should throw if transferring to a contract that does not implement `tokenFallback`. This is problematic because there are deployed contracts in use that assume they can safely call `transfer(address,uint256)` to move tokens to their recipient. If one of these deployed contracts were to transfer an ERC223 token to a contract(e.g. a multisig wallet) the tokens would effectively become stuck in the transferring contract.\r\n\r\nThis ERC aims to provide the helpful functionality of ERC223 without colliding with it. By giving contracts a reason to implement `tokenFallback` before ERC223 becomes widely implemented, a smooth transition is provided until a larger part of the Ethereum ecosystem is informed about and capable of handling ERC223 tokens. `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.\r\n\r\n## Specification\r\n\r\n### Token\r\n#### transferAndCall\r\n```javascript\r\nfunction transferAndCall(address receiver, uint amount, bytes data) returns (bool success)\r\n```\r\nTransfers tokens to `receiver`, via ERC20's `transfer(address,uint256)` function. It then logs an event `Transfer(address,address,uint256,bytes)`. Once the transfer has succeeded and the event is logged, the token calls `tokenFallback(address,uint256,bytes)` on the `receiver` with the sender, the amount approved, and additional bytes data as parameters.\r\n\r\n### Receiving Contract\r\n#### tokenFallback\r\n```javascript\r\nfunction tokenFallback(address from, uint256 amount, bytes data) returns (bool success)\r\n```\r\nThe function is added to contracts enabling them to react to receiving tokens within a single transaction. The `from` parameter is the account which just trasfered `amount` from the `token` contract. `data` is available to pass additional parameters, i.e. to indicate what the intention of the transfer is if a contract allows transfers for multiple reasons.\r\n\r\n## Backwards Compatibility\r\nThis proposal is backwards compatible for all ERC20 tokens and contracts. New tokens and contracts moving forward can implement the `transferAndCall` functionality, but also still fallback to the original `approve`-`transferFrom` workflow when dealing with legacy contracts. It does not require any changes or additional steps from already deployed contracts, but enables future contracts to gain this functionality.\r\n\r\n## Implementation\r\nWIP: I'll provide a generic example with tests in the future. Still looking for feedback at the moment."},"comment":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/comments/353871816","html_url":"https://github.com/ethereum/EIPs/issues/677#issuecomment-353871816","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/677","id":353871816,"user":{"login":"tal-beja","id":10635261,"avatar_url":"https://avatars1.githubusercontent.com/u/10635261?v=4","gravatar_id":"","url":"https://api.github.com/users/tal-beja","html_url":"https://github.com/tal-beja","followers_url":"https://api.github.com/users/tal-beja/followers","following_url":"https://api.github.com/users/tal-beja/following{/other_user}","gists_url":"https://api.github.com/users/tal-beja/gists{/gist_id}","starred_url":"https://api.github.com/users/tal-beja/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tal-beja/subscriptions","organizations_url":"https://api.github.com/users/tal-beja/orgs","repos_url":"https://api.github.com/users/tal-beja/repos","events_url":"https://api.github.com/users/tal-beja/events{/privacy}","received_events_url":"https://api.github.com/users/tal-beja/received_events","type":"User","site_admin":false},"created_at":"2017-12-25T14:10:09Z","updated_at":"2017-12-25T14:10:09Z","author_association":"NONE","body":"@Dexaran  So?\r\nDon't  `transferAndCall` to a contract that \"fake\" the receiving protocol.\r\nThe `require` (in line 22) doesn't safe guard you from transferring tokens to a non \"truly\" erc223 receivers, but if they do, then the transfer will fail when the inner method didn't returned true."}}
{"actor":{"display_login":"tal-beja"}}