The OneAlto Token (O-Token ) Standard. Version February 28, Abstract

Transcription

1 The OneAlto Token (O-Token ) Standard Version February 28, 2019 Abstract OneAlto is building a decentralized compliance protocol to standardize the way cryptosecurities are issued and traded on blockchains. The first project is O-Token, an open-source standard that defines a mechanism in which crypto-securities can be compliantly transferred on blockchains. It requires issuing a permissioned ERC-20 token on the Ethereum blockchain that checks an on chain Regulator Service for trade approval. The Regulator Service can be configured to meet relevant securities regulations, Know Your Customer (KYC) policies, Anti-Money Laundering (AML) requirements, tax laws, and more. The O-Token Standard enables ERC-20 tokens to become compliant crypto-securities that can be traded across any ERC-20 compatible platform. 1. Introduction Blockchain technology created an immutable ledger with the potential to transform the private securities market. The technology can simplify transfer of ownership, create transparency, reduce administrative burden, and provide opportunity for greater liquidity. With liquidity, investors have the flexibility to sell private securities for an efficient market price, increasing marketability and unlocking greater potential asset value for issuers. There are many asset categories that can benefit, including real estate assets such as limited partner (LP) interests in real estate investment funds, fractional ownership in land/buildings, and private REITs. Liquidity, however, also brings significant regulatory challenges to issuers and investors. Private securities must fall under exemptions with applicable laws to avoid onerous public filing requirements. These exemptions can require limiting the number of total investors, only allowing specific types of investors (e.g. accredited investors), implementing a holding period, and applying many other rules. Restrictions differ by jurisdiction, and compliance with both the issuer s jurisdiction as well as each investor s jurisdiction is mandated. Furthermore, these

2 restrictions apply not only to the initial offering (where much of the responsibility lies on the issuer), but to all secondary trades where responsibility is also placed on the seller. In the U.S. alone, private securities must fall under exemptions within the Securities Act of 1933 as well as the Securities Exchange Act of 1934 and in some cases, the Investment Adviser Act of 1940 and the Investment Companies Act of 1940 to avoid public filing and other costly and operationally prohibitive requirements. For example, in many cases, an owner of LP interests in a real estate investment fund can rely on Section 144 of the Securities Act of 1933 to conduct secondary trades. This would require the seller to comply with a one year holding period or trade with only a Qualified Institutional Buyer under Rule 144a.[5] In addition, the issuer of the initial offering must also continue to be exempt under the Securities Exchange Act of 1933, the Securities Exchange Act of 1934 and the Investment Companies Act of 1940, which may, among other things, require limiting the number of accredited and non-accredited investors.[6] Enforcing these regulatory requirements has been a significant deterrent in the adoption of blockchain technology for private securities issuances. In this paper, we propose a solution to this compliance challenge using the O- Token Standard. By implementing the O-Token Standard with the right rule set, private securities can be traded on blockchains in compliance with regulatory requirements. 2 The O-Token Protocol Ecosystem OneALto believes the Digital Securities ecosystem will be very diverse, due to the enormous size, varied nature and specific vertical requirements of the securities market. OneALto aims to enable this diversity by using a model that will facilitate the flexible development of specific implementations for certain elements, an ecosystem of OneAlto Apps.

3 The main elements in this ecosystem are: O Tokens: ERC-20 compliant tokens, extended with the capabilities of the O Protocol. O Apps: Smart Contracts designed to manage specific lifecycle events for a Digital Security. Examples for this are issuance O Apps, exchange-specific O Apps, voting rights O Apps or dividend issuance O Apps. O Services: The basic infrastructure of the O Protocol, enabling lifecycle management and compliance to O Tokens. O Apps can access these services to fulfill their goals. The O Services include: Trust Service: managing the relationships between the different stakeholders. Registry Service: an on-chain register of investor information. Compliance Service: which implements specific compliance rules applicable to a O Token as per the Issuer requirements. Comms Service: enabling communication of relevant events to investors. To improve the investor experience, OneALto s platform extends the O Protocol with the Ready For Exchange (RFE) off-chain API. This API will enable Exchanges to integrate into the Digital Securities ecosystem in a simple way that also improves the customer experience for investors. For instance, it will enable the sharing of KYC information between the issuer to the authorized Exchanges, not shared on-chain due to privacy constraints. This is useful for the Issuer to be able to maintain the cap tables for investors and for exchanges to provide a contact mechanism information to the issuer (e.g., an ) so that relevant lifecycle events can be notified. Additionally, there are some REST APIs that allow access to specific information about the investor pool (e.g., allocation of investors of a certain category according to regulation), so that they can provide the right user experience in their investor dashboards. The following figure shows a high-level representation of the different elements in the O Protocol Ecosystem: OneALto s O Protocol Ecosystem In the next sections, the different components in this ecosystem will be described. Subsequently, we will illustrate several user journeys that will clarify the flows involved during the Digital Securities lifecycle. 3 The O Token

