Security Token Standards

The core requirements that drive security tokens

The tokens that will be issued as part of the DAO belonging to each Asset on the platform, can be directly correlated to the value of the asset which will act as a collateral. Hence there is a very high chance that from the regulatory perspectives, these tokens will be treated as securities.

Hence we are now working towards compliance using a bottom up approach to match the existing security token standards and apply to the area of fractional real estate.

Objective

The creation of specification will increase adoption by allowing third party integration in a standard way and lower friction and cost of off-chain processes that may be required for compliance purposes.

The standardisation would also allow for the on-chain actions to be according to the real world requirements for investors geared towards creating a more safe, secure and interoperable world.

The standardisation will allow building on top of these definitions and extend this framework to be future proof.

Introduction

Moving the issuance, trading and lifecycle management events of a security onto a public ledger requires having a standardised way to model ownership via identity and equity ownership tokens.

A security token requires the following features: Ability to associate metadata with specific securities which are otherwise fungible Flexibility in permissions and control Ability to moderate transfers of securities using either on-chain codified rule set or off-chain approvals Association of public data to the security (issuer details, legal documentation)

Requirements

Following requirements have been found after discussions with parties of security token ecosystem

• MUST have a standard interface to query if a transfer would be successful and return a reason for failure.

• MUST be able to perform forced transfer for legal action or fund recovery.

• MUST be able to emit standard events for issuance and redemption

• MUST be able to attach metadata to a subset of a token holder’s balance such as special shareholder rights or data for transfer restrictions.

• MUST be able to modify metadata at time of transfer based on off-chain data, on-chain data and the parameters of the transfer.

• MAY require signed data to be passed into a transfer transaction in order to validate it on-chain

• SHOULD NOT restrict the range of asset classes across jurisdictions which can be represented.

Partially fungible Token

This allows owners token balances to be divided into any number of tranches.

These tranches can be associated with securities metadata for that tranche.

Additional benefits or features can be associated with token ownership within certain tranches - for example special rights associated with primary token issuance (STO).

The metadata associated could be use to record additional data about groups of securities that can be used for transfer restrictions, reporting, authorisation, authentication and other lifecycle events.

Signed Irreversible Decisions

This provides a structure for an authorised entity (e.g legal enforcement agencies) to enable revoking of permissions and that this revocation is permanent.

For example, if there is a dynamic decision made to restrict the number of tokens minted to be capped, this should be enforceable via this standard.

Restricted Transfers

Transfer of security tokens can fail due to lack of different real world requirements. For example lack of authZ/authN, time period mentioned as lock-in period etc. Thus different layers related to security, authentication and other parameters.

For utility tokens balanceOf and allowance functions provide a way to check that a transfer is likely to succeed before executing the transfer and for security tokens checkSecurityTokenSend function can be introduced to check the different metadata related and other external constraints related to the transfer.

In order to provide a richer result than just true/false, a byte return code is returned. This way additional log information about the transfer can be inferred ,and should show the reason/class for failure.

Identity

Whether an individual is able to receive and send securities will likely depend on the characteristics of the individual entity. For example after a KYC/AML checks an investor may be categorised as an accredited investor or otherwise. That information may qualify / disqualify him to invest in certain assets.

We will finally (phase 2 or later) rely for authentication / authorisation based on on-chain data regarding the individual.

Security Information

When an asset is issued it may be useful or required to associate documents with it. This could be details of purchase deed , title deed, insurance on title and asset etc. These documents (public) can be associated with a unique URL based on the document hash (as used in IPFS) or for private documents may be encrypted and permissioned cloud storage.

Disclaimer:

Please distinguish these tokens from REIT platform token, which is considered as a governance and utility tokens for the Reitcircles platform.