ERC1540: Asset Token Standard

EIPS/eip-1540.md

@@ -0,0 +1,185 @@
+---
+eip: 1540
+title: Asset Token Standard
+author: Axe Jiang <jzw@hashfuture.pro>, Yinghao Jia <jiayinghao@hashworld.pro>, Yong Ren <yongren@hashworld.pro>, Jiaqing Dong <jiaqing@hashworld.pro>
+discussions-to: https://github.com/ethereum/EIPs/issues/1553
+status: Draft
+type: Standards Track
+category: ERC
+created: 2018-10-25
+requires: 20
+---
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+This Asset Token Standard defines a smart contract legally representing the ownership and corresponding privileges of a real-world asset.
+The Asset token corresponding to the ownership of real-world asset can be issued into Asset keys representing shares of the asset privileges. Any holders of Asset keys can collect dividends, earn income, and receive consumer services according to their shares. Asset keys can be regarded as the standard ERC20 tokens, which exist only after an Asset token is issued into keys.
+
+This standard keeps backward compatibility with [ERC20].
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+This standard defines the ownership of a real-world asset as an Asset token according to the unique verifiable identification and corresponding rights agreement. The Asset token is a unique digital legal certificate for non-specific transfer objects, which could transfer on Ethereum freely. The transfer of Asset Token represents the transfer of ownership of assets in the real world. The whole process greatly reduces transaction costs, improves efficiency and realizes disintermediation.
+In accordance with the general Token-based mandatory delivery (TBD) agreement, any holder with this Asset token can forcibly claim for the real-world asset from the asset keeper (assigned when the Asset token is created). The Asset token will be destructed after the real-world asset has been claimed. In addition, the Asset token can be issued into a designated number of Asset keys. After key issuance, the Asset token will be in 'locked' status, under which any operations on Asset token are not permitted. Holders of Asset keys can collect dividends, earn income, and receive consumer services of the corresponding real-world asset according to their shares.
+
+## Motivation
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+
+This standard realizes the tokenization for real-world assets. In compliance with national laws and regulations, the mapping of the on-chain assets and off-chain assets is confirmed by the untampered programmable asset token generated on blockchain, which combines the unique verifiable identification and corresponding rights agreement of a real-world asset. The standard realizes the decentralized property verification for more real-world assets. This standard will endow Ethereum with greater value for the real world.
+This standard promotes the conversion of primary and secondary real-world assets. The Asset token represents a kind of holistic property, any holder of the Asset token can lock the token and issue the designated number of Asset keys. The profit from the real-world asset appreciation will be distributed to the holders of Asset keys. Meanwhile, any holder of all the Asset keys can convert into the Asset token to claim for the real-world asset. Through this process, we can achieve the free conversion of primary assets and secondary assets, greatly reducing transaction costs and promoting the efficient of assets circulation.
+This standard achieves intelligent management of programmable assets. This standard designs the function of Key issuance and Buyback price, applying smart contracts instead of corporate governance, shareholder vote, merger, acquisition, etc. Firstly, this standard can avoid big shareholders from doing evil. In reality, the major shareholders may encroach on the dividend income of the minority shareholders through the majority rule. On the other hand, it can also prevent small shareholders from extorting the holder who wants to collect all the keys to claim for the real asset, credit to the ‘collectAllForce’ function. In this way, the Situation described in “[property is only another name for monopoly](https://chicagounbound.uchicago.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=12668&context=journal_articles)” will be refrained.
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+
+### Asset Status Brief
+There are three metrics describing the status of the Asset token.
+The first one is 'valid'. The Asset token is in 'valid' status by default and will be 'invalid' once the owner explicitly executes the 'cancelContract' function, which is not reversible.
+
+The second one is 'issued'. The Asset token is 'unissued' by default, and will be 'issued' after the owner locks the Asset token and issues the Asset keys. This status is reversible. A holder with all Asset keys can convert them into the original Asset token.
+
+### Preferred Stable Token
+The contract specifies a stable token at the initialization phase by assigning the address of a preferred stable token.
+
+The stable token will be used to distribute dividends to the Asset keys holders or to collect Asset keys forcibly at the price the owner designated at when issuing the Asset keys.
+
+### Asset File Management
+#### getAssetFile / setAssetFile
+AssetFile includes two parts, one file describing features of the real-world asset and the other containing legal documents. These two files are open to the public and can be set at the constructing phase of the smart contract or by explicitly executing 'setAssetFile' or 'setLegalFile' functions by the owner. These two operations require 'unissued' and 'valid' status.
+
+```solidity
+function initAssetFile(
+    string _assetFileUrl, string _assetFileHashType, string _assetFileHashValue,
+    string _legalFileUrl, string _legalFileHashType, string _legalFileHashValue
+    ) internal;
+
+function setAssetFileLink(string url) public onlyOwner onlyValid onlyUnissued;
+
+function setLegalFileLink(string url) public onlyOwner onlyValid onlyUnissued;
+```
+
+AssetFile: indicates the unique verifiable identification of real-world assets. Generally, AssetFile includes assets’ detailed description, photos of full angle, certification authority of value, quality, availability, etc. Different types of assets have different asset templates. [Case Link](https://hashfuture.io/static/data/Asset_Info.pdf)
+
+assetFileHashValue: indicates the digital fingerprint of the asset. According to the binary data of ‘AssetFile’, applying the ‘assetFileHashType’, generate the unique and untampered ‘assetFileHashValue’, thus realizing effective registration of Asset information consistency.
+
+LegalFile: indicates the Token-based mandatory delivery (TBD) agreement of real-world assets. This agreement publicly declares that any holder of the Asset token, that is, the owner of the real-world assets off-chain, can at any time enforce the settlement of the real-world assets described in the document ‘AssetFile’. [Case Link](https://hashfuture.io/static/data/Term.pdf)
+
+LegalFileHashValue: indicates the effective registration of the Token-based mandatory delivery (TBD) agreement. According to the binary data of ‘LegalFile’, applying the ‘legalFileHashType’, generate the untampered ‘legalFileHashValue’.
+
+### Asset Trading Management
+The Asset token has an ETH-denominated price specified at initialization, with a 'tradeable' status set to false.
+Only the owner can change the 'tradeable' status and set the asset price by calling the function:
+
+```solidity
+function setTradeable(bool status) public onlyOwner onlyValid onlyUnissued;
+
+function setAssetPrice(uint newAssetPrice) public onlyOwner onlyValid onlyUnissued;
+```
+
+If 'tradeable' is set to true, anyone can acquire the ownership of the Asset token by sending ETH to a payable function:
+
+```solidity
+function buy() public payable onlyValid onlyUnissued;
+```
+
+This function requires 'valid' and 'unissued' status.
+
+### Asset Ownership Management
+The owner of an Asset token can transfer the ownership to another holder under 'valid' and 'unissued' status.
+
+```solidity
+function transferOwnership(address newowner) public onlyOwner onlyValid onlyUnissued;
+```
+
+### Asset Cancellation
+The cancellation is tightly related to the 'onlyValid' modifier.
+After cancellation, the Asset token enters 'invalid' status.
+Only the owner can execute the cancellation function once after the smart contract is initialized, under unissued and valid status.
+This operation is not reversible.
+
+```solidity
+function cancelContract() public onlyOwner onlyValid onlyUnissued;
+```
+
+### Key Issuance Management
+The holder of an Asset token can issue a fixed number of Asset keys, specifying a buy-back price, an initial Asset token distribution in the meantime.
+Note that the buy-back price is stable-token denominated.
+
+```solidity
+function issue (uint _supply, uint8 _decim, uint _price, address[] _address, uint[] _amount) public onlyValid onlyOwner onlyUnissued;
+```
+
+This operation requires 'valid' and 'unissued' status and can only be executed by the owner.
+
+
+After issuing, Asset keys appear and are compatible with ERC20 standards:
+
+
+```solidity
+/**
+ * Standard ERC 20 interface.
+ */
+contract ERC20Interface {
+    function totalSupply() public constant returns (uint);
+    function balanceOf(address tokenOwner) public constant returns (uint balance);
+    function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
+    function transfer(address to, uint tokens) public returns (bool success);
+    function approve(address spender, uint tokens) public returns (bool success);
+    function transferFrom(address from, address to, uint tokens) public returns (bool success);
+
+    event Transfer(address indexed from, address indexed to, uint tokens);
+    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
+}
+```
+
+If a holder collects all Asset keys, he/she can convert them into the original Asset token by executing the 'convert' function:
+```solidity
+function convert() public onlyValid onlyIssued;
+```
+This function requires that the Asset token is 'issued' and the executor (i.e, msg.sender) has all the Asset keys.
+
+One can forcibly collect Asset keys from given holders by calling the 'collectAllForce' function at the buy-back price, if guaranteed that he/she has approved enough stable token to this contract.
+However, due to the gas limitation of Ethereum, he/she cannot collect all Asset keys with only one call. Hence an agent that can be trusted is needed.
+The operator is such an agent who will first receive a request to collect all Asset keys, and then collect them with the stable tokens provided by the claimer.
+
+```solidity
+function collectAllForce(address[] _address) public onlyOperator;
+```
+
+### Asset Dividends Management
+If the real-world asset gains income and the corresponding Asset token has been issued, then the dividends will be distributed to holders of Asset keys according to their shares.
+The dividend is denominated by the designated stable token.
+To distribute dividends, one can call the 'distributeDividend' function, if guaranteed that he/she has approved enough stable token to this contract.
+In addition, due to the limitation of Ethereum, one might not be able to distribute all dividends to all holders by one call, people can call 'partialDistributeDividend' instead, which specifies the amount and corresponding holders to distribute to.
+
+```solidity
+function distributeDivident(uint amount) public;
+
+function partialDistributeDivident(uint amount, address[] _address) public;
+```
+
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+The Asset token standard expresses the uniqueness of assets, similar to the exclusive characteristics of ERC721, and promotes the mutual conversion between Asset token and Asset keys. Asset keys keep backward compatibility with ERC20.
+
+Based on the asset information documents and legal agreements, a bridge linking the real asset in the physical world and tokens in the blockchain world will be established. Compliance with the legal agreements under the laws and regulations of various countries will help holders of Asset token or keys to obtain the rights and interests of real assets appreciation and dividends in a legal and compliant manner. At the same time, Asset keys will be given the voucher of asset consumption and VIP services, which will facilitate their circulation in the real world.
+
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+Asset keys can be regarded as standard ERC20 tokens, which can only exist after the Asset token is issued.
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+Please check the link repository for the Process of Asset Tokenization test suite
+[Link](https://etherscan.io/address/0x565b7bd8056322f96dac28345245aead44f24ff2)
+
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+The implementation is available in the repo: link.
+[Link](https://etherscan.io/address/0x565b7bd8056322f96dac28345245aead44f24ff2)
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).