View source for 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:

[[File:Solution-venn-diagram_blank.png|center|400px]]

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:

[[File:Research-process-visualisation.png|center|600px]]


== 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 Ideal Solution ==
=== Solution Map ===
[[File:Ideal-solution-venn-diagram.png|center|400px]]

=== Solution Architecture ===
[[File:Ideal-solution-diagram.png|center|800px]]

=== High Level Sequence Diagram ===
[[File:Sequence diagram.png|center|800px]]

=== 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):

[[File:Eth 3-mth price.png|center|500px]]

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.

== Price Stability ==
=== "Fiat-Currency World" to "Future Crypto-Asset World" ===
We currently live in a world driven by fiat currencies. In this state
of the world, the need for crypto-assets is difficult to justify because at the
end of the day, users of the system must be able to convert their
crypto-assets into physical goods. For instance, in today’s fiat
currency environment you cannot directly purchase your groceries using
Bitcoins or Ether. The vendor will only accept a recognised fiat
currency, therefore a conversion from a crypto-asset to a fiat
currency needs to occur. 

A future crypto-asset world is a hypothetical state of the world where
all physical assets can be directly represented digitally as on
blockchain crypto-assets. i.e. in a crypto-asset world, you can
purchase your groceries using crypto-currencies such as Bitcoin or
Ether. 

Using this conceptual framework of two different states of the world
(present and future) and applying it to the developed ideal blockchain
solution, we can see that there is a disconnect in the value
transfer mechanism proposed and what is realistic under the present
"fiat-currency state" of our societies. 

Within the ideal blockchain
solution, value is represented and transferred using cryptocurrencies,
however in today's society this is not a reasonable solution for a
number of reasons:

1. '''Recognisability'''. For the most part, goods and services cannot be purchased directly in cryptocurrencies yet. In other words, cryptocurrencies have little real purchasing power.;

2. '''Volatility'''. It is unreasonable to expect investors to hold investments in companies in cryptos which have a volatile (i.e. risky) conversion rate to fiat currencies. Similarly for issuers who are exposed to massive conversion risk on their capital raised;

3. '''Poor Usability'''. Current mechanisms for converting between fiat and cryptocurrencies are cumbersome and involve significantly higher risks that working within the fiat currency eco system (e.g. what if funds are accidentally transferred to the wrong address). Large exchanges (Coinbase) have restrictions in how much cryptocurrency a user can purchase at one time. 

This work proposes that the key to solving these issues is price stability.
The following section will form a discussion around these issues.

=== What is currency stability? ===
According to ''Hayek Money (Ametrano, F.)'', money must have three essential
functions to be usable:

'''1: Medium of exchange''' - something that can be reliably swapped for something
else. Its virtues should include fungibility, transportability, divisibility,
recognisability, and resistance to counterfeiting;

'''2: Store of value -''' something that can be reliably saved, stored, and retrieved while
retaining its usefulness over time. It should be non-perishable or with a low
preservation cost. Often the store of value property is also presented as the
ability to retain constant value over time, but this ability is instead related to
being a good, i.e. stable, unit of account.

'''3: Unit of account -''' other goods, services, and assets are priced in terms of money. Money is the unit of measurement of relative worth, so it should have stable value allowing for stable comparison of prices. In order to constrain money value its supply must be limited in some way, and controlled to match up demand;

Currency stability in its most basic form is the third function of money: money as a unit of account. In other words, a cryptocurrency is considered "stable" if it's purchasing power is constant. 

=== Why are cryptocurrencies so unstable? ===
From fundamental economics, we know that to achieve price stability,
supply and demand must be in equilibrium. To understand why cryptocurrencies are unstable we look to their supply
and demand mechanisms.

==== Cryptocurrency Demand ====
To analyse demand, we find it useful to split the demand into
two parts:
* Transactional Coin Demand, CD_T
* Speculative Coin Demand, CD_S

Total coin demand, CD, is therefore:

