Projects:2017s1-167a Applications of Blockchain to Equity Fund Raising

Project Members

• Ayden Aba
• Jackson Virgo

Project Supervisor

Dr Matthew Sorell

Introduction

Bitcoin’s underlying technology, the blockchain, or the distributed consensus ledger, has allowed mutually distrustful parties to securely transact virtual currency stored on a decentralised database with minimal time expense and financial friction, effectively eliminating the need for a trusted intermediary. The realisation that this technology can be more broadly applied to other digital assets led to the advent of smart contracts; an agreement whose execution is both automated and enforced by the cryptographic consensus of the distributed ledger.

This revelation bares significant ramifications for the financial services industry. In particular, blockchain technology presents an opportunity for emerging companies to undercut the large industry incumbents who have enormous amounts of capital tied up in traditional methods of transacting and storing financial information.

However, before blockchain can be integrated into existing businesses, the risks of the technology need to be explored and further understood. For instance, the recent security breach of an Ethereum blockchain application, “The DAO”, in July 2016 saw the equivalent of USD$50 million in cryptocurrency at stake, highlighting the pertinence of research into blockchain.

This case reminded investors that, whilst theoretically sound, exploits in the underlying technology are still possible, and a single such security vulnerability can expose all the users of an entire blockchain network. Considering cryptocurrencies and blockchain applications are expect to become the new fabric of trade and commerce, this uncertainty is alarming.

Through our research into applications of blockchain within crowdfunding, we hope to further understanding of how the technology may be realistically and securely integrated into existing businesses, and society more broadly.

Objectives

The overarching objective of our research team is to distil a more accurate picture of blockchain’s utility from the noisy aggrandizement that has characterised a lot of discussion around its potential. By investigating the application of blockchain technology within the Australian unlisted securities market, we aim to examine various cyber security issues, and societal acceptance issues, to be faced during the transition toward crypto-asset based economies.

Motivations

From ASSOB market research, it is understood that there is a demand for growth capital amongst small innovative businesses, as well as a demand for investment in such businesses. Current mechanisms for facilitating this form of investment are high-friction and do not scale well; ASSOB's current business process is one such mechanism, others include angel investment and venture capital investment. As a result of changing legislation and market demands, businesses like ASSOB must be capable of processing large volumes of transactions quickly and securely, ideally with minimal human interaction.

Blockchain may present a viable solution to the unlisted equity investment transaction problem, smoothing the flow of investment capital from investors to the companies that need the capital. The flow-on effects of this are outlined as follows:

• if innovative small business are able to attain expansion capital at a lower cost and faster than previously possible as a result blockchain applications, more innovative small business are able to succeed and the level of innovation overall is increased
• with more innovation and small business growth, economies are stimulated

Blockchain technology applied within businesses such as ASSOB has the potential to improve the utilisation of available investment capital within the economy. Instead of investor dollars being wasted on middle-men and administration costs, a higher proportion of investor dollars actually get delivered to the businesses seeking investment.

Approach

Design Framework

We define, the System (or System) as the abstract object (or black-box) which facilitates ASSOB's Initial Share Application Process. The System is described via the System Functional Requirements.

We then go on to define a Solution as a specific way of meeting the System Requirements. Solutions are categorised into what we define as Classes. The set of all solutions is referred to as the Solution Set.

We have defined three mutually-inclusive Classes of Solutions:

• Blockchain
• Conventional Digital
• Analogue

Where a particular Solution sits within multiple Classes, the Solution is categorised as Hybrid.

The below figure illustrates the Solution Set:

The purpose of defining a clear framework is to allow us to apply a more heuristic approach to developing a cohesive Solution for the Client. A heuristic approach is beneficial as it minimises the risk of tunnel vision throughout the design process. This is due to how we have structured out research framework which (within our defined typeology) recognises that there are solutions that exist outside of the blockchain paradigm.

Research Process