4 The O Token is an ERC-20 compliant token that also implements the additional hooks required by the O Protocol. As per this ERC-20 specification, the O Token contract can be queried to get the balances of tokens for specific wallets or the total supply available for the token. To address regulatory compliance, the token contract has its transfer() and transferfrom() methods overloaded so that they check via the Compliance Service if tokens can be exchanged between specific wallet addresses. Besides the ERC-20 methods, the O Protocol adds methods for issuers being able to block wallets, or freeze the token due to a regulatory requirement. It also provides methods for O Apps to be able to iterate through the investor list to execute their services, like dividend issuances. Issuers of Digital Securities may create their own specific O Token implementing the O Protocol, usually through an issuance O App or a O Issuing Platform, like OneALto s white-label platform. The use of the O Protocol standardizes the interaction between the token and other Smart Contracts. These Smart Contracts offer the additional securityfocused capabilities required for issuers, investors and exchanges during the Digital Security 4. The case for tokenizing private securities One of the primary reason for issuing private securities is the relative ease and costeffectiveness of the initial issuance. However, secondary trading of private securities often requires various middlemen (such as brokers and exchanges).[8] In addition, the process for tracking trade activity is manual and costly, and there is a significant burden on issuers to safeguard against potential regulatory risk.[9] These inefficiencies can often lead to issuers imposing trade restrictions, making private securities illiquid. To account for the lack of liquidity, the value of private securities is discounted (i.e. the illiquidity discount ), preventing issuers from capturing the full value of the underlying asset.

5 In comparison, public securities can have deep markets and high liquidity, as non-controlling holders can generally resell them freely. However, it is time and cost intensive to IPO and remain a public company. The process to complete an IPO is complex and can often require 12 to 18 months of preparation. Significant costs apply not only to the offering itself, but also to the ongoing process of being a public company, including rigorous regulatory and reporting requirements. In other words, the cost-effectiveness of public securities is low compared to private securities. By tokenizing private securities, we can potentially move them from the Low Liquidity/High Cost-Effectiveness quadrant to the Higher Liquidity/Higher Cost- Effectiveness quadrant, as illustrated in the chart below. Tokenized private securities (i.e. cryptosecurities) can be more easily traded on the secondary markets without the administrative burdens of traditional private securities. In other words, tokenized private securities can potentially have more liquidity while maintaining their cost-effectiveness. High Public Securities Token Liquidity Move Liquidity Low Private Securities Low Cost Effectiveness Figure 1: Liquidity versus cost effectiveness of securities and tokens. High Given that the asset categories within the private securities market are massive (in the trillions), and that the illiquidity discount can be as high as 20-30%, the tokenization of private securities has the potential to unlock billions of dollars in value.

6 In addition to providing liquidity, tokenizing private securities creates opportunities for greater efficiency. Blockchains enable trades to occur securely between two parties without a middleman. It is an immutable ledger where every transaction is automatically recorded and easy to audit. The process and timeline for settlement and clearing of transactions can also be condensed significantly, and any reconciliation processes can be greatly simplified. Tokenizing private securities has the potential to significantly reduce costs, increase speed of settlement, and improve security. It is compliance with regulatory requirements that now must be addressed in order to enable 3 the adoption of securities on blockchains and transform the private securities market. 5. Real Estate Among the various categories of private securities, tokenizing real estate assets may provide a particularly compelling opportunity. As of 2016, the value of professionally managed global real estate alone was $7.4 trillion and all developed real estate globally amounted to about $217 trillion. The US real estate market also continues to be attractive to foreign investors due to its relative stability, fueled by multiple years of steady job growth and a strengthening economy. This provides global investors with the ability to diversify their portfolio and generate returns outside of their country of origin. Real estate assets have additional legal requirements (on top of the already complex securities regulations) that must be enforced, making it a great candidate for tokenizing on blockchains. For example, a private domesticallycontrolled Real Estate Investment Trust (REIT) restricts non-us investors from collectively owning more than 50 percent of shares, allows a maximum of five individuals to collectively own more than 50 percent of shares, and requires a minimum of 100 direct shareholders. In addition, under the Foreign Investment in