CD = CD_T + CD_S

Transactional Coin Demand represents the demand for a coin to use as a
transactional medium. Speculative Coin Demand represents the demand
for a coin as a speculative investment vehicle.

==== Cryptocurrency Supply ====
Using the Bitcoin/Ethereum protocols as an example, supply of currency
is governed by the network's ability to mine blocks. In other words,
new coins are only minted and distributed when new blocks are mined
and added to the chain.

This supply mechanism is flawed for two reasons:

1. The supply mechanism only has capacity to increase supply, but not decrease supply.

2. Demand for currency is dynamic and unpredictable, supply is increased irrespective of the level of demand for coins.

=== How do we create currency stability? ===
At the core of creating currency stability is controlling the supply of
currency according to demand; ''monetary policy''. Holding the
supply of currency constant whilst demand increases will drive the price up. Assuming we
can measure demand reliably and accurately, increasing/decreasing
supply ''(rebasing)'' in-step with demand will maintain price. The more difficult problem however is
maintaining purchasing power of a cryptocurrency. 

==== Multi-currency Systems ====
One way to approach the purchasing power stability problem is to implement multi-cryptocurrency systems
which have a volatile component and a stable component.

For instance, consider a cryptocurrency which we want to stabilise in
terms of USD purchasing power. 

The user's wallet is made up of two components:

1. volUSD, the volume / volatile component of the cryptocurrency;

2. savUSD, the saving / stable component of the cryptocurrency.

Users are free to distribute their wallets between volUSD and savUSD however they
want, and 1 savUSD can always be converted to 1 volUSD and vise
versa. Furthermore, rebasing only occurs with respect to the number of
volUSD in existence and we can only trade between volUSD and USD - not
savUSD and USD. See below:

[[File:Multicurrency-system-diagram.png|center|500px]]

This structure aligns with the components of coin demand; users who
have high CD_S but low CD_T will hold more volUSD, and users who
have low CD_S but high CD_T will hold more savUSD.

The basic multi-currency system still has a number of major
flaws however which fall under the two following aspects:

1. How do we control supply of cryptocurrency, i.e. issue and absorb units dynamically?

2. How do we measure the price of a cryptocurrency in a decentralised way?

=== Dynamic Cryptocurrency Supply Control ===
Even with a multi-currency system it is still necessary to have mechanisms to control supply of volUSD and savUSD in order to achieve price stability. If we allow users to freely trade between volUSD and savUSD with no restrictions on supply, we would see the following behaviour from rational users:

* users allocate 100% of their wallet value in volUSD when there is expectation that the price of USD / volUSD will increase over the next rebasing period, in an effort to maximise financial gain.
* users allocate 100% of their wallet value in savUSD when there is expectation that the price of USD / volUSD will decrease over the next rebasing period, in an effort to minimise losses.

The end result is a system which is just as volatile and unsustainable
as a single currency system. 

Building on the concept of a multi-currency system is a number of
approaches which are being developed in the cryptocurrency
ecosystem. These approaches have so far had varied success, and the
following section will consist of a brief look at a few of the more
prominent methods. 

==== Bitshares & BitUSD ====
Bitshares is a blockchain network which is capable of providing a range of financial services, it is also the name of the network's generic currency (BTS). Bitshares features price-stable cryptocurrencies, their stablecoin pegged to the USD is referred to as BitUSD. Within the context of our multi-currency wallet defined above, BitShares (the currency) is the volatile component which is used to back BitUSD (the target of stability). 