Within the context of the design framework, we are attempting propose a blockchain solution which meets the System functional requirements. The way in which we will move from functional requirements to a practical Solution is outlined in the following flowchart:

Functional Requirements

Application Verification Requirements (AV)

ASSOB Application Verification [AV001]

The System must be able to verify ASSOB Component of Share Applications.

Anti Money Laundering (AML) Application Verification [AV002]

The System must be able to verify the Anti Money Laundering (AML) Component of Share Applications.

Value Transfer Requirements (VT)

System must be able to track value flow (flow tracking) [VT001]

The System must be able to track value. This means be able to know when Investors have sent money to the 3rd Party Trust account. Furthermore the System must be able to control the flow if this value as outlined by requirements VT002 - VT005.

Value Transfer from Investor to Issuer (forwards flow) [VT002]

This is the default flow of value. The System must be able to facilitate the transfer of value from Investors to Issuers.

Halt Value Transfer, either direction (halt flow) [VT003]

In the event that there is fault in the Transaction Process, the System must be able to halt the flow of value until the fault is resolved. A fault may be an issue with Share Application, or oversubscription of the capital raise for example.

Refund Investor (reverse flow) [VT004]

In the event that the Investor withdraws their Share Application as a result of a fault, or the Share Application must be rejected by ASSOB, the System must be able to return value back to the Investor. Furthermore an Investor may want to withdraw their Share Application within the allowed cooling off period (2 days currently, 5 days under new legislation) because of a change in decision.

Distribute Value as Commissions or Fees (split flow) [VT005]

The System must be able to control value flow to the point where it can split inputted Investor value into value distributed to the Issuer, value distributed to ASSOB (as commission) and value deducted for the owner of the System. The value deducted for itself as fees may end up being delivered to ASSOB eventually though, depending on who has ownership of the System.

Registry Handling Requirements (RH)

Share Registries are updated to reflect successful Share Applications within 28 days [RH001]

Transaction state changes must be reflected in the share registry within the time frame required by ASIC (28 days).

Share Registries are Immutable [RH002]

The information contained within a share registry must only be changeable by a valid transaction completion within the system. The ledger should only ever change in response to the addition of new transactions, or the revocation of previous transactions by the system.

Share Registries are Permissioned [RH003]

Information contained with the share registry should only be accessible by appropriate parties. These permissions need to be determined.

Share Registries meet ASIC reporting requirements [RH004]

The specifications laid out here: http://asic.gov.au/for-business/running-a-company/shares/

Legally Tenable Artifacts Requirements (TA)

Compliant Share Certificates [TA001]

As part of transaction completion the system must be able to generate proof of the transaction’s occurrence in the form of a tangible artefact. This artefact should be legally tenable, meaning that in a dispute resolution scenario the the artefact would be recognised by the Law as evidence.

External Control and Interfacing Requirements (EC)

Data Piping [EC001]

Information contained within the system should be able to be communicated to external systems under certain conditions. The system should be able to receive data as an input to relevant process stages. The system should be able to receive external trigger events that can manipulate process control flow. For example, several stages in the share application require manual human verification. Therefore the system must accept input from an external source that approves next stage in the process to proceed.

Transactions are Manually Revokable [EC002]

In the event that the integrity of a share application transaction has been compromised, external controllers must be able to reverse the transaction such that the final system state is identical to the original system state before the transaction took place. That is to say, the final state of the system following transaction completion should reflect the current status of all verification stages, rather than the status of verification at the time the transaction took place. An external input should be able to trigger the revocation of the transaction under circumstances which information external to the system violates any of the requirements for transaction validity. For example, in the case that external information reveals the AML verification to be fraudulent, an external system must have the ability to trigger a transaction reversal.

The Existing Solution

Solution Map

The Ideal Solution

Solution Map

Solution Architecture

High Level Sequence Diagram

Validity of the Ideal Blockchain Solution

Does it solve the issues with the Existing Solution?

Through this work, it was highlighted that the two key issues with the Existing Solution were: 1. Centralised trust; and 2. High transaction friction.