7 Real Property Tax Act of 1980 (FIRPTA), foreign investors of these private domestically-controlled REITs are subject to 30% withholdings on dividends. 6 O Apps The O Apps are additional Smart Contracts that can be registered with a O Token and invoked based on their own interface to trigger a specific lifecycle event. Typically, a O App developer will provide some front-end interface to the issuer to manage the execution of this given app. For instance, O Tokens, whether acquired on issuance or via a secondary trading through a Security Token Exchange (STE), may convey additional rights or require some specific additional capabilities depending on their underlying asset. Certain tokens may provide governance rights or have payback mechanisms associated with them. To this end, as part of the O Protocol, it is possible to associate different O Apps to a O Token, which can provide such additional value for token holders. The user journeys section includes specific examples of lifecycle events and how their O Apps would work within the O Protocol. 7 Trust Service A key component in the O Protocol is the Trust Service. The Trust Service is used by the rest of the components in the O Protocol architecture to ensure that a given actor or O App is allowed (in general by the issuer) to take a certain action. Relevant examples of actions controlled by the Trust Service are: Using multiple Ethereum addresses in the Issuer role, but with different levels of permissions. For instance, several addresses may be allowed to add investor information to the Registry Service, but only a specific one can manage registry federation. Authorizing an Exchange to introduce additional entries into the Registry Service. Given that the model in the O Protocol delegates gathering KYC and investor accreditation information to exchanges for new investors, only trusted Exchanges will be authorized to do this. Authorizing a specific O App to use some of the

8 protocol capabilities, such as the Comms Service to be able to send communications to investors. To simplify the example flows in the user journeys section, the Trust Service will not be included in the diagrams. The assumption is that all actors involved have been previously authorized to do the different functions presented. 8 Registry Service The Registry Service holds an on-chain register of the investors that hold a given O Token. Each investor is identified by a unique ID, built from a hash of personal information that allows identification in a privacy-safe way, and includes the following information: Investor Country for regulation purposes Investor KYC status Investor Accreditation/qualification status Investor KYC expiry date Investor Accreditation expiry date Investor KYC information hash Investor Accreditation information hash Both Issuers and Exchanges roles can interact with the Registry Service to create investors and associate investors to specific wallets. In particular, the Registry Services will support assigning several wallets to the same investor, so that investors can manage their token allowances in a flexible way. An additional, non-unique ID hash (for instance, based just on the investor name and birth date) may be also held in the registry to raise situations in which the same investor may have been registered twice using different identification documents. In those situations, specific methods will allow the Registry Service owner to merge investor entries into a single registry. This case is particularly relevant when several entities are providing customer identification (for instance, the issuer and exchanges), and there are limits on the number of investors supported for a certain category (for instance, a limited number of U.S. investors), which may require avoiding double-counting of the same investor. The Registry Service allows a federation model, by which if a match is not found for a specific investor query, it can, in turn, propagate the query to a different investor registry.

9 9 Compliance Service The Compliance Service will handle the transfer() and transferfrom() validation calls from the O Token contract. It will check the sender and receiver address in the Registry Service and will enforce the constraints applicable to a given issuance. For instance, a fund issuer may want to limit its presence in the U.S. to just 99 accredited investors. Alternatively, an issuer following Reg S may require preventing flow-back from non-u.s. to U.S. investors. These rules will be enforced by the Compliance Service, allowing or rejecting specific token transfers. To facilitate adherence to the specific requirements of an issuer for compliance, the Compliance Service will also be responsible for storing and updating data that can be required for allowing a transfer to happen. This will be very specific to the Digital Security and the regulatory context for issuance and trading. Examples of information that a given Compliance Service may store and update are: Investor-specific information, like their adherence to a subscription agreement or the hash for the signed agreement document. Number of investors for a certain category, for instance non-qualified investor from a certain country. Number of trades that have occurred in a certain period 9.1 Additional Compliance Support For certain classes of assets, it may be required by the applicable regulation that a token holder be able to get their tokens re-issued in case they have lost access to their previous wallet. The Compliance Service is also responsible for allowing or preventing the issuer to allow such reissuance. 10 Comms Service During the lifecycle of a security investment it is important to be able to provide information to investors. This way, token owners can be aware of liquidity events,