1 BitUSD is always equal to 1 USD. To achieve this stability, a user locks into a smart contract the amount of BitShares (at the current price) equivalent to 2 times the USD value of BitUSD they wish to hold. The smart contract then releases the BitShares used as collateral when the BitUSD is paid back into the smart contract. Effectively, users `borrow' BitUSD from the network, using BitShares as collateral.

If the dollar value of the BitShares used as collateral drops to below 1.9 times the dollar value of BitUSD borrowed, a margin-call is automatically enforced by the protocol. This means the smart contract will buy back the BitUSD debt and return to the user their BitShares collateral.

==== Seigniorage Shares ====
Seigniorage shares is a concept proposed in Robert Sams paper published in 2015. It posits a system based on shares (the volatile component) and coins (the target of stability).

In a Seigniorage shares system, a user can trade shares-for-coins and coins-for-shares via an auctioning system, where shareholders vote on the number of coins to be minted. It should be noted that Seigniorage shares have not yet been successfully implemented in practice, and there exists no further literature discussing the theory behind the concept outside Sams (2015).

==== Nubits ====
Similar to Seigniorage Shares, Nubits uses the concept of shareholders
(NuShares) and a target stable currency (Nubits, NBT). Within the
Nubits protocol holders of NuShares have voting rights as to:

* Issue new NuBits
* Issue new NuShares
* Set transaction fees on the network
* Set the interest rate on parked NuBits

NuBits are one of the more sucessful stablecoin implementations that
exist currently - although their peg is still not perfect. During
2016, from June through to October, the price of NuBits saw a rapid
decline and spike in volatility, reaching as low as 0.2 USD on June 26th. As of
23/10/2017, there are approximately 750,000 NBT in circulation.

The specific mechanics of how NuBits attempts to maintain a peg of 1
NTB = 1 USD will not be discussed here as it is not the focus of this paper.

[[File:Nubits-historical-price.png|center|600px]]

==== Tether ====
Tether is a single currency system which aims to maintain a peg to the USD (1 Tether = 1 USD) using a contract. 

The contract set out between a User and Tether:

User gives Tether 1 USD for 1 Tether, 
on the premise that at anytime in the future, they can redeem 1 Tether for 1 USD.

The issue with this approach however is it recentralises control of fiat currency to Tether and the financial institutions supporting it. For instance, it is stated in the Tether Terms of Service that there is ``no contractual right or other right or legal claim against us [Tether] to redeem or exchange your Tethers for money.''. This means an unknowing user could exchange fiat currency for an equivalent amount of Tethers, for which they cannot force Tether to redeem for their original currency back. In a worst case scenario, Tether could just walk away with user fiat currency, with no obvious legal recourse for users. 

=== How does this apply to the Ideal Blockchain Solution? ===
Through this discussion, we have seen that the problem of price
stability has not been completely solved yet by the blockchain
community. We find that stablecoins still
have limited purpose for the fact that their recognisability is
limited. 

Within the context of our Ideal Solution we can work around price
volatility with three approaches:

1. Transact purely in stablecoins; or

2. Move in / out of transaction cryptocurrency quickly; or

3. Don't represent value in the system with cryptocurrencies.

==== Approach 1: Transact Purely in Stablecoins ====
Value is represented in the System only as stablecoins, this means we
use a stablecoin such as NuBits or bitUSD to transact value from
Investors to Issuers - based on the usable stability of these
stablecoins they could be implemented as an exension to the Ideal Solution.

Using this value representation mechanism, in order to purchase shares, investors need to deposit
a sufficient number of stablecoins in their Investor Platform
Wallets. It also means that funds received at the Issuer Platform
Wallet end is represented in stablecoins.

By transacting in stablecoins, the design of the Ideal
Blockchain Solution is largely unaffected, and we address price
volatility issues, however from a usability standpoint, the
transaction becomes more difficult for investors and issuers. 

This is because at the end of the day, stablecoins do not have real
purchasing power due to their lack of recognisability (you can't buy
goods and services with stablecoins yet - even less so than Bitcoin or
Ether). As a result of this, if Investors want to realise their profits from
selling shares, or Issuers want to spend funds raised, a conversion to
fiat currencies is still be required. 

Although technically possible, the facilities available to do this are
cumbersome and likely too difficult for the average user to navigate.

A better solution, which is more familiar to Investors, would be for
the Platform to accept fiat currency which it exchanges into
stablecoins on behalf of the Investors / Issuers.

This would work similar to how a typical trading account would work
(think Nabtrade / Commsec). An Investor would transfer fiat currency
to the Platform, the Platform would then be exchanged for stablecoins
which are alloted to the corresponding Investor Platform Wallet. 

Investors could then purchase shares using their stablcoin currency in
their trading account - or withdraw funds as well if they
wish. Investors would withdraw funds by signalling to the Platform, at
which point stablecoins are traded back for an equivalent amount of
fiat currency. 

On the Issuer side of the transaction, they would receive stablecoins
in their Issuer Platform Wallets whilst the capital raise is
occuring. When it is time to release the funds, stablecoins are
convert into fiat currency by the Platform and distributed to the
Issuer's bank account. 

'''Pros'''

The benefit of this approach is that the Ideal Blockchain Solution
design is largely unchanged - meaning we can ensure the integrity of
share purchases and share registries using a blockchain once users
are in the cryptocurrency ecosystem. Furthermore
usability from an Investor and Issuer perspective is improved
significantly, as the system would behave similarly to online trading
platforms which exist today. 

'''Cons'''

The main issue with this approach is that it places a high degree of
trust back in the Platform. Effectively control over user funds is
re-centralised at the Platform which acts like an exchange. 

This poses a notable, but acceptable level of risk to Investors and
Issuers, namely:

1. What recourse for an Investor is there if they transfer fiat currency
to the Platform and no stablecoins are returned? 

2.  What if the Platform
does not distribute the correct amount of fiat currency to the Issuer
and `skims a little off the top'? 

