{"action":"created","issue":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/1404","repository_url":"https://api.github.com/repos/ethereum/EIPs","labels_url":"https://api.github.com/repos/ethereum/EIPs/issues/1404/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/EIPs/issues/1404/comments","events_url":"https://api.github.com/repos/ethereum/EIPs/issues/1404/events","html_url":"https://github.com/ethereum/EIPs/issues/1404","id":359329364,"node_id":"MDU6SXNzdWUzNTkzMjkzNjQ=","number":1404,"title":"ERC-1404: Simple Restricted Token Standard","user":{"login":"masonicGIT","id":7960935,"node_id":"MDQ6VXNlcjc5NjA5MzU=","avatar_url":"https://avatars1.githubusercontent.com/u/7960935?v=4","gravatar_id":"","url":"https://api.github.com/users/masonicGIT","html_url":"https://github.com/masonicGIT","followers_url":"https://api.github.com/users/masonicGIT/followers","following_url":"https://api.github.com/users/masonicGIT/following{/other_user}","gists_url":"https://api.github.com/users/masonicGIT/gists{/gist_id}","starred_url":"https://api.github.com/users/masonicGIT/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/masonicGIT/subscriptions","organizations_url":"https://api.github.com/users/masonicGIT/orgs","repos_url":"https://api.github.com/users/masonicGIT/repos","events_url":"https://api.github.com/users/masonicGIT/events{/privacy}","received_events_url":"https://api.github.com/users/masonicGIT/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-09-12T06:12:07Z","updated_at":"2018-09-20T00:45:02Z","closed_at":null,"author_association":"NONE","body":"|eip         |title  | authors| status | discussions-to | type | category | created |\r\n|---------|----|---------|-------|----------------|-----|----------|---------|\r\n| 1404 | Simple Restricted Token Standard|Ron Gierlach <@rongierlach>, James Poole <@pooleja>, Mason Borda <@masonicgit>, Lawson Baker <@lwsnbaker> | Draft | https://github.com/simple-restricted-token/simple-restricted-token/issues | Standards | ERC | 2018-07-27 |\r\n\r\n# Simple Restricted Token Standard\r\n\r\n## Simple Summary\r\n\r\nA simple and interoperable standard for issuing tokens with transfer restrictions. The following draws on input from top issuers, law firms, relevant US regulatory bodies, and exchanges.  \r\n\r\n## Abstract\r\n\r\nCurrent ERC token standards have provided the community with a platform on which to develop a decentralized economy that is focused on building Ethereum applications for the real world. As these applications mature and face consumer adoption, they begin to interface with corporate governance requirements as well as regulations. They must not only be able to meet corporate and regulatory requirements but must also be able to integrate with technology platforms underpinning their associated businesses. What follows is a simple and extendable standard that seeks to ease the burden of integration for wallets, exchanges, and issuers.\r\n\r\n## Motivation\r\n\r\nToken issuers need a way to restrict transfers of ERC-20 tokens to be compliant with securities laws and other contractual obligations. Current implementations do not address these requirements. \r\n\r\nA few emergent examples:\r\n\r\n- Enforcing Token Lock-Up Periods\r\n- Enforcing Passed AML/KYC Checks\r\n- Private Real-Estate Investment Trusts\r\n- Delaware General Corporations Law Shares\r\n\r\nFurthermore, standards adoption amongst token issuers has the potential to evolve into a dynamic and interoperable landscape of automated compliance.\r\n\r\nThe following design gives greater freedom / upgradability to token issuers and simultaneously decreases the burden of integration for developers and exchanges.\r\n\r\nAdditionally, we see fit to provide a pattern by which human-readable messages may be returned when token transfers are reverted. Transparency as to _why_ a token's transfer was reverted is of equal importance to the successful enforcement of the transfer restriction itself.\r\n\r\nA widely adopted standard for detecting restrictions and messaging errors within token transfers will highly convenience the exchanges, wallets, and issuers of the future.\r\n\r\n## Specification\r\n\r\nThe ERC-20 token provides the following basic features:\r\n```solidity\r\ncontract ERC20 {\r\n  function totalSupply() public view returns (uint256);\r\n  function balanceOf(address who) public view returns (uint256);\r\n  function transfer(address to, uint256 value) public returns (bool);\r\n  function allowance(address owner, address spender) public view returns (uint256);\r\n  function transferFrom(address from, address to, uint256 value) public returns (bool);\r\n  function approve(address spender, uint256 value) public returns (bool);\r\n  event Approval(address indexed owner, address indexed spender, uint256 value);\r\n  event Transfer(address indexed from, address indexed to, uint256 value);\r\n}\r\n```\r\nThe ERC-1404 standard builds on ERC-20's interface, adding two functions:\r\n```solidity\r\ncontract ERC1404 is ERC20 {\r\n  function detectTransferRestriction (address from, address to, uint256 value) public view returns (uint8);\r\n  function messageForTransferRestriction (uint8 restrictionCode) public view returns (string);\r\n}\r\n```\r\n\r\nThe logic of `detectTransferRestriction` and `messageForTransferRestriction` are left up to the issuer.\r\n\r\nThe only requirement is that `detectTransferRestriction` must be evaluated inside a token's `transfer` and `transferFrom` methods.\r\n\r\nIf, inside these transfer methods, `detectTransferRestriction` returns a value other than `0`, the transaction should be reverted.\r\n\r\n## Rationale\r\n\r\nThe standard proposes two functions and an event on top of the ERC-20 standard. Let's discuss the rationale for each.\r\n\r\n1. `detectTransferRestriction` - This function is where an issuer enforces the restriction logic of their token transfers. Some examples of this might include, checking if the token recipient is whitelisted, checking if a sender's tokens are frozen in a lock-up period, etc. Because implementation is up to the issuer, this function serves solely to standardize _where_ execution of such logic should be initiated. Additionally, 3rd parties may publicly call this function to check the expected outcome of a transfer. Because this function returns a `uint8` code rather than a boolean or just reverting, it allows the function caller to know the reason why a transfer might fail and report this to relevant counterparties.\r\n2. `messageForTransferRestriction` - This function is effectively an accessor for the \"message\", a human-readable explanation as to _why_ a transaction is restricted. By standardizing message look-ups, we empower user interface builders to effectively report errors to users.\r\n\r\n## Backwards Compatibility\r\n\r\nBy design ERC-1404 is fully backwards compatible with ERC-20.  \r\nSome examples of how it may be integrated with common types of restricted tokens may be found [here](https://github.com/simple-restricted-token/simple-restricted-token-standard#readme).\r\n\r\n## Test Cases & Implementation\r\n\r\nSee the reference implementation and tests [here](https://github.com/simple-restricted-token/reference-implementation#readme).  \r\nSee some examples of common usage patterns for ERC-1404 [here](https://github.com/simple-restricted-token/simple-restricted-token-standard#readme).\r\n\r\n## Copyright\r\n\r\nCopyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).\r\n"},"comment":{"url":"https://api.github.com/repos/ethereum/EIPs/issues/comments/423002902","html_url":"https://github.com/ethereum/EIPs/issues/1404#issuecomment-423002902","issue_url":"https://api.github.com/repos/ethereum/EIPs/issues/1404","id":423002902,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMzAwMjkwMg==","user":{"login":"rongierlach","id":4658359,"node_id":"MDQ6VXNlcjQ2NTgzNTk=","avatar_url":"https://avatars3.githubusercontent.com/u/4658359?v=4","gravatar_id":"","url":"https://api.github.com/users/rongierlach","html_url":"https://github.com/rongierlach","followers_url":"https://api.github.com/users/rongierlach/followers","following_url":"https://api.github.com/users/rongierlach/following{/other_user}","gists_url":"https://api.github.com/users/rongierlach/gists{/gist_id}","starred_url":"https://api.github.com/users/rongierlach/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rongierlach/subscriptions","organizations_url":"https://api.github.com/users/rongierlach/orgs","repos_url":"https://api.github.com/users/rongierlach/repos","events_url":"https://api.github.com/users/rongierlach/events{/privacy}","received_events_url":"https://api.github.com/users/rongierlach/received_events","type":"User","site_admin":false},"created_at":"2018-09-20T00:45:02Z","updated_at":"2018-09-20T00:45:02Z","author_association":"NONE","body":"@bmann Thanks for chiming in!\r\n\r\nLooks like #902's `TokenValidator` contract shares more similarities to Harbor R-Token's [RegulatorService](https://github.com/harborhq/r-token/blob/master/contracts/RegulatorService.sol) approach. We include an R-Token integration example [here](https://github.com/simple-restricted-token/simple-restricted-token/tree/master/contracts/examples/other-standards/R-Token)! 😄 \r\n\r\nIn ERC1404, `detectTransferRestriction` is meant to live on the token contract itself, in there you could easily kick off the call to `validate` (what looks to be one of #902's \"validation helpers\") and achieve a similar result."}}
{"actor":{"display_login":"rongierlach"}}