BCP Framework For Assessment of Crypto Tokens - Block 2
BCP Framework For Assessment of Crypto Tokens - Block 2
Framework
for Legal and Risk
Assessment of
Crypto Tokens
Classification of decentralized
blockchain-based assets
The age of tokenized ecosystems has begun, the shift from centralized to decentralized blockchain-based
creations and the transfer of assets is ongoing. Our current world is full of different asset classes ranging
from money (in a narrow sense) to gold, real estate, securities, intellectual property ("IP") etc., many of
which are difficult to physically trade or subdivide. Distributed ledger technology, or more specifically
blockchain technology, is increasingly providing solutions to this problem.
Blockchain technology can design digital information units that contain elements of a property right (ac-
cording to civil law concepts) to which an owner has direct and exclusive access that can be defended
against third parties (right in rem). It contains the tools to program a unique set of information that attrib-
utes a property right and enables a secure and registered public transfer of the new type of digitally-de-
fined property: Blockchain Crypto Property (“BCP”).
In addition, the introduction of Smart Contract Systems (“SCS”) at the application level of the blockchain
has added immutable functions and property terms to BCPs, enabling not only the execution of bilateral
and multilateral programs in accordance with contractual terms and conditions, but also the ability to
create co-ownership like organizations. A BCP is therefore defined as a digital property that can be regis-
tered on the blockchain, in addition, it may carry out coded functions governed by an SCS, following coded
or manual input by an agreed party (called an “Oracle”).
In order to consistently assess the legal and tax implications, associated risks and investment suitability
of BCPs in the tokenized ecosystem, a reliable classification model and risk assessment criteria are indis-
pensable. By applying an assessment method based on functionality, rather than on a particular country’s
legal concepts, the classification and risk assessments can be considered in all jurisdictions, regardless
of national legal and regulatory frameworks. Though the BCP classification may ultimately lead to different
regulatory treatments in each jurisdiction, it may facilitate the multijurisdictional understanding of exist-
ing and new applications in the tokenized ecosystem, as well as identify coins which may not have the
essential characteristics of digital property (i.e. not a BCP). The objective of the risk assessment and re-
sulting BCP rating is to increase awareness and serve as a basis for establishing governance and diligence
standards for all aspects of creating, offering, transferring and holding tokens.
With the above in mind, a “Conceptual Framework for a Legal and Risk Assessment of Blockchain Crypto
Property” was developed. The current "Block 2” version includes several amendments to the initial genesis
version from September 2017, including a more detailed classification and Token development stages.
1
BCP Classification and Risk Assessment Method
BCP Class 1
Operational
No legal counterparty
Market & Counterparty Risks
Pre-Operational
BCP Class 2
Counterparty Tokens
Risk Extent
Weighting of
BCP
BCP Class 3
A, B, C, D and E
Right in rem
2
Definitions
Blockchain Crypto Property (“BCP”): (1) Digital information containing all elements of a property right
from a functional equivalence perspective, (2) that is registered on a blockchain or in an alternative dis-
tributed ledger, (3) which can be transferred via a protocol, and (4) that may (or may not) carry out addi-
tional functions governed by a SCS following coded and/or manual input. This document uses the term
BCP or Token, which is the term widely used by the blockchain community.
Access and Intermediation: A user has direct access to BCP using his private key ("PIK"). The BCP is visible
d
on the protocol through the cryptographic address of the Public Key ("PUK"). Intermediary functions are
only possible through the transfer of single-signature or use of multi-signature private keys. Co-ownership
is made possible via immutable code-defined SCS functions that cannot be changed once released on a
protocol.
Blockchain Technology: A blockchain is a type of distributed ledger in the form of a continuously growing
list of records based on blocks, which are linked and secured using cryptographic signatures. Each block
typically contains a hash pointer as a link to a previous block, a timestamp and transaction data. Block-
chains are inherently resistant to data modification. From a functional perspective, a blockchain can serve
as an open, distributed ledger that can record transactions between two parties (accounts) efficiently and
in a verifiable and permanent way.
Distributed Ledger Technology: Database of replicated, shared and synchronised information that is
shared in a decentralized manner among network users.
Input and Output Function (Conditions): These functions allow the BCP to interact with other BCPs or ex-
ternal data. The input and output functions are governed by an SCS, following coded or manual input by
an agreed third party (called an “Oracle”).
Platform(s): A platform allows transactions where BCP can be created and/or transferred via protocols.
There are infrastructure platforms such as Ethereum (“Infrastructure Platforms”) and specific user plat-
forms built on such infrastructure platform (“Application Platforms”). Platforms frequently include an in-
built algorithm for creating, transacting and burning digital units.
Registration Function (Terms): This function defines the legal nature of the BCP. There are basically three
categories: (1) property right of an account entry (e.g. of a Bitcoin), (2) derivative of a property right leading
to a legal right against a counterparty (share in a legal entity or fund, real estate, movable item, registered
IP); and (3) a direct property (e.g. on IP).
Smart Contract System: The SCS is a distributed-ledger-based computer protocol intended to define, ver-
ify and enforce the functions of a BCP.
Tokenizing: A BCP can include two sets of functions: (1) registration functions (“terms”); and (2) input and
output functions (“conditions”). Tokenizing is the programming of all or part of these functions to a BCP. A
Token will be issued and functional once released on a protocol.
3
Introduction: Relevant Data
The BCP classification and risk assessment is based on an analysis of the underlying protocol, market-
related data and token functionality.
The data examined will represent the basis not only for the functional classification and risk assessment,
but also for the resulting BCP rating.
Underlying Protocol
Functionality
The first part, the evaluation of the underlying Token protocol, involves a broad range of different technical
and conceptual aspects which may have an impact on the stability, security and/or proper function of the
BCP. Such aspects are the:
The market evaluation focuses on the financial key figures as well as on the availability and tradability of
the BCP. The financial data of BCP is analysed for a reference period of the last 30 and 180 days and is set
in relation to Bitcoin ("BTC") as the first BCP. Therefore, relevant factors are the:
Functional Data
The functional evaluation of the BCP is of high importance for the classification of the BCP. Relevant func-
tional aspects are the:
5
Functional BCP Classification
This framework proposes a classification of Tokens or BCPs based on their function or target use. Key el-
ements that further define the classification include the existence and type of counterparty along with the
presence of an underlying asset or value. For example, if the Token includes some form of asset and a
counterparty, it will have significant legal and regulatory differences compared to a native “currency-like”
Token. As defined above, all BCPs are transferable property that may carry out certain functions, including
the transfer of rights or revenue.
Categorizing tokens based on these criteria aims to clarify a Token holder’s rights, allowing the community
to precisely define a Token’s value, mitigate any risks and provide a supporting framework. Following the
above, our BCP distinguishes between three major classes of BCPs and Tokens:
Natural/legal person
No legal counterparty Right in rem
as counterparty
BCP Class 1 Tokens can be transferred on a decentralized ledger from user 1 to user 2, but do not grant
any rights towards a counterparty. The owner of a Native Utility Token does not have any relative or
absolute right, except for the right relating to the Token itself.1 The fact that a Token might be used on a
specifc blockchain system, for example as “gas”, does not exclude it from being assigned to the BCP Class
1. The relevant criteria for this category is the lack of a relative right against a counterparty, such as the
Token generator or a third party. BCP Class 1 Tokens can be divided into the following four sub-classes:
Basic Tokens are simple mediums of exchange, units of account and stores of value
without further functionalities. Examples of Basic Tokens are Bitcoin, Bitcoin Cash,
Litecoin, Monero or ZCash.
1 Theright on the Token itself depends on the technical and conceptual model of the underlying blockchain. In
the case of blockchains based on unspent transaction outputs (UTXO) such as Bitcoin, those UTXO might be
seen as the units of value. In account-based-blockchain-models such as Ethereum a user would have a right
on the (externally owned) account linked to a specific asymmetric key pair.
6
(2) Infrastructure Access Tokens
The second category, BCP Class 2, refers to Tokens which include any form of a relative right against a
third-party. The relative right might be a (legal) right to use the Token generator’s services, a right to receive
a financial payment, a right to receive an asset or a bundle of shareholder’s right.
Based on the different characteristics of these relative rights, we distinguish between the following sub-
classes in our BCP Class 2: (1) IOU Tokens, (2) Derivative Tokens, (3) Fund Tokens, (4) Equity Tokens, and (5)
Membership Tokens.
IOU Tokens represent any forms of a debt or claim against the token holder or a
third party. Examples of such an underlying claim can be the:
Typically, the details of the debt are part of a separate contract between the Token buyer and the Token
generator. Examples are Tokens on the Lykke Marketplace. Moreover, all "utility tokens" outside of BCP
Class 1 which include a relative right against a counterparty and do not fit within the other categories of
BCP 2 are classified as IOU Tokens.
7
(2) Derivative Tokens
Derivative Tokens are a special form of the above-mentioned IOU Tokens. Because
of their specifically regulated existence, they form a separate sub-class in our clas-
sification model. The value of the claim derives from an underlying base value, for
example gold, Swiss Francs etc. An example of a Derivative Token is Modum.
The fourth sub-class in BCP Class 2, Equity Tokens, relate to tokenized shares and
shareholders’ rights.2 The Token represents membership rights in a corporation as
well as associated asset rights, such as the right to receive dividend payments.
Depending on the specific ownership model, we can distinguish between (1) Joint-Ownership Tokens, (2)
Co-Ownership Tokens and (3) Sole-Ownership Tokens.
2 In Switzerland, daura AG, a joint venture project of Swisscom and MME, is currently developing the legal, technical and op-
erational possibilities to trade shares on blockchains; see C-Share introduction video on:
https://www.youtube.com/watch?v=FRCK6EEbYnY.
8
(1) Joint-Ownership Tokens
Sole-Ownership Tokens refer to situations in which the assets linked to the To-
kens are divisible and separable. In this case, every Token holder is the sole owner
of a specific asset. The sole ownership is referred to in German as "Alleineigen-
tum".
9
Functional BCP Classification Overview
Payment,
FINMA Payment
Payment and/or Utility Tokens Utility and/or Asset Tokens n/a n/a
Equivalent Tokens
Asset Token
Medium of
(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1)
exchange,
unit of ac- Access to en- Access to de- Tokenization Tokenization Tokenization Tokenization Tokenization Joint-owner- Co-ownership Sole-owner-
count and hanced func- centralized of a claim of a claim of a fund of a corporate of a personal ship of an as- of an asset, ship of an as-
(2)
store of value tionality in- application or against a le- share membership membership set, i.e. IP i.e. IP set, i.e. IP
Functionalities
Personal
Underlying Derivative Ownership of Ownership of Ownership of
None None None None Debt / Claim Fund share Equity share membership
Value (debt) an asset an asset an asset
right
Bitcoin,
Ether, Ether Lykke Colored
Bitcoin Cash, Siacoins,
Classic, Coins, "Utility Blockchain Daura
Examples Litecoin, Wings Mysterium, Modum tba tba tba tba
Cardano, Lisk, Tokens" with Capital C-Shares
Monero, Filecoin
ICON, EOS counterparty
ZCash
10
BCP Development Stages
Functionality is the basis for the BCP classification introduced above. Therefore, all three BCP Classes refer to
functional tokens. However, many Tokens will not be functional from the moment a contribution is made in the
context of a Token Generating Event ("TGE"), also known as an Initial Coin Offering ("ICO"). In some cases, early
investors may be granted a right to receive a future BCP. In order to provide greater transparency into the rights
and obligations generated at various stages of a Token’s creation, distribution or exchange, this analysis adds
three development stages to the BCP Framework which defines the various development layers and maturities
of the related protocol, application, business or projects associated with a BCP.
(1) Pre-BCP
The first development stage refers to situations in which contributions are recorded centrally by a legal entity or
decentrally on a blockchain, but do not result in the receipt of a Token. A contribution can be registered within a
protocol or any other distributed or centrally managed ledger entry but is not transferable. For example, a project
team could save all contributor addresses and future application wallets on the Bitcoin Blockchain or within an
Ethereum SCS and undertake to allocate future tokens accordingly. At this stage, a contributor has no transfer-
able assets on a distributed ledger. He can only transfer the wallet data bilaterally and off-chain. Therefore, the
ledger entry for a proposed future Token allocation does not fulfil the transferability requirement of our BCP def-
inition. The same applies to constellations in which a contributor receives a passphrase allowing him to access
future BCPs.
Tokens which are transferable via a protocol, but cannot yet offer their intended utility on the network are cate-
gorized as “pre-operational” Tokens. Such Tokens are often listed and traded on a secondary market exchanges.
Within this category, we distinguish between BCP Voucher Tokens, which need to be converted into separate To-
kens, and pre-operational Tokens, which requires a completion of the underlying protocol, the infrastructure
and/or the application.
Pre-operational Tokens fulfil the definition of BCP (i.e. the transferability) but lack the intended target utility.
This stage refers to BCPs which operate in accordance with the intended design.
Operational BCP can be classified into the BCP classes 1 to 3 and its specific sub-classes.
11
BCP Development Stages Overview Ledger Entry or Passphrase
=pre-BCP
Pre-BCP
Pre-Operational Token
=Independent Token =Final Project Token
(Conversion function into (Final but pre-operational BCP,
separate project related BCP, transferable via a protocol,
transferable via a protocol, e.g. as ERC20 token)
BCP BCP
12
Risk Assessment
Risk Extent
Risk Probability
Weighting of Risk Category
Risk Factors
Net Risk A, B, C, D and E
The categorization of BCP in risk classes depends on the technical, legal and market risks associated with the
specific BCP.
Risk of Weaknesses or Exploitable Breakthroughs in the Field of Cryptography: The development of cryptography
is continuing. Code cracking or technical advances such as the development of quantum computers, could pre-
sent risks to cryptocurrencies and the BCP, which may result in the theft or loss of BCP.
Risk of Underlying Technology Attacks: The underlying technology used for the BCP may be susceptible to various
and different network attacks, including but not limited to denial of service attacks and race condition attacks.
Any successful attacks present a risk for BCP transactions, i.e. the proper execution and sequencing.
Risk of Blockchain Consensus Attacks: The user must understand and accept that, as with other public block-
chain-based systems that rely on independent validators, the underlying technology may be susceptible to con-
sensus attacks, including but not limited to, double-spending, majority voting power and censorship attacks. Any
successful attack presents a risk to the BCP, expected proper execution and sequencing of BCP transactions.
13
Cyber Security Risk: Cyber security risk is defined as the risk of financial loss, disruption of business ac-
tivities or reputational damage resulting from absent or insufficient protection safeguarding information
technology systems (e.g. hacker attack, virus transmission and network downtime), poor change manage-
ment practices or leakage of information. Investors and users are the most exposed to risks of losing funds
by investing, storing, managing or transferring cryptographic tokens. Organizations must ensure they pro-
vide investors and users with the best tools and security protocols to protect them from theft, malfunc-
tions, and technical incompetence.
Risk of Insufficient User Wallet Encryption: User wallets should be encrypted with a strong password (a
minimum of 12 characters, containing alphanumeric, special characters such as uppercase letters,
spaces or symbols). A standard and well tested encryption algorithm should be used.
Risk of Insufficient User Wallet Backups: Users should be able to download an encrypted backup of their
keys.
Risk of Insufficient Contingency Tools: Users should not lose access to funds due to software malfunction-
ing. Users should contemplate potential network congestion.
Money Laundering Risks: Where a Token Generating Event accepts and generates assets within the same
infrastructure (e.g. ETH – ETH), the buyer’s PUK can easily be traced and screened. Conversely, money
laundering risks are more likely to be present where Fiat currency is accepted in the initial Token genera-
tion without an AML and Know Your Customer ("KYC") pre-screening of the buyer, or when a Token is ex-
changed for another from a different infrastructure in the issuing processes, reducing the visibility of the
original PUK.
Following the initial Token generation, funds raised by a corporation may be misappropriated by individu-
als or groups where there are insufficient controls. Alternative business models that provide strong gov-
ernance, such as that of a Foundation, significantly reduces the risk of money laundering by ensuring in-
dependent audits and disclosure to authorities of fund management.
Finally, in daily trading, while the anonymity of the BCP sender’s true identity carries inherent risks for
money laundering abuse (the individual may be black-listed), the transaction history visible in a pseudon-
ymous system, such as Bitcoin or Ethereum, allows the recipient to complete a KYC/AML screening of the
entire history of the asset’s transfers.
14
Risk of Value Decrease of BCP: Market conversion rate of BCP may change significantly between the time
of the user’s instructions and the time of conversion. Hence, there is a risk of untimely execution.
Operator Counterparty Risk: As all functions of the Operators are not yet regulated, no self-regulating
schemes exists and market prices remain volatile (see above), there is an increased operator (counter-
party) risk. In particular, an operator would not be in the position to execute a transaction due to organiza-
tional, financial and/or regulatory restraints.
Risk of Alternative (Hard-Forked) Underlying Technologies: Alternative underlying technologies that uses
the same open-source code and open-source protocol as the BCP could be established. The official un-
derlying technology may compete with these alternative networks, which could potentially negatively im-
pact the value of the BCP.
The final stage of a BCP assessment combines the BCP Class, which considers technical aspects, value
and the presence of counterparties, together with the BCP Risk Category, based on security, legal and mar-
ket considerations. The resulting BCP rating is therefore derived from a standard and holistic assessment
of the BCP that aims to provide visibility to regulators and protection to investors, ultimately leading to
higher trust and adoption of blockchain technologies.
15
Annex 1: Regulatory Qualification in Switzerland
FINMA ICO Guidelines of February 16, 2018
The Swiss Financial Market Supervisory Authority FINMA has published guidelines (“Guidelines”), dated
February 16, 2018, setting out how it intends to apply financial market legislations in handling enquiries
regarding the applicable regulatory framework for initial coin offerings (“ICO”). The Guidelines complement
FINMA’s earlier Guidance 04/2017, published on September 29, 2017.
By issuing the Guidelines, FINMA takes an important step forward to further clarify the applicability of the
current legal and regulatory framework related to the organisation of ICOs or Token Generating Events
(“TGE”) in Switzerland. In doing so, FINMA becomes the first global regulator to provide detailed and prin-
ciple based rules on how it intends to treat enquiries from ICO organisers.
FINMA’s Guidelines recognise the innovative potential of blockchain technology by creating a positive and
(lightly) regulated environment for this highly dynamic market. By means of this most recent Guideline,
FINMA informs ICO organisers the information that is required in order to submit enquiries, it allows
FINMA to respond more effectively, and of greater importance, it clarifies the principles on which FINMA
will base its response to such enquiries or ruling requests.
Although the Guidelines aim to provide high-level guidance, they also leave a degree of ambiguity in rela-
tion to a number of legal questions. The Guidelines provide a general framework as to how FINMA currently
interprets the regulatory landscape, however in our view, many market participants may nevertheless re-
quire further clarification on the regulatory treatment of their Tokens or ICO, obtained by means of a non-
action letter. Furthermore, the Guidelines do not go into depth the detailed reasoning behind FINMA’s legal
analysis. It therefore remains to be seen to what extent future case law and further regulations will con-
tinue to support FINMA’s approach as the technology and markets matures. Finally, the Guidelines focuses
largely on traditional issuers and investor relationships, they do not take into account aspects of decen-
tralized funding models, community-based projects and open-source software developments.
FINMA distinguishes between Payment Tokens, Utility Tokens and Asset Tokens:
Payment tokens (synonymous with cryptocurrencies) are tokens which are intended to be used, now or in
the future, as a means of payment for acquiring goods or services or as a means of money or value transfer.
Cryptocurrencies give rise to no claims on their issuer.
Utility tokens are tokens which are intended to provide access digitally to an application or service by
means of a blockchain-based infrastructure.
Asset tokens represent assets such as a debt or equity claim on the issuer. Asset tokens promise, for ex-
ample, a share in future company earnings or future capital flows. In terms of their economic function,
therefore, these tokens are analogous to equities, bonds or derivatives. Tokens which enable physical as-
sets to be traded on the blockchain also fall into this category.
16
Relationship between BCP and FINMA Classification
FINMA remains more or less in line with frameworks discussed by leading practitioners, including the cur-
rent Blockchain Crypto Property Classification model (“BCP”) at hand, however in a simplified version by
grouping all token forms into three categories without any sub-categories. Both the BCP and FINMA mod-
els are based on the functionality of specific Tokens. However, FINMA points out that the individual token
classifications are not mutually exclusive and hybrid Tokens are possible. The absence of a precise clas-
sification leads to some degree of legal uncertainty in practice. Moreover, the qualification of Tokens for
decentralized, open-sourced and community-based projects, which do not need a centralized issuer,
seems to be out of scope in the FINMA model.
The aim of the Blockchain Crypto Property Classification 2.0, which is based on 3 BCP Classes and 12 BCP
Sub-Classes, is to enhance the existing framework for Token classification approach and complement the
high-level FINMA model in order to simplify the legal, risk and regulatory evaluation.
Taxation
Taxation issues have – rightfully – not been addressed by FINMA as part of the by Guidelines. Nevertheless,
while regulatory discussions are of highest relevance, taxation question are vital to the same extent. Luck-
ily, the Swiss tax system is generally very beneficial for corporate structures, offering effective income tax
rates between 8 – 24%, depending on business activity and location.
Blockchain-based crowdfunding, however, is still in its infancy in Switzerland. Although the individual
forms of funding are essentially nothing new under civil law, many uncertainties remain under tax law. The
difficulty of crowdfunding is that the tax implications differ widely, depending on the form it takes. While
for equity and debt-based structures, transactional taxes like stamp duties and withholding taxes are of
major relevance, income tax exemption or gift tax must be considered for donation-based models. In ad-
dition, reward-based crowdfunding could be subject to VAT. Moreover, countless combinations (including
profit participating loans, reclassification of debt as equity, mixed donations, and so forth) and cross-bor-
der issues are possible, which further complicates matters.
Therefore, no general comments about specific tax consequences of ICOs can be made. Only a case by
case analysis may identify the exact circumstances and particularities of a specific project. Furthermore,
this would enable the tax implications to be discussed with the relevant authorities ahead of time, in order
to avoid any unpleasant surprises down the road that could jeopardise the very existence of the project.
However, the Swiss tax authorities are generally very progressive with regard to blockchain-based tech-
nologies such as cryptocurrencies, tokens and ICOs. Responding to the formal request of some Swiss
bitcoin organizations in 2015, the Swiss Federal Tax Administration (SFTA) confirmed that for the purpose
of Swiss VAT it would treat Bitcoin the same way as the Swiss Franc or other FIAT currencies, i.e. trading in
Bitcoins is neither a delivery, nor a service, but rather a means of payment and as a result, not subject to
VAT. Recently, the SFTA has mentioned orally that all BCP Class 1 Tokens (i.e. tokens with no claim towards
a legal counterparty) would receive the same VAT treatment.
In addition, the SFTA has published an "official" exchange rate for Bitcoin since December 31, 2015. This
exchange rate is a recommendation to the cantonal tax authorities for net wealth tax purposes. In 2017,
the SFTA added nine additional cryptocurrencies - Ethereum, Ripple, Bitcoin Cash, Litecoin, Cardano, NEM,
Stellar, IOTA and TRON - to their exchange list, which is unprecedented in the rest of Europe or the US.
17
Regulatory Implications of BCP Classification in Switzerland Primary Market
Swiss license requirement for direct primary market issuance (TGE/ICO) of Tokens?
Only if issuer
qualifies as
No No
derivative
house
Anti-money-laundering provisions: Self-regulatory-organisation (SRO) membership or a directly subordinated financial intermediaries (DSFIs) approval required?
direct and centralized issuance via TGE/ICO
If qualified as
No structured Yes In general, no
product
Contributions / sales price might be subject to business profit tax; Stamp duty of Tax-neutral if Sales price might be subject to business profit
tax-neutral if contributed to the committed assets of a foundation or if corresponding liability must be booked; 1% if association tax; value added tax (VAT) of 7.7%
value added tax (VAT) depending on circumstances > CHF 1 Mio. membership depending on associated asset
18
Regulatory Implications of BCP Classification in Switzerland Secondary Market
Swiss regulatory license requirement for Swiss-based exchanges trading Functional Tokens?
In general, yes (if: (1) relative right, (2) suitable for mass trading,
In general, no (BCP Class 1 refers to Tokens with no Depends on
and (3) fulfilling formal requirements of uncertificated Depends on specific case
relative right against a legal counterparty) specific case
security)
Swiss regulatory license requirement for Swiss-based exchanges trading BCP Voucher Tokens or Pre-Functional Tokens?
Secondary Market
Depends on specific case (possible, if: (1) relative right, (2) suitable for mass trading, and (3) fulfilling formal requirements of uncertificated security)
Intermediated transfer
Anti-money-laundering provisions: self-regulatory-organisation (SRO) membership or a directly subordinated financial intermediaries (DSFIs) approval for exchange required?
19
Annex 2: BCP Classification & Assessment of BTC
Token Evaluation
Bitcoin (BTC)
Measures
required
Underlying BCP Protocol
Hard Fork History Hard forked in July 2017 (BTC – BCH) and October 2017 (BTC – BTG)
IP rights Open-source
In relation to BTC 1
In relation to BTC 1
In relation to BTC 1
In relation to BTC 1
Trading Volume High/Low
$ 23.5B (06.01.18) / $ 0.8B (25.09.18)
(180d)
In relation to BTC 1
Trading Volume High/Low
$ 14.1B (06.02.18) / $ 5.7B (25.02.18)
(30d)
In relation to BTC 1
20
In relation to BTC 1
In relation to BTC 1
pre-sale, pre-allocation, com-
Decentralised non-TGE-distribution
munity allocation
Price finding mechanism,
Decentralised non-TGE-distribution
contribution cap
issuing legal structure Decentralised non-TGE-distribution
AML, contributor suitability
Decentralised non-TGE-distribution
compliance
Cross-border offering Decentralised non-TGE-distribution
BCP Classification
BCP Class 1
Risk Assessment
Full Source Code Screening Required?
Measures required
No Sufficient Market Experience with Token
*Risk Definitions based on the separate “BCP Risk Assessment (BCP RA)”
Risk Categories: 1 (very low risk) - 5 (very high risk)
21
Long history of stability and functionality
Risk Extent 3
Wallet System Risk:
Risk Probability 2
Net Risk 2.5
No deviation from general BCP 1 risk
Risk Extent 3
Cyber Security Risk
Risk Probability 2
Net Risk 2.5
No deviation from general BCP 1 risk
Risk Extent 2
Regulation-Related Risks
Risk Probability 2
Net Risk 2
Market-Related and Counterparty Risks
22
Risk Probability 2
Net Risk 2
No deviation from general BCP 1 risk
Risk Extent 2
Operator Counterparty Risk
Risk Probability 2
Net Risk 2
Hard forked in July 2017, SegWit2x fork planned
17.425
Risk Category: A
Risk Category A
BCP 1A
23
Your Contacts
Dr. Luka Müller Dr. Andreas Glarner Thomas Linder Stephan D. Meyer
Legal Partner Legal Partner Tax Partner Research Associate
MME is an innovative, cutting edge consulting firm for all of your legal, tax, and compliance needs. Our crypto, blockchain and
fintech clients range from established international institutions to some of the world's most innovative start-ups with the
potential to become market disrupters. MME is a member of World IT Lawyers (www.worlditlawyers.com) and founding mem-
ber of the Digital Finance Compliance Association (http://en.dfca.ch/) as well as the Crypto Valley Association (https://crypto-
valley.swiss/).
24