These outcomes are due to the looser connection
between the fiat currency system and the cryptocurrency ecosystem, and are
difficult to govern by code. As a result of this there is exposure to
fraudulent human behaviour. 

To summarise: the weak points of this approach are at the bridge
between fiat ecosystem and the cryptocurrency ecosystem where some
human action by the Platform is required. That being said, the level
of trust in the System is reduced under this approach when compared
with the Existing Solution.

==== Approach 2: Move in/out of the cryptocurrency ecosystem quickly ====
This approach is less to do with how the Ideal Blockchain Solution is
designed and more to do with how users choose to interact with the
System. If users hold their funds in stable fiat currencies, then only
buy into volatile cryptocurrencies at the time of transaction, they
can limit their exposure to changes in price significantly. 

This approach is somewhat nonsensical from a usability perspective
however. 

From the perspective of the average investor, why would
they buy into a cryptocurreny, to buy shares, when previously they
could've purchased shares using their fiat currency directly (albeit
in a manually intensive way)? 

From the Issuer and Platform's perspective, approaching price stability in this way
is even more roundabout. To illustrate, funds may need to be held in
escrow pending the completion of a capital raising campaign, this
escrow period could be in the order of a few months. For price volatility
reasons, these funds cannot be held in escrow as cryptocurrency,
therefore we need to hold them in escrow as fiat currency in a 3rd
Party Trust Account. So as funds come in from Investors, the Platfom
needs to convert this back into fiat currency, then deposit this
currency into the 3rd Party Trust Account. At this point, the manual
work of converting from fiat to crypto to fiat,
then depositing funds into
the 3rd Party Trust Account is comparable to the process undertaken in
the Existing Solution.

As a result, it can be seen that by using this approach, blockchain is not adding siginificant value.

==== Approach 3: Don't Represent Value in the System with Cryptocurrencies ====
This approach would require significant reworking of the Ideal
Blockchain Solution. Effectively we would be using a digital payment
gateway (such as PayPal) to determine when purchases are made using
fiat currency, which we would use as a signal to trigger on blockchain
processes. 

'''Pros'''

Usability from Investors and Issuers is easy, and looks similar to
purchasing any goods online. Furthermore administrative load is
reduced using this payment mechanism.

'''Cons'''

Payment velocity is reduced, and furthermore integrity of the
transaction is compromised slightly on two fronts.