10 governance events, or any other relevant aspects that are a fundamental part of a Digital Security lifecycle. During the initial issuance through a O Issuance Platform, information to communicate with investors (e.g. an address) can be gathered. But this information may not be available to the issuers for new investors accessing the tokens through exchanges in the secondary market. As described above, the RFE (Ready For Exchange) API may also be used by exchanges to share this information with the issuance platform; but to avoid those dependencies at the protocol level, the O Protocol includes the Comms Service. The Comms Service does not make any assumption on what other communication means may be available off-chain and is defined in a generic way, accepting messages addressed exclusively to Ethereum addresses. This allows the flexibility of different implementations of the Comms Service supporting different modes of integration with specific issuance platforms or investor wallets. Access to the Comms Service functions is controlled via the Trust Service, so that it cannot be abused by non-trusted applications to send potential spam to investors. The usage of the on-chain Comms Service also provides auditability to all the content and communications that an Issuer has shared with an Investor, that will have an immutable registry for them. The choice to use a specific implementation for a communication service instead of relying on existing native capabilities in the Ethereum network has been based on its fitness to purpose. Whisper messaging is not being used because by design its goal is to provide dark comms, while for the Comms Service an auditable store for messages is required. Also, using Swarm for that purpose is not adequate due to its maturity level. As new capabilities are supported and mature enough in the Ethereum network, it may be possible to have the Comms Service rely on them. For instance, it is possible that in the future the Comms Service will use the native Whisper and

11 Swarm technologies offered by the Ethereum network as their feature-set and maturity match the Comms Service needs. 11. Service Registry The Service Registry provides the O-Token smart contract with a mechanism for locating the current, correct, or desired version of the Regulator Service. Figure 4 illustrates the interaction between the O-Token, Regulator Service, and Service Registry. The Service Registry provides the appropriate Regulator Service address to the O-Token; the O-Token then checks with the given Regulator Service to obtain trade approvals. When a new version of the Regulator Service is introduced, the Service Registry provides the updated Regulator Service address to the O-Token. This ensures that the correct Regulator Service is used for trade approval. See Figure 5. Note: The O-Token Standard provides an interface that developers can use to implement custom business logic. Other implementations of the Service Registry could allow for multiple Regulator Services to exist at once, making it possible to decentralize the Regulator Service. Regulator Service Address Service Registr y ref O-Token Check() Reason code Regulator Service Figure 4: Interaction between the O-Token, Regulator Service, and Service Registry.

12 O-Token Regulator Service Address Service Registr y Regulator Check() ref Service V1 Reason code Regulator Service V2 Figure 5: Interaction between the O-Token, Service Registry, and Regulator Service when a new Regulator Service is introduced. 12. Trade Controller The initial implementation of the Regulator Service relies on an off-chain Trade Controller to update its permissions as well as add newly approved participants. The Trade Controller determines the status of the permissions. It maps participant data against relevant securities regulations, KYC/AML policies, and tax laws to determine whether each participant can send and/or receive the token. It also determines whether the token is locked/unlocked and whether partial trading is allowed/disallowed. These token-level permissions are then updated in the Regulator Service. Only an approved Trade Controller with the correct private/public key pair can make changes to the Regulator Service.

13 Note: OneAlto will be the first Trade Controller for the initial implementation of the O-Token Standard. Planned implementations will allow for decentralization of this role. 13. Conclusion We propose an open-source standard for compliantly transferring cryptosecurities on blockchains. With the O-Token Standard, every transfer occurs if and only if they are approved by a Regulator Service. The Regulator Service houses the permissions necessary for regulatory compliance and relies on an off-chain Trade Controller to set and update these permissions. To account for changes to the regulatory landscape over time, we also propose the use of a Service Registry for easier upgrades. Implemented with the right rule set, the O-Token Standard enables ERC-20 tokens to become compliant crypto-securities that can be traded across any ERC-20 compatible platform. This is the first step in developing a decentralized compliance protocol for crypto-securities. It addresses core challenges of transferring private securities on blockchains, bringing us one step closer to the proliferation of crypto-securities.