ERC1540: Asset Token Standard

[hack1t]

---

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: #1553
status: Draft
type: Standards Track
category: ERC
created: 2018-10-25
requires: 20

Simple Summary

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

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

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” will be refrained.

Specification

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.

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

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

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:

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:

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.

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.

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.

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:

/**
 * 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:

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.

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.

function distributeDivident(uint amount) public;

function partialDistributeDivident(uint amount, address[] _address) public;

Rationale

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

Asset keys can be regarded as standard ERC20 tokens, which can only exist after the Asset token is issued.

Test Cases

Please check the link repository for the Process of Asset Tokenization test suite
Link

Implementation

The implementation is available in the repo: link.
Link

Copyright

Copyright and related rights waived via CC0.

[Axejiang]

Feedback about this proposal is appreciated.

[davesag]

I have a number of questions about this but first I think there are some issues with the use of wording that need to be fixed.

Firstly the past tense of 'split' is also just 'split' not 'splitted' which is not a word. References to onlySplitted and onlyUnplitted need to be changed to onlySplit and onlyUnsplit.

Secondly there is no such word as 'divitent'. The author means 'dividend' so functions like distributeDivident and partialDistributeDivident need to be changed to distributeDividend and partialDistributeDividend respectively.

setassetPrice should be setAssetPrice.

I appreciate that the author is likely not a native English speaker and this in no way implies a criticism of the author, however I do think that the whole proposal needs going over by someone with a stronger grasp of English as it's quite hard to make sense of. I'd also like to see the Author's GitHub profile fleshed out as right now it's very anonymous. (That's just a personal preference however)

The profit from the asset appreciation will be distributed to the holders of small tokens.

What about losses in the case where the real-world asset loses value or is destroyed?

As the 'big' token and 'small' derivative tokens are all ERC20 tokens, what happens if the tradable value of the 'big' token diverges from the underlying asset value?

What happens if the value of the small tokens diverge to the point that they no longer sum to the value of the big token?

Can a small token also be split? (Is this recursive?)

What happens to the small tokens if the owner of the big token loses their address / keys and is thus prevented from interacting with the big token again (say due to hard drive crash or loss of hardware wallet, or some other disaster outside of the control of the owner of a small token)?

What's to stop a fraudulent actor from splitting a big token, selling the small tokens, then just absconding with the money?

One can forcely collect small tokens from given hoders by calling the 'collectAllForce' function, guaranteed that he/she has approved this contract enough stable token to by the small tokens at the buy-back price.

How would this actually work in an implementation?

How does the big token keep track of who owns the small tokens?

As an owner of a small token, how do I know which big token my small token is part of?

What about assets that have on-going storage costs such as whisky barrels, rare metals, or frozen concentrated orange juice? How are the on-going storage costs apportioned to the owners of the small tokens?

I have many more questions but these are the first things that spring to mind when I read the proposal.

[mudgen]

@hack1t What do you think of the idea of implementing ERC1540 using an upgradeable, transparent contract as given in ERC1538?

[hack1t]

@hack1t What do you think of the idea of implementing ERC1540 using an upgradeable, transparent contract as given in ERC1538?

That would be a nice feature if the contract is transparently upgradeable!

[apguerrera]

The reference implementation links appear to be incorrect?

[Axejiang]

The reference implementation links appear to be incorrect?

Much thanks for your comments!
The reference implementation links just a case, defining a smart contract legally representing the ownership and corresponding privileges of a real-world asset.

Key Issuance management, collectAllForce, and other functions have been described as above, the totally complete implement would be done if necessary.

[Axejiang]

I have a number of questions about this but first I think there are some issues with the use of wording that need to be fixed.

Thank you for your kind feedback, very helpful!
The 'big' token changed into 'Asset token',
The 'small' token changed into 'Asset key',
The 'split' changed into 'issue'.

Firstly the past tense of 'split' is also just 'split' not 'splitted' which is not a word. References to onlySplitted and onlyUnplitted need to be changed to onlySplit and onlyUnsplit.

Secondly there is no such word as 'divitent'. The author means 'dividend' so functions like distributeDivident and partialDistributeDivident need to be changed to distributeDividend and partialDistributeDividend respectively.

setassetPrice should be setAssetPrice.

I appreciate that the author is likely not a native English speaker and this in no way implies a criticism of the author, however I do think that the whole proposal needs going over by someone with a stronger grasp of English as it's quite hard to make sense of. I'd also like to see the Author's GitHub profile fleshed out as right now it's very anonymous. (That's just a personal preference however)

Thank you very much for your contribution. We have revised the proposal and submitted it to the native English speaker for revision and improvement. I hope to help you read and understand.
Author's GitHub (McGrady00H, @hack1t, etc.)

The profit from the asset appreciation will be distributed to the holders of small tokens.

What about losses in the case where the real-world asset loses value or is destroyed?

First, when the assets are on the chain, we will evaluate the reliability of the assets. Second, after the assets are on the chain, the physical assets need to be mortgaged on a third-party platform, which may be the government, the bank, or other institutions in the industry; Mainly to reduce the probability of asset loss. In the event of accidental accidents, physical assets are lost or damaged, all Token\key holders may be forced to pay or claim under the Token-based mandatory deliver（TBD) Agreement.

As the 'big' token and 'small' derivative tokens are all ERC20 tokens, what happens if the tradable value of the 'big' token diverges from the underlying asset value?

The Asset Token ('big' token) is not ERC20, more similar to the Non-Fungible Token Standard ERC721.

What happens if the value of the small tokens diverge to the point that they no longer sum to the value of the big token?

In the event of a fork, the chain-service provider needs to publicly declare which chain's contract assets are recognized for the first time.

Can a small token also be split? (Is this recursive?)

For the time being, we have not considered the lock-in and split of the Asset key (small token). At present, we mainly design it into primary and secondary assets. In the future, there may be recursive asset-winding. For example, more than a dozen houses are linked together, and each house is Non-Fungible smart contract, Split the smart contract, each contract can be split into Fungible Token ERC20.

What happens to the small tokens if the owner of the big token loses their address / keys and is thus prevented from interacting with the big token again (say due to hard drive crash or loss of hardware wallet, or some other disaster outside of the control of the owner of a small token)?

If the private key is lost, it may not be possible to provide a recovery task. However, If a holder collects all Asset keys, he/she can convert them into the original Asset token by executing the 'convert' function.

This is the first section of the reply, the next question, as soon as possible to give you a continuous reply, thank you for your guidance！

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[davesag]

@Axejiang how is progress on this spec?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.