Firstly, trust is being placed back in the hands of the financial
institutions and the 3rd Party Authority. Further to this, additional trust is placed
in the System to couple the flow of fiat currency and flow of on-blockchain data. 

Upon reviewing this approach, again the value added by integrating
blockchain here is marginal. Significant intermediaries are still required
to facilitate the transaction, whilst the blockchain component
is somewhat reduced to the logging of actions after the
fact. Ideally we have what's on the blockchain being the source of
truth with flow on actions being taken based on this information - not
the blockchain providing a trail of what has already happened.

=== A Note On Cryptocurrency Price Discovery ===
Up till this point, we have only considered changes in the USD/cryptocurrency exchange conversion rate as a proxy for the demand of a given cryptocurrency. This is a flawed assumption however for two reasons:

1. The USD/crypto conversion rate is not fully representative of the demand for the cryptocurrency - true demand is obfuscated by factors such as transaction friction (USD into cryptocurrency), and the fact that cryptos are traded across different exchanges with different prices and pricing mechanisms. In other words, a robust, decentralised price discovery mechanism is required.

2. Pricing a cryptocurrency relative to a centralised fiat currency does not make sense from the perspective of a currency which is global, trustless and decentralised. By pricing in terms of USD, we are effectively inheriting the monetary policy actions of the US government. To solve this we need a new pricing reference point.

Although not the focus of this work, price discovery is a crucial
component of creating ideal stable cryptocurrencies that are truly
decentralised. Price discovery of cryptocurrencies is a branch of
price stability which could form the basis of future research.

== 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.

== References ==
[1] S. Nakamoto (2008), Bitcoin: A Peer-toPeer Electronic Cash System. [Online]. Avail- able: https://bitcoin.org/bitcoin.pdf.

[2] A. Back. (2002), Hashcash - A Denial of Service Counter-Measure. [Online]. Available: http://www.hashcash.org/papers/hashcash.pdf.

[3] W. Dai. (1998), b-money. [Online]. Available: http://www.weidai.com/bmoney.txt.

[4] H. Finney. (2005), Reusable Proofs of Work. [Online]. Available: https://web.
archive.org/web/20140413220721/http://www.finney.org:80/~hal/rpow/.

[5] N. Szabo. (2004), Scarce Objects. [Online]. Available: https://web.archive.org/web/20140413040733/http://szabo.best.vwh.net/scarce.html

[6] N. Szabo. (2005), Bit Gold. [Online]. Available: http://nakamotoinstitute.org/bit-
gold/#selection-43.45-43.240.

[7] H. Massias, X. Serret Avila, J.-J. Quisquater. (1999), UCL Crypto Group, Design of a Secure Timestamping Service with Minimal Trust Requirement. [Online]. Available: http://nakamotoinstitute.org/static/docs/secure-timestamping- service.pdf

[8] V. Buterin. (2013), A Next Generation Smart Contract & Decntralised Application Plat- form. [Online], Available: http://www.the-blockchain.com/docs/Ethereum_white_ paper-a_next_generation_smart_contract_and_decentralized_application_ platform-vitalik-buterin.pdf.

[9] World Economic Forums Meta-Council on Emerging Technologies. (2016) Top 10 Emerging Technologies of 2016. [Online]. Available: http://www3.weforum.org/docs/ GAC16_Top10_Emerging_Technologies_2016_report.pdf.

[10] British Business Bank. (2015) Equity Crowdfunding in the UK: Evidence from the Equity Tracker. [Online]. Available: http://british-business-bank.co.uk/wp-content/ uploads/2015/03/230315-Equity-crowdfunding-report-final.pdf.

[11] P. Evans-Greenwood (2016) et al, Bitcoin, Blockchain & distributed ledgers: Caught between promise and reality [Online], Deloitte’s Centre for the Edge. Available: https://www2.deloitte.com/au/en/pages/technology/articles/distributed- ledgers.html