Centralised Trust

Concerning centralised trust, the Existing Solution relied on the 3rd Party Authority to both hold funds in escrow and provide AML checks. Within Ideal Solution, the 3rd Party Authority is no longer required to perform fund escrow (we can escrow funds with smart contracts), however there is some degree of trust centralisation around the Attestation Authority. We trust that the Attestation Authority provides truthful Attestation Certificates. This is still an improvement over the Existing Solution however.

High Transaction Friction

Transaction friction is drastically improved with the Ideal Solution compared with the Existing Solution. We can illustrate this by comparing the number of manual processes in each solution.

Within the Ideal Solution, the only manual process is the Attestation Sub-process (see Section \ref{sec:attes-sub-process}), specifically at the point where the Attestation Authority verifies that the Investor's Personal Identification Information is truthful. Currently it is assumed that this must be carried out manually, be we may see automated processes in the future.

Comparatively, within the Existing Solution, all processes are manual, from the application verification, to transfer/release of funds to any required communications between involved parties.

Usability of the Ideal Blockchain Solution

Thus far, we have only considered the capacity of the Solution to meet functional requirments in a vacuum - the Ideal Solution has not yet been validated (is it usable or suitable?). One of the key issues with the Ideal Blockchain Solution is the usability of cryptocurrencies as a value transfer mechanism, as used in the Solution. In particular, the high price volatility of Ether renders Ether unusable as a long-term value store for investors or issuers.

Consider the following price chart of Ether over the past 3 months (23/07/2017 - 23/10/2017):

The average price of ETH was $288.25 USD, with a high point of $390.20 USD on the 1/09 and a low point of $184.89 USD on the 29/07.

To put this into perspective, if you were holding $1000 USD of ETH on the 23/07/2017, you would have seen your account balance in terms of USD go from $1000, to $823.75, to $1738.47 back down to $1023.08 on the 15/09, then finally back up to $1286.30 on the 23/10, all in the space of 3 months.

This level of volatility is impractical for any user holding Ether, for reasons which will be discussed in the following section.

Conclusions

The goal of this work was to discover if blockchain technology could realistically be applied to equity crowdfunding, and further explore its usage within the financial services sector whilst examining potential usability issues.

Blockchain technology presents an opportunity within the equity crowdfunding industry to improve transaction friction and transparency. As a result, innovating small businesses have the capacity to attain expansion capital faster and cheaper than previously possible. With a higher level of innovation overall, economies are stimulated by small business growth.

The research goals were approached through a system design and review process.

Firstly a set of functional requirements was defined and categorised. Following this, an Ideal Blockchain Solution was designed which met all functional requirements, making assumptions to do so where necessary.

By then applying more realistic conditions, a discussion around the value transfer mechanism and price stability of cryptocurrencies was constructed.

The two big accomplishments as part of this research were (1) the creation of a core set of System Functional Requirements for equity crowdfunding infrastructure, and (2) the development of an Ideal Blockchain Solution architecture.

Further to this, with respect to the Ideal Blockchain Solution which relied on cryptocurrencies to represent value in the System - a viable solution to the price volatility of cryptocurrencies problem was presented.

The set of System Functional Requirements, enables further work to be done in determining the effectiveness of equity crowdfunding solutions, whether they be conventional digital, blockchain or simply analogue. The Ideal Blockchain Solution (along with the price volatility workaround) shows that blockchain may have a place in improving equity crowdfunding, shown by how it elegantly meets System Functional Requirments. Furthermore, the Ideal Blockchain Solution acts as a starting point for a prototype System to be built.

Although this work shows that blockchain powered equity crowdfunding is technically possible and outlines the foundations to built it, it was found that numerous issues still exist in applying blockchain technology to equity crowdfunding from usability and investor protection perspectives. The end conclusion is that blockchain technology alone has limited usefulness in the equity crowdfunding space, and if it were to be applied today would still rely on more conventional digital infrastructure to be realistically feasible.