Tokenized: A Token Protocol for the Bitcoin (BSV) Network

Date: 21/11/18

Version: 0.11 Alpha (Public Release)

By James Belding, Samuel Georges, Scott Barr,

Farid Uddeen, and Brendan Lee

Special thanks to Joannes Vermorel for his

visionary work, Tokeda, from which inspiration was

drawn.

Abstract: This paper explores a practical approach to a generalized digital token system that allows for the issuance, management and exchange of tokens on the Bitcoin Satoshi’s Vision (BSV) network - to be referred in this paper as simply Bitcoin (BSV).

A general and standardized token protocol built upon a public, global, immutable, reliable and uncensorable ledger, such as the Bitcoin network, has the potential to contribute significant value to society by increasing market and institutional confidence, reducing legal risks and costs, increasing economic freedom, and lowering the costs of voluntary exchange. All token systems are subject to complex, dynamic and interacting technical, political and economic realities. With consideration of these realities, the most important goal of any token system is that it allows for practical and beneficial use cases. This goal means that the system cannot operate in isolation, but must interact with external human systems in a way that allows the ledger to influence human action.

Tokens are fundamentally different to cryptographic currencies in that their legitimacy as a record of ownership requires a form of ongoing and evolving consensus by the institutions that recognize and enforce property rights. An immutable and uncensorable record of ownership is meaningless if the owner can’t exercise any ownership rights over the underlying property. The simple truth is that no digital ledger, regardless of implementation, is capable of reaching into the physical world to enforce property rights. Therefore, for any token system to gain widespread adoption, it must respect the constraints and concerns of the legal and law enforcement institutions that are the ultimate arbiter of property rights in the jurisdiction to which the assets are subject.

The Tokenized protocol is altogether contained within the OP_RETURN payload of a standard Bitcoin transaction with the exception of the input and output addresses. Token transactions are validated by issuers using off-chain smart contracts allowing for flexibility and interoperability with any legal or governance system. This architecture gives the potential to create borderless and censorship-resistant contracts that can achieve levels of trust and efficiency beyond what is generally achievable within traditional frameworks.

Most valuable tokens require a contract of some form to give legal structure to the token. The Tokenized protocol will provide any entity (issuer) the ability to create their own contract with unique terms and conditions, and give them the freedom to allow other parties (users) to participate in that contract on a permissionless and voluntary basis. However, an important aspect of the design is that the issuer - to whom the contract is a liability - has complete freedom to choose which entities can participate as parties to the contract and that no issuer or token owner is forced to enter into a contract with another party against their will. This feature makes one of the foundational features of a free market - freedom of contract - an intrinsic part of the design.

Note: Where the term ‘Bitcoin’ is used, this document refers exclusively to Bitcoin Satoshi Vision (BSV). Bitcoin (BSV) is the only protocol that is consistent with the Bitcoin white paper and Satoshi Nakamoto’s original vision.

Page 1 of 52

Table of Contents

1 Introduction 4

2 Tokens 4

3 Philosophy 6

3.1 Trust 7

3.2 Economic Freedom 8

4 Protocol 9

4.1 Token Balance 10

4.2 Burning and Minting Tokens 10

4.3 Action Mechanism 11

4.4 Stateless/SPV Wallet Compatible 12

4.5 Voting 13

4.6 Enforcement/Compliance 13

4.7 Consensus Model 13

4.8 Actions 14

4.9 Order of Operations 16

4.9.1 Rules 17

4.9.1.1 Contract Operations 18

4.9.1.2 Asset Operations 18

4.9.1.3 Transfer Operations 19

4.9.1.4 Governance Operations 19

4.9.1.5 Enforcement Operations 19

4.9.1.6 Messaging Operations 20

4.9.1.7 Registry Operations 20

4.9.2 Flow Diagrams 20

4.9.2.1 Example 1: Security Token Offering [Contract Formation > Asset Creation > Issuance] 20

4.9.2.2 Example 2: Initiative 21

4.9.2.3 Example 3: Confiscation 22

4.9.2.4 Example 4: Share Repurchase 22

4.9.2.5 Example 5: Share Dilution 23

4.10 Authorization Flags 23

4.10.1 Contract Authorization Flags 23

4.10.2 Asset Authorization Flags 24

4.11 Operations 26

4.12 Asset Types 26

4.12.1 Asset Type Register: 26

4.12.2 Share - Common (SHC): 27

4.12.3 Movie Ticket (MOV): 28

Page 2 of 52

4.12.4 Admission Ticket (TIC): 29

4.12.5 Coupon (COU): 30

5 System Design 30

5.1 Overview 30

5.1.1 Control Hierarchy 31

5.2 Contracts 31

5.2.1 Contract Formation 34

5.2.1.1 Agreement 34

5.2.1.2 Consideration 35

5.2.1.3 Capacity 35

5.2.1.4 Intention 35

5.2.1.5 Certainty 35

5.3 Assets 35

5.4 Token 36

5.5 Issuers 36

5.6 Users 36

5.7 Smart Contract Operator 36

5.8 Issuer Platform 37

5.9 Issuer Wallet 37

5.10 User Wallet 37

5.11 Registry 37

5.12 Messaging 38

5.12.1 Message Type Register 38

5.13 System Analysis 39

5.13.1 Impact on the UTXO Set 39

Assumptions: 40

Non-Payment Related UTXO Growth Projection (Worst Case) 43

5.13.2 Minimization of Near-Dust UTXOs (Optional Proposal) 43

5.13.3 Transaction Ordering 44

5.13.4 0-Confirmation Reliability 44

5.13.5 Double-Spend Detection 45

5.13.6 Chain Splits 45

5.13.7 Chain Reorganizations 46

5.13.8 Technical Risks 46

6 Use Case Methods 47

6.1 Single Usage Tokens: 47

6.2 Repeated Usage Tokens: 47

6.3 Multiple Concurrent Usages (e.g. streaming TV service subscription): 48

7 Definitions 48

Page 3 of 52

1 Introduction Many thought leaders in the cryptocurrency space have mused over the advantages of using ‘tokens’ or ‘coloured coins’ - to represent ownership of anything of value, including real-world assets. The advantages of

1

a tokenized system in comparison to the current system of fragmented private databases and paper records are numerous and include:

● Low barriers to entry ● Information symmetry ● Full public and immutable record of ownership/transaction history ● Pseudonymous ownership ● High-level of interoperability ● Removal of middlemen and double-handling ● Quick ‘true’ settlement time ● Low cost ● Convenient

These advantages are becoming more pronounced as we see the adoption of cryptocurrencies continue to increase with high levels of interest and investment in platforms that enable the rapid creation and issuance of digital assets. The maturation of the cryptocurrency industry is incentivizing the creation of a robust supporting infrastructure which is, in turn, improving the value proposition. Evidence of this can be seen in the rapid rise, magnitude and popularity of initial coin offerings (ICO) created on the Ethereum network. ICOs, using the ERC20 token protocol, have yet to prove themselves to be a viable and stable way to manage token issuance, exchange and governance over the long term. However, the proliferation and value of ICOs has shown that there is a strong appetite for the practical delivery of tokenized assets.

Tokenized’s token system built on the Bitcoin network will offer users and issuers a better value proposition than competing solutions and will be lower in cost compared to what exists in the current paradigm.

There is evidence to suggest that a global system based on digital tokens would have many advantages over the current system. However, getting from where we are now to a future where every asset is represented by a (set of) digital token(s) presents many challenges and requires both the consideration and involvement of current governance structures and legal institutions.

2 Tokens The word ‘token’ (i.e. coloured coin, security token, digital token, tokenized asset, representative money, distinguished money) refers to a class of methods that use the Bitcoin network to record the ownership, management and transfer of extrinsic assets other than bitcoin. The use of ‘extrinsic assets’ here is meant to represent any intangible or tangible assets, including but not limited to:

● Financial products (shares, stocks, bonds, futures, swaps, options, etc.) ● Licenses ● Trademarks ● Copyrights ● Patents

1 Dr. Craig Wright: https://www.youtube.com/watch?v=rPO4BLw5OXc https://www.youtube.com/watch?v=74XhvbXx_pY Joannes Vermorel: https://blog.vermorel.com/pdf/tokeda-2018-04-30.pdf Andrew Stone: https://medium.com/@g.andrew.stone/bitcoin-scripting-applications-representative-tokens-ece42de81285 Stephen McKeon: https://hackernoon.com/the-security-token-thesis-4c5904761063 Anthony Pompliano: https://medium.com/@apompliano/digital-securities-unlocking-the-cheapest-capital-27d913e0633d

Page 4 of 52

● Minerals and resources ● Land titles ● Automobiles, boats, planes, etc. ● Currency ● Tickets (movie, event, airplane) ● Coupons ● Loyalty/reward points

The key difference is that these are value-holding assets that cannot be stored on the Bitcoin blockchain directly, as opposed to bitcoin which is an asset intrinsic to the blockchain.

2

The term ‘coloured coin’ - the most popular name for most of Bitcoin’s history - comes from the idea of ‘colouring’ or marking a nominal amount of bitcoin to represent something other than the bitcoin value itself. 3

The term ‘token’ has grown in usage thanks to the Ethereum community and the mainstream popularity of ICOs. These terms can be used interchangeably, but the term token (related: tokenization, tokenized, etc.) is preferred. One important thing to note is that Tokenized’s protocol does not actually ‘colour a coin’ in the classical sense. All token balances are recorded in the OP_RETURN payload and are accounted for by the associated off-chain smart contract (an autonomous agent) with respect to the terms and conditions of the contract, as well as the state of the blockchain (e.g. max supply of tokens). No satoshis are actually ‘consumed’ to represent a token, effectively decoupling the quantity and value of tokens on the network from the use and value of Bitcoin as a currency. This is an important design feature with respect to its impact on the stability of Bitcoin’s supply relative to other goods and services. A fixed quantity of money has merit, but a highly deflationary money supply can cause problems in an economy, just as a highly inflationary money supply can. The cost of coloured coins is also likely to become prohibitive as the price of BSV rises to a more stable valuation.

The advantage of using the Bitcoin network as the backbone for Tokenized, as opposed to another blockchain or database, is that it confers the same strengths that give Bitcoin its value. While there has been widespread experimentation with the creation of ‘altcoins’ since the inception of Bitcoin, it is not yet clear that any significant innovations or improvements have been made to the basic Bitcoin model as described in the original white paper by Satoshi Nakamoto. Bitcoin is the only network that uses Satoshi's original vision as a 4

roadmap which has resulted in a credible community of developers, business leaders and visionaries that firmly support the foundational idea that Bitcoin’s utility comes from its ability to be a medium of exchange akin to cash and as a general purpose ledger for record keeping. Significant work by development teams including Lokad, nChain and Bitcoin Unlimited is currently taking place to develop and test real solutions for scaling to global adoption levels with initial results indicating that no significant technological, or economic barriers need to be overcome to achieve this. It is also important to note that the basic Bitcoin architecture allows for highly parallel processing, allowing for scale at levels well beyond global adoption with currently available technology.

Another important aspect to the use of tokens on the Bitcoin network is the ability to implement ‘smart contracts’ which allow for important functions such as voting, enforcement orders and fulfilling rights and obligations-like distributions. These functions are critical to ensuring the practical management of most types of token use cases, however, the value of smart contracts goes well beyond enabling token management functions. Smart contracts also offer the potential to significantly increase the efficiency of common economic interactions while also providing predictable, transparent and fair methods to settle disputes, which may reduce the need for lengthy and costly legal proceedings. Low-cost and standardized smart contracts - especially combined with a reputation system to guide users on the fairness and robustness of various standardized contracts - can go a long way towards empowering organizations of all sizes for any legal interactions they may face. It is very difficult to disprove the legitimacy of an immutable blockchain record,

2 https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc 3 https://en.bitcoin.it/wiki/Colored_Coins 4 https://bitcoin.org/bitcoin.pdf

Page 5 of 52

which significantly lowers the barrier to entry for conducting business, and reduces the cost of trust and voluntary exchange more generally.

While the full potential of smart contracts has yet to be explored, the goal of Tokenized is to ensure they are considered the 2nd killer app of the Bitcoin distributed ledger.

3 Philosophy

“Economics is not about things and tangible material objects; it is about men, their meanings and actions.”

- Ludwig Von Mises, Human Action

A token system, like Bitcoin itself, is as much an economic system as it is a technical system. In the case of Bitcoin, it is incentivized human action that ensures that the Bitcoin network perpetuates through time and at a grand scale, as long as it continues to provide strong economic benefits for both miners and users. Bitcoin’s economic incentive structure has led to the creation of a globally significant distributed network incorporating billions of dollars of infrastructure in less than a decade. A viable token system must support this incentive structure while also ensuring that it possesses a strong and stable incentive system of its own. It is worth reinforcing the fact that the only purpose of a token system is to provide economic utility to both users and issuers. It is therefore critical to truly understand what users and issuers want out of a token system, and that a token system’s design is optimized to maximize utility (or value) for both users and issuers.

A strong focus on optimizing for maximum utility is the core design philosophy of Tokenized, and is what separates Tokenized from competing token solutions. Tokenized is unabashed in its design choice to use off-chain smart contracts to keep as much processing and data off-chain as possible. Only as much data as is necessary to ensure that property ownership can be recognized and rights enforced will be stored on-chain, allowing the Tokenized protocol to foster a compelling token ecosystem for the lowest possible cost to users. The Tokenized model aims to win market share by servicing the majority of use cases and creating powerful economic incentives for rapid adoption in a diverse set of marketplaces.

While it is important to place the interests of users and issuers at the forefront of the design philosophy, it is also necessary to consider the interests and concerns of all stakeholders that play a part in the success of Bitcoin. The Bitcoin system is primarily composed of users and miners, but it also relies on legal institutions to recognize Bitcoin transactions as legitimate forms of voluntary exchange and on law enforcement organizations to enforce property rights. Legal institutions and law enforcement organizations are critical because Bitcoin may be protected by effectively unbreakable cryptography, but its users are not protected from the logic of violence in the real world. With this in mind, one of the most important design features is to provide functionality to allow authorities some control over property to protect Bitcoin users, and it is unlikely that legal authorities will recognize a digital token system to be a legitimate record of ownership if the token system does not afford them the ability to confiscate assets. In conclusion, it is important to understand and respect the concerns and interests of legal and law enforcement institutions for the benefit of both Bitcoin and token owners. Like Bitcoin, a token system requires users, miners, legal institutions and law enforcement organizations to work together, however, it also introduces a fifth actor – the token issuer. While token owners are still vulnerable to coercion, token owners also require trust in the issuer. It is important to note that a token represents something of value. That underlying value can be anything including ownership rights to an asset, or the promise of a future good or service, however, it is important to place maximum emphasis on the fact that a token is not value in and of itself and any token representing something of value is ultimately valueless if the token’s owner cannot benefit from the underlying asset. Therefore, it is critical to ensure that the token

Page 6 of 52

system allows the issuer to control their tokens in a way that satisfies their goals while also providing them the ability to comply with whatever rules, terms/conditions, laws or regulations that they choose to comply with. The Tokenized system operates in full recognition that decentralization, cryptographic techniques and clever protocols are simply tools used by Satoshi Nakamoto to allow the Bitcoin network to provide its users with an immutable, uncensorable, public, reliable and global ledger. It is these properties that give the ledger value. The tools that create this value are irrelevant and can be changed, as long as these essential properties and the incentives are not affected. The Bitcoin protocol leverages these valuable properties to create digital money which is Bitcoin’s first ‘killer app’ - and which is intrinsic to the Bitcoin system as it provides the incentive framework necessary to secure and perpetuate the network through time. This money has incredible utility as a medium of exchange, can’t be manipulated and has a fixed supply, making it an excellent store of value. The Tokenized system leverages the value-giving properties of the Bitcoin network to create a standard system for all of the world’s contracts, financial transactions and commercial records.

3.1 Trust Societies function because at a foundational level, humans trust each other to behave in a predictable manner. Most of us have a common understanding of both our own motives, emotions and behaviours, as well as those of the people we interact with, and we perceive that understanding to be reliable. So reliable, in fact, that we design our lives around this trust.

We all have an appreciation for the consequences of actions and events as they affect people, and we intuitively know how people will behave in most circumstances. It is this trust that enables us to drive a car on a road at high speed, while strangers drive their cars in the exact opposite direction with only a painted line providing guidance. People feel comfortable with this risk because there is a strong belief - or trust - that others will behave in a way that is self-preserving. This basic truth provides the basis of our entire economic system. We trust surgeons to perform complex and invasive procedures on us, and chefs to cook our food properly. We trust pharmaceutical companies to produce safe drugs, and doctors to prescribe them. We trust pilots and bus, train and taxi drivers to get us safely to our destination and generally, we trust the police to protect us. The function of today’s society is completely dependent on the implicit trust that millions of strangers will behave in predictable, self-preserving ways.

Our modern economies rely on legal frameworks to create and strengthen incentives that help to improve our ability to trust strangers. A general understanding of the consequences of breaking the law provides stability and peace of mind for market participants, and it is the rule of law that allows for people to have the confidence to engage in complex contracts with strangers. Contracts that are formed outside of the legal system - illegal/black market trade for example - nearly always means that participants will have to resort to violence or the threat of violence to enforce terms or conditions that are breached. This is not necessarily because the contracting parties want to be violent - they just have no other means of creating a powerful enough disincentive to offset the incentive to act contrary to what has been agreed. Society utilizes trusted institutions to leverage incentives that help shape behaviour towards a positive outcome for society. This institutionalised trust enriches society, so any system that seeks to improve the way trust is managed must facilitate and enable the wider application of trust in our daily lives.

With these thoughts in mind, it is important to note that trusting the issuer is an intrinsic and inextricable property of all tokens, and that many disputes relating to an issuer failing to honour their obligations can be impractical and/or expensive to enforce. Examples include:

● Movie/concert tickets ● Financial products (e.g. shares, derivatives, bonds) ● Loyalty points ● Lottery tickets ● Train/bus passes

Page 7 of 52

● Memberships (e.g. gym, club)

All of these forms of value require the liable parties in the contract - the issuer - to honour the terms and conditions of the contract. The value may be derived from a promise by the issuer to provide access to a service, or perform a certain set of actions over time.

An illustrative example is where an investor buys shares in a company with the hope of earning a future return on the investment. Generally, the purpose of a company, set out in the shareholders’ agreement, is to carry on business activities in such a way that profit can be generated and ultimately distributed as a return to all shareholders. In order for this to happen, the management of the company (issuer) will need to conduct themselves in such a way as to ensure that the business is successful. The outcome is completely dependent upon the skill, integrity, and fortuity of the issuer in its fulfillment of the promise. Despite the immutable nature of the contract, it is impossible for the Bitcoin network to ensure that issuers behave competently and with the best intentions. It is also very difficult to distinguish malicious intent from incompetence, and therefore justice is often not served well when holding management to account for undesired outcomes.

This example serves to highlight how much trust is typically placed on the issuer and how ‘grey’ the accountability can be. Prosecuting violations to the terms and conditions of these types of contracts is often not worth the time and cost, due to the inherent complexities, overheads and of the legal system. It is the consequences that the market dishes out to the issuers that keeps them acting in good faith. For example, it is fairly obvious as to what would happen if an issuer did not honour a movie ticket, social media would hear about it, and most likely the issuer’s future revenues would be affected, severely. In a tokenized world, with the transparency that the blockchain provides, information around issuer violations of token contracts could be disseminated throughout token owner networks (Twitter, forums, Reddit, Slack, etc.) in a much more transparent way than it can be today. Online complaints can be backed up with irrefutable on-chain proof. The same can be said for a company’s stock price. The collective actions of informed token owners will keep issuers in line and will make breaking the explicit terms and conditions of most tokens unthinkable.

It is with this nuanced understanding of the realities of trust in our society that the Tokenized system chooses to place such strong emphasis on the benefits of using a token system based upon off-chain smart contracts for which the issuer takes full responsibility of the basic management. The main reason that trust is placed on the issuer is simply due to the nature of what a token is and the fact that adding more trust to the equation through the responsible management of the smart contract does not meaningfully increase the risk of token ownership. For the token system to work, it must be trivial to prove that either the issuer or the user has acted in contradiction to the terms and conditions of the contract. The Tokenized trust-but-verify model satisfies this requirement and is a fair, practical, low-cost and simple way to create usable tokens that are suitable for mainstream global adoption.

3.2 Economic Freedom

“No one may threaten or commit violence ('aggress') against another man's person or property. Violence may be employed only against the man who commits such violence; that is, only

defensively against the aggressive violence of another. In short, no violence may be employed against a nonaggressor. Here is the fundamental rule from which can be

deduced the entire corpus of libertarian theory.”

-Murray N. Rothbard from War, Peace, and the State

The Tokenized system will be open to and useful for every man, women and child the world over. Its primary aim is to improve the lives of people by offering them a better way to engage in voluntary exchange, and at a much lower cost than what has been possible to date. A guiding principle towards this goal is to provide universal tools that increase economic freedom. Roger Ver and Brian Armstrong have both made strong

Page 8 of 52

arguments supporting the notion that having high levels of economic freedom is beneficial, and that the advent and widespread adoption of cryptocurrencies will serve to further increase economic freedom worldwide. These are reasonable conclusions that are supported by empirical evidence, large volumes of

5

credible academic research and common sense axioms.

While there is always the possibility of confusion between causation and correlation with such an argument, the Tokenized protocol provides flexibility to allow issuers the ability to choose to abide by regulations, providing an environment where different regulatory regimes can compete and coexist. This allows businesses to go where business is most profitable, either due to a particular jurisdiction’s economic freedom, or conversely, where there is a lack of economic freedom, but the right combination of regulations. The Tokenized protocol therefore allows for more economic freedom, but without requiring it, or hampering useful laws and regulations.

The two pillars of economic freedom are the freedom of contract and the recognition and enforcement of property rights. Every good economic system respects these principles and governments that are sensible, fair and efficient with respect to the administration of laws that support and defend these principles, typically have better outcomes for their citizens. The Tokenized system seeks to improve the administration of these principles in societies across the world by making it easier, cheaper and more transparent to record and recognize property rights through the immutability of the Bitcoin ledger.

Freedom of contract is supported by Tokenized by enabling tools for anyone, anywhere, to create a contract using whatever terms they like with any other person (or persons) in the world on a permissionless and voluntary basis. Where either party does not wish to abide by the laws of the jurisdiction they live in, the censorship-resistant nature of the Bitcoin blockchain allows them to create contracts and tokens that effectively ignore undesirable regulations. While this is done at their own risk, a record of the contract is broadcasted and recorded as safely as a Bitcoin transaction. These contracts can be sent to the ledger from any location from which the Bitcoin network is accessible, and cannot be restricted without restricting access to Bitcoin itself. Issuers are able to operate their own smart contracts or have trusted 3rd parties operate them on their behalf. Bitcoin also allows payments to be made to smart contract operators in countries with favourable regulations.

4 Protocol The Tokenized protocol utilizes 27 actions (see section 4.8) that allow for the creation, issuance, management, and exchange of tokens for all token use cases. All actions and related token metadata are stored on-chain using OP_RETURN transactions. All Tokenized OP_RETURN payloads are prefixed with the protocol identifier - 0x00000020 - in line with Terab’s guidelines. Tokenized protocol actions are identified by action Prefix codes

6

contained within the OP_RETURN payload.

The protocol uses standard pubkey scripts that ‘Pay-to-PubKey-Hash’ (P2PKH), and utilizes input and output addresses to identify contract participants - or contracting parties - by the index number and to make the necessary BSV payments. Where outputs are required that don’t need Bitcoin output values, the nominal figure of 546 satoshis will be used to comply with dust filtering rules. When the dust filtering rules are changed then a lower figure will be used, with 0 satoshis considered the ideal option.

All actions related to a particular contract are linked by the smart contract’s public address. For an action to be valid it must be sent to, or from, the smart contract’s public address. The only exceptions to this rule are the Messaging action (M1) and the Registry actions (R1 - R4). Therefore, for a wallet to track a token, all it has

5 Roger Ver: https://www.youtube.com/watch?v=kMTsY3C3Fd0 Brian Armstrong: https://blog.coinbase.com/how-digital-currency-will-change-the-world-310663fe4332 6 https://github.com/Lokad/Terab/blob/master/spec/opreturn-prefix-guideline.md

Page 9 of 52

to do is add the token contract’s public address as a watch-only address and monitor it for actions relevant to the token owner.

If a user has a token sent to his wallet - assuming the wallet’s software supports the Tokenized protocol - the wallet will look for and recognize the OP_RETURN payload protocol identifier prefix and will then proceed to parse the rest of the OP_RETURN payload. The wallet will mark the transaction as a ‘token transaction’ and will update the user’s account balance to adjust for the received tokens. The wallet will also store the smart contract’s public address as a watch-only address and will monitor the address for further actions relevant to the owned token. The burden put on a thin client can be reduced at the connection level by narrowing the transactions to ‘watch’ by using bloom filters and logic to filter out all of the actions the user is not interested in. The only actions a user would be interested in are ‘contract-wide’ actions (votes, Contract Amendments, Asset Modifications, etc.) that are identified by transactions where the contract address is in the index 0 position of both the input and output of the transaction. The metadata related to the token can be retrieved from the Contract Formation and Asset Creation transactions which are generally among the first transactions on a smart contract’s public address. The wallet can search the smart contract’s transaction history to find the latest valid revision of Contract Formation and Asset Creation actions to ensure amendments have been considered. Ultimately, the token owner’s wallet only needs to concern itself with ‘contract-wide’ transactions whereby the contract’s public address is in the index 0 position of the inputs as well as index 0 of the output, and for token balance updates, which are only the subset of transactions sent from the contract’s public address that also has their address as an output.

4.1 Token Balance

A wallet’s token balance can only be affected (debit/credit) by a Settlement action, an Asset Creation action, a Confiscation action or a Reconciliation action. All other actions only signal intent to the smart contract to debit/credit the balance and do not actually affect the balance of tokens. The smart contract must ‘sign-off’ on the request action by publishing a response action. An Exchange action followed by a Rejection action - or no action - from the smart contract will be ignored by the protocol, and no tokens will change hands. A Rejection action effectively invalidates an Exchange action so that the last Settlement action is still referred to for token balances. The total quantity of outstanding (aka circulating, issued, supply) tokens is determined by the Qty subfield on the latest revision of the Asset Creation action. Any differences between the balances accounted for by the total tokens given to token owners by way of a Settlement action and the Qty field are tokens owned by the issuer. When tokens are first created with the first Asset Creation action, all created tokens are owned by the issuer - ‘treasury tokens’ - until they perform a Transfer Operation to change ownership. If an issuer has no tokens then an auditing entity can verify that the total outstanding tokens is equal to how many that are held by token owners by simply adding up all the Settlement balances. The Confiscation action is similar to the Settlement action in the resulting balances of the affected parties are published in the metadata. This is in response to the quantity of tokens that is to be confiscated, specified in the Order action. The Reconciliation action is a record-keeping tool used to delete targeted extraneous token balances that may appear at a sender’s public address due to breaks in a chain of 0-conf token transfers. In other words, if for some reason the network dropped a token transfer transaction that had many downstream and dependent 0-conf token transfers, with no UTXO dependencies, then the transferred quantity of tokens would be returned back to the original sender just before the break in the chain. This would increase the total outstanding tokens by the amount specified in the dropped transaction. A Reconciliation action can be used to amend the break in the chain with respect to token balances, and will leave all the downstream token transfers in place. With the correct application of risk mitigation algorithms and strategies, this will be considered a very rare event, but it is important to have measures to deal with edge cases if they appear.

Page 10 of 52

4.2 Burning and Minting Tokens

Burning tokens can only be done by an issuer and only when they own the tokens. A burning operation is simply an Asset Modification action that decreases the total token quantity (subfield: Qty) of the asset. The smart contract will only permit token burning for a quantity of tokens up to the full amount held by the issuer as a current asset. An issuer can also increase the total token quantity for a given asset - known as minting new tokens - by broadcasting an Asset Modification action that increases the total token quantity (Qty subfield) of the asset. The minting and burning functions are restricted/permitted by the smart contract in the authorization flags of the Contract Formation action. A prominent example use case for the minting and burning of tokens is when a company wants to perform a share repurchase/buyback (burning) or a share dilution (minting). It is helpful to think of an issuer’s tokens in terms of how they are represented on the issuer’s balance sheet. When an issuer creates shares, an entry in the shareholder’s Equity section is added to the balance sheet to represent the quantity of shares created, also known as ‘treasury shares’. When the issuer sells some of these shares, they are effectively trading shares in the Assets column for cash, which will also be added to the balance sheet in the Assets section. If the issuer were to buy back shares, they would effectively be trading cash for shares and are then able to retire the shares in the Equity section with an equal and offsetting impact seen in the Assets section under the ‘Cash’ line item. Depending on the authorization flags and actual terms and conditions of the contract, issuers may be able to confiscate tokens from addresses arbitrarily. Once they’ve confiscated the tokens, they can burn them with the process described above.

4.3 Action Mechanism

All Tokenized token-related actions operate with the ‘fire-and-forget’ mechanism first described in Joannes Vermorel’s paper Tokeda. The fire-and-forget mechanism - to be known as the ‘request-and-response’ 7

mechanism in this paper - works by using two actions by two different classes of actors. The two classes of actors are the investors, issuers, and token owners. The second class of actors are the smart contracts which are code representations of the ‘spirit and letter’ of the associated token contracts. The first stage of the request-and-response mechanism, is where a user broadcasts a ‘request’ transaction to the Bitcoin network. An example of a request transaction is the Exchange action. The smart contract monitors the mempool/blockchain of the bitcoin network and when it identifies a Tokenized action pointed at it (smart contract’s public address in the output), it will complete the second stage of the request-and-response mechanism by broadcasting a ‘response’ action which would be either a ‘validation’ response or ‘rejection’ response transaction to the bitcoin network.

The request-and-response mechanism is an incredibly powerful method when one considers actual use cases, how business is conducted and how the legal system actually works. The fact that all meaningful actions are published to the public and immutable Bitcoin ledger effectively allows the Tokenized protocol to operate completely on-chain. It also means that every user of the Tokenized protocol is able to enjoy the same censorship-resistant properties as Bitcoin, and it means that users can act in a permissionless manner. Smart contract operators, issuers and users can act pseudonymously if they choose to. If two users want to exchange tokens, then no one can stop them from broadcasting their ‘exchange agreement’. For a majority of use cases, a request-and-response mechanism provides novel and unprecedented utility to both users and issuers, at a trivial cost.

For users it means that they have an indisputable, signed, immutable, timestamped and publicly available record by which to prove the existence of their exchange agreement to any interested parties. If their exchange agreement was in accordance with the terms of the contract, then the smart contract’s validation response is only a matter of bookkeeping. If the smart contract fails to respond with a validation transaction (e.g. Settlement action), then the users involved in the exchange agreement would be able to seek legal recourse with the best proof possible. The validation transaction also provides peace of mind and a legally meaningful ‘sign-off’ by the issuer to say that the exchange agreement was lawful and within the terms and

7 https://blog.vermorel.com/pdf/tokeda-2018-04-30.pdf Page 11 of 52

conditions of the token contract. Most token use cases rely on the issuer to honour the terms and conditions of the token contract, so having that sign-off by the issuer at the time of exchange, and critically, before money actually changes hands, adds significantly to the potential for widespread trust and adoption.

This allows for users to reliably ascertain that the counterparty (issuer) approves of the transaction, and that they will honour all rights and benefits associated with the ownership of the token - all done conveniently within a matter of seconds for a fraction of a cent. It also means that some of the due diligence required in determining whether or not their exchange action is in accordance with the relevant laws and with the terms of the contract, is outsourced to the smart contract. All users benefit from the automation of this step, and is a relatively trivial cost for the issuer. The mechanism also means that users will know if their exchange agreement is in contradiction to the terms of the token contract, or the relevant laws, before the transaction is settled. Most importantly, buyers of tokens don’t actually hand over bitcoin until they know that they will be able to access the value of the token they are purchasing.

For issuers, the request-and-response mechanism is also very important because it allows them to control who they engage into contracts with. This allows them to choose to be selective with applicable laws and regulations, but also to have a large degree of expressiveness in exercising their right to freedom of contract. Trade groups, private organizations, shareholder agreements, clubs and region specific deals are a few important use cases that require whitelisting and control over who participates as a party to a token contract. Issuers also have the freedom to let anyone exchange their tokens, and pseudonymously, if they so wish. Therefore, issuers have the best of both worlds and most issuers will consider this to be a positive freedom and something that will cause them to use the Tokenized protocol over competing solutions.

The mechanism also absolves the issuer from accusations of wrongdoing or manipulation since everything will be recorded on the public record. This is in stark contrast to other proposed token protocols where multisig locking scripts are used to provide issuers with control over token transactions. In a multisig controlled token system, the potential exists for the issuer to ignore partially-signed transactions, or even worse, use them to manipulate prices by holding and releasing exchange transactions at selectively chosen times. The multisig arrangement is undesirable because the partially-signed transactions are passed around off-chain. Proving that an issuer is manipulating prices or ignoring transactions is inherently more difficult than in cases where the equivalent action was published to the public and immutable Bitcoin ledger.

Another important point for the request-and-response mechanism is that it allows trading to continue in the event a smart contract goes offline. Smart contracts may need to go offline for many legitimate reasons and the ability to do so and simply ‘catch back up’ using the on-chain request transactions is a positive. Smart contracts going offline is not desirable, as the customer experience will degrade in the downtime. Also, trading can only go on for a very short period of time once the smart contract goes down before it is inhibited by the lack of Settlement transactions. Therefore, downtime should be minimized and it will likely be worth investing in, designing and operating robust and reliable smart contract systems, but it is not catastrophic if for example a bug is found or an upgrade is needed.

After careful consideration, the Tokenized token protocol has chosen the request-and-response mechanism as a foundational method because it is the best possible mechanism for any practical token system, and it is robust, flexible and expressive enough to become the technical foundation for many financial transactions the world over.

4.4 Stateless/SPV Wallet Compatible

“A stateless wallet is defined as a wallet that can be set up once - offline - and is never required to persist any further data. A stateless wallet is a more stringent form of an SPV wallet.” A 8

Tokenized-compatible wallet can be stateless/SPV because it only requires the storage of two elements: its own secret seed (associated with the address at which the tokens are stored) and the contract’s public address (associated with the token). Users don’t need to interact directly with issuers; the Bitcoin ledger acts as the

8 https://blog.vermorel.com/pdf/tokeda-2018-04-30.pdf Page 12 of 52

intermediary between issuers and users. The smart contract only reads and writes to the blockchain, and the users/issuers only interact with the blockchain as well.

4.5 Voting

The Tokenized protocol allows issuers and token owners to carry out governance by holding votes. When an issuer initiates a vote, it is called a ‘Referendum’. When a token owner initiates a vote it is called an ‘Initiative’. Votes can be about anything the issuers/token owner choose, such as corporate/organizational governance, voting on proposals, etc. The protocol allows one vote per token. However, vote multipliers can be added to specific assets to allow for more votes per token. For example, this could be useful for shareholder agreements where multiple classes of shares are on issue. Up to 15 different voting options can be used and a voting proposal document - with an on-chain hash - will detail what each option means. To filter out spam, Initiatives will usually be accompanied with a threshold fee, specified in the Contract Formation action. There are also options to vote on changes to a contract, authorization flags or changes to an asset. These options are all controlled by the terms and conditions set out by the Contract Formation action and enforced by the smart contract. The voting systems are listed below.

Voting Systems Code Comments

Majority Vote M

More than half (=>50%) wins. Abstentions/spoiled votes are not counted. If only

10% of the token owners vote, then it would take 5.0% of the total possible

votes to win the Majority.

Absolute Majority A

More than half (=>50%) wins. >=50% of all token owners must vote for the vote

to pass. Abstentions/spoiled votes only detract from the likelihood of the vote

passing.

Plurality Vote P The most favoured option is selected, regardless of the percentage of votes.

Supermajority S

More than two thirds (=>67%) wins. Abstentions/spoiled votes are not counted.

If only 10% of the token owners vote, then it would take 6.7% of the total

possible votes to win the Supermajority.

Absolute

Supermajority T

More than two thirds (=>67%) wins. >=67% of all token owners must vote for

the vote to pass. Abstentions/spoiled votes only detract from the likelihood of

the vote passing.

No Voting Rights N No voting rights permitted.

4.6 Enforcement/Compliance

The ability for issuers to comply with laws and regulations, as well as custom contracts, is a freedom in and of itself and is an extremely important part of the value proposition for the Tokenized protocol. If issuers want to comply with a particular legal framework then they should be free to do so and have the tools that allow them to comply. The three tools that the Tokenized protocol provides to an issuer is the Freeze, Thaw and Confiscate actions. These three actions allow sufficient intervention utility for any regulator/legal authority in a wide range of investigative or legal matters related to ownership of token assets through the issuer in combination with the association of real identities with public addresses. Any Enforcement operation must be initiated by the issuer or the smart contract operator. The Reconciliation action is considered to be more of a administrative Enforcement operation, but it is still an important tool for the issuer to maintain compliance with the terms and conditions of the contract.

4.7 Consensus Model

The Tokenized protocol relies on miner validation using Bitcoin consensus rules and through proof-of-work for the basic Bitcoin transactions and, by way of a smart contract, for issuer validation of the Tokenized protocol

Page 13 of 52

metadata and the token contract terms contained within the OP_RETURN payload. The smart contract also uses the position of input and output addresses to determine which contracting parties are which. If any actions are in contradiction to the terms and conditions of a token contract, then the issuer is responsible for correcting the action, and affected users must utilize the legal system for recourse if there is a dispute with the issuer. The smart contract is the singular authority with respect to the contract’s consensus rules, therefore distributed consensus is not required.

4.8 Actions

Page 14 of 52

Page 15 of 52

4.9 Order of Operations

The Tokenized protocol follows an ‘order of operations’ for all of the different actions. The order of operations must be followed by issuers and users for the contract, tokens and Transfer/Governance/Enforcement operations to be considered valid. The order of operations varies slightly for different use cases, and so it is best to examine example use cases. Any actions that don’t follow the correct order of operations will be rejected/ignored by the smart contract and will be effectively meaningless in the greater context of the contract. The following list of rules and flow diagrams illustrate the correct order of operations against time (timestamp/block height) for a few basic use cases.

Page 16 of 52

4.9.1 Rules

● All contract-initiated actions must be cash flow neutral apart from the accumulation of near-dust amounts used to identify the contract in response actions. This means that the user/issuer action that precedes all contract response actions must, at a minimum, include enough BSV to pay for the responding action. In cases where not enough BSV has been included, no response action will take place. This removes the need for the smart contract to have a reservoir of satoshis and also removes

Page 17 of 52

the need to manage the balance to prevent a situation where the contract runs out of BSV and is unable to respond to a valid action. In practice this means that the contract must receive at least ~$0.02USD (current mining fees for transactions) from a request action in order to respond with a response action. If the request action sends less than ~$0.02USD to the contract, then that bitcoin will be lost to the contract’s address.

● Every contract-initiated action - specified by the ‘Initiated By’ column on the Actions table (section 4.8) - must be in response to a user/issuer initiated action. No contract initiated action will be valid without a preceding ‘request’ action initiated by a user or issuer.

● For smart contracts, every on-chain user/issuer action must be responded to on-chain by the smart contract in either an affirmation action (e.g. Settlement, Confiscation, Asset Creation, Contract Formation, Freeze, Thaw, Vote, Ballot Counted) or a negation action (e.g. Rejection).

● All Tokenized actions must be sent to or from a contract’s public address. The contract’s public address is what connects all associated token actions. The only exceptions to this rule are the Messaging action (M1) and the Registry actions (R1 - R4). Therefore, for a wallet to track a token, all it has to do is add the token contract’s public address as a watch-only address and monitor for relevant actions.

4.9.1.1 Contract Operations

A. Every token must have a valid Contract Formation action to be considered a valid token by the Tokenized protocol.

B. Every Contract Formation action must be preceded by a Contract Offer action except for in the case of static contracts - ie. no smart contract involved - whereby the contracting parties simply wish to publish the Contract Formation action to the chain. The contracting parties can simply send the txn back to one of their own addresses to publish the transaction to the BSV blockchain.

C. The first Contract Offer and Contract Formation actions are considered to be the only valid Contract operations for a particular contract address. Any subsequent Contract Offers sent to the contract address will be ignored. There can be only one Contract Offer and one Contract Formation (Rev.0) per contract address. (When contract’s are amended the Contract Formation action increments the revision sub-field by one. Rev. 0 -> Rev. 1. The highest revision is always taken as the current one.)

D. Additional Contract Formation actions (revisions) are only valid if there is a preceding Contract Amendment action from the original issuer’s address which is identified as the input address (Index 1) on the first Contract Offer action transaction.

E. The first Contract Offer action determines the issuer’s public address and only one issuer per contract address is valid.

F. In cases where a whitelist is used, any Contract Offer that is broadcast from a public address that is not on the whitelist, will be rejected. This is to ensure know-your-customer/anti-money laundering (KYC/AML) compliance is adhered to.

4.9.1.2 Asset Operations

A. Every token must have an Asset Creation action to be considered a valid token by the Tokenized protocol. Asset Creation actions define the properties of the token.

B. Every Asset Creation action must be preceded by a Contract Formation action. C. All Asset Creation actions must be preceded by a Asset Definition action. D. The Asset Definition action must come from the issuer’s address, which is set by the input address on

the valid Contract Offer action. E. Only one Asset Creation (Rev.0) action can persist per AssetID, per Contract address. F. All additional revisions of an Asset Creation action must be preceded by an Asset Modification action

initiated by the issuer’s public address. G. A Contract’s public address can have an unlimited number of Asset Creation actions but each one

must have a unique Asset Code. This property allows for an ‘unlimited’ amount of non-fungible assets to be associated and controlled by one Contract address.

H. The first Asset Creation action assigns the ownership of all tokens created to the issuer. Page 18 of 52

I. Asset Creation actions are limited to a quantity of non-fungible assets specified by the Contract Formation in subfield ‘Restricted Qty’. Restricted Qty refers to the number of non-fungible assets that are allowed to be associated with the contract. However, each non-fungible asset can have many fungible tokens associated to it. The Restricted Qty does not restrict how many tokens per asset, only how many asset types per contract.

4.9.1.3 Transfer Operations

A. All Transfer operations must be in reference to an Asset Code specified by a valid Asset Creation action.

B. All Issue, Exchange and Swap actions must be responded to by a succeeding Settlement action. C. In cases where a whitelist is used, any Issue, Exchange or Swap action will be rejected if it would send

tokens to a public address not on the whitelist. As mentioned above, this is to ensure KYC/AML compliance is adhered to. All token owners must have their tokens stored at a public address on the whitelist.

4.9.1.4 Governance Operations

A. All Vote actions must be preceded by an Initiative action or a Referendum action. B. A Ballot Cast action is only valid if it is cast during a vote. The Vote action specifies the time period

that a vote is on, the start is the timestamp of the Vote action and the cut off timestamp is specified by the ‘Vote Cut Off Timestamp’ sub-field in the Vote action. The next block to be announced after the timestamp is the last set of transactions that will be included in the count. The smart contract will wait for six confirmations of the last valid block before tallying up the ballots.

C. Ballot Casts are counted as one vote per token as a standard convention. However, vote proposals are free to add additional rules that give some tokens more voting power than others. All of this extra functionality can be added to custom smart contracts.

D. Ballot Cast actions must be responded to by a Ballot Counted action if valid, or a Rejection action if invalid.

E. Result actions must have a preceding Vote action. F. Result actions tally up the votes specified in all the Ballot Counted actions at the end of the vote.

Ballots cast are only valid if the votes was cast by a token owner that owned the token before the valid period specified by the Vote action. Trading votes away after the vote has been announced is not permitted by the smart contract.

4.9.1.5 Enforcement Operations

A. All Enforcement operations require an Order action sent from the issuer’s address as the initiating action.

B. A Freeze action alerts the affected token owner that the smart contract will be unable to respond to any actions with an affirmative action (Settlement, Vote). All actions will be responded to with a negation (Rejection action).

C. Votes submitted by a token owner whose account is frozen will not be counted in the vote tally. D. A frozen address can only be unfrozen by a Thaw action. E. Thaw actions that are not directed at a frozen address will be ignored. F. Confiscation actions that are not directed at an address with tokens will be rejected. G. Reconciliation actions will decrement the tokens of the specified type at the targeted address to

ensure that the number of outstanding tokens issued by the issuer is maintained across the state of the blockchain. Chained token transfer actions that are broken can result in additional tokens in the system that need reconciling.

Page 19 of 52

4.9.1.6 Messaging Operations

A. Message actions can be from any address to any other address. B. Rejection actions are the negative response from a smart contract to indicate that another action is

not valid. Actions that have a Rejection action as a response are ignored by the protocol.

4.9.1.7 Registry Operations

A. All Registry operations that come before an Establishment action are ignored. B. All Addition actions are on a treated on a first seen basis. All subsequent Addition actions that are

repetitions of the first are ignored. C. An Alteration action must be preceded by an Addition action that is pointed to the same user’s

address. D. All Removal actions must be preceded by a valid Addition action.

4.9.2 Flow Diagrams

4.9.2.1 Example 1: Security Token Offering [Contract Formation > Asset Creation > Issuance]

Page 20 of 52

4.9.2.2 Example 2: Initiative

Page 21 of 52

4.9.2.3 Example 3: Confiscation

4.9.2.4 Example 4: Share Repurchase

Page 22 of 52

4.9.2.5 Example 5: Share Dilution

4.10 Authorization Flags

The Authorization Flags (a 2-byte subfield in the contract actions and the Asset actions) are binary terms and conditions that the smart contract can control/enforce.

4.10.1 Contract Authorization Flags Flag 1 - Contract Amendments Permitted (excluding Contract Authorization Flags):

This flag permits the issuer to broadcast a Contract Amendment action to make changes to one or all of the following subfields: Contract Name, Contract File Hash, Governing Law, Jurisdiction, Contract Expiration, URI, issuer ID, Contract Operator ID, Voting System, Initiative Threshold, Initiative Threshold Currency, Restricted Qty. Examples of where this flag would be used: Cross-border mergers or acquisitions might require contract names, jurisdictions and governing laws to be amended.

Flag 2 - Vote required for Contract Amendments (excluding Contract Authorization Flags):

This flag acts as a modifier for Flag 1. If Contract Amendments are permitted by Flag 1, then this flag (Flag 2) restricts amendments to only when a Vote is passed successfully that has the Vote Type subfield set to C (Contract Amendment). Votes can be initiated by Referendum or by an Initiative (restricted/permitted by Flag 5). If this flag is set to yes (1), but Flag 1 is set to no (0), then the contract cannot be amended regardless of whether a vote has occurred.

Page 23 of 52

Similar to the example used for Flag 1, hostile acquisition offers that require eventual Contract Amendments could require token owner ratification through a vote (irrespective of Referendum or Initiative). Flag 3 - Contract's Authorization Flags can be Amended:

This flag permits/restricts the issuer to amend the Authorization Flags. Example: Post-issuance bugs are detected in an issuer’s smart contract and the issuer wishes to Freeze certain assets while the bug is fixed, requiring Enforcement actions (Flag 6) to be permitted temporarily. After addressing the problem, the issuer can reinstate Flag 6 to be ‘0’. Flag 4 - Contract Authorization Flag amendments permitted with Referendum:

This flag acts as a modifier for Flag 3. If Flag 3 is set to 1, and this flag is set to 1, then a Referendum with Vote Type subfield set to F (Authorization Flags) must be held to change the Authorization Flags. Flag 4 can act as a natural check for issuers by token owner with respect to Flag 3- only critical changes to authorization flags that have widespread demand across token owners will pass. Flag 5 - Initiatives can amend the Contract:

This flag acts as a modifier to Flag 2. If Flag 1 and Flag 2 are set to 1, then this flag set to 1 will allow users to create votes (Initiatives) that allow for the contract to change. If Flag 1 and/or Flag 2 are set to 0 then Contract Amendments are not permitted regardless of what this flag is set to. Examples where this could be applicable include investment/divestment decisions for equity token owners of a given company or in cases where bankruptcy is involved and a consortium of bond-token owners proposes a viable restructuring plan. Flag 6 - Enforcement Actions Permitted:

If this flag is set to 1, then issuers are permitted to broadcast Order actions to Freeze, Thaw, or Confiscate assets (tokens) from users. If this flag is set to 0, then issuers are not permitted to Freeze, Thaw or Confiscate assets that users own. Using the example of bug detection in a smart contract post-issuance, permitting Enforcement operations at the contract level allows entire assets (all tokens) or multiple assets to be frozen during a period of troubleshooting. Flag 7 - Transfers are restricted to a Whitelist:

If this flag is set to 1, then the transfer of tokens is restricted to a nominated whitelist. The whitelist can be an on-chain registry, or it can be a off-chain whitelist. The key example for restricting transfer to a whitelist would be the very common requirement of an approved KYC/AML user list for security tokens. This is a common requirement in most regulatory regimes for trading financial products.

4.10.2 Asset Authorization Flags

Flag 1 - Asset Modifications Permitted (excluding Asset Authorization Flags):

If this flag is set to 1 then Asset Modifications are permitted with the exception of the Authorization Flags subfield. If it is set to 0 then no Asset Modifications are permitted.

Page 24 of 52

This would be required for secondary offerings of a security token whereby the number of tokens might need to be increased, or M&A situations whereby the issuer name gets amended in the contract, triggering a requirement to amend the issuer name embedded in all issued assets.

Flag 2 - Vote required for Asset Modifications (excluding Asset Authorization Flags):

This flag acts as a modifier for Flag 1. If Asset Modifications are permitted (Flag 1 set to 1), and this flag is set to 1 then a vote that has A (Asset Modification) set as the Vote Type subfield must be passed before an Asset Modification action is considered valid/permitted. If this flag is set to 0 then no vote is required for an Asset Modification action to be considered valid. If Flag 1 is set to 0, then no Asset Modifications will be permitted no matter what this flag says.

A use-case where Flag 2 would be desired could be a residential real-estate property such a condominium unit which has fractional ownership; if token owners collectively agree that a 2 bedroom apartment can and should be converted into a 3 bedroom apartment they will be able to do so with Flags 1 & 2 set to ‘1’.

Flag 3 - Asset's Authorization Flags can be Amended:

This flag permits/restricts the issuer to amend the Authorization Flags. For example, an issuer (company) may want to create a separate Asset to represent share options for employees that are non-transferable for a period of time. They can then amend Flag 8 to allow token transfers after that period of time has passed.

Flag 4 - Asset Authorization Flag amendments permitted with Referendum:

This flag acts as a modifier for Flag 3. If Flag 3 is set to 1, and this flag is set to 1, then a Referendum with Vote Type subfield set to F (Authorization Flags) must be held to change the Authorization Flags. An example of where this could be applicable would be in instances whereby issuers initially prioritized control of tokens issued by restricting Asset Authorization Flag 5 to ‘0’ but over time through feedback and dialogue with the token owners, became open to the idea of user-driven Initiatives and wanted token owners to affirm or reject the notion through a vote. Flag 5 - Initiatives are permitted:

If this flag is set to 1, users (token owners) can create an Initiative. If it is set to 0 then no Initiatives will be permitted. An example use case would be allowing for nominees to be proposed to the board of a company through user-driven Initiatives for equity security tokens. Also, the issuer may want this right to only be applicable to preferred shares, and restrict it for common shares. Flag 6 - Initiatives can modify the Asset:

This flag acts as a modifier to Flag 1 and Flag 2. If Asset Modifications are permitted and a vote is required for an Asset Modification to be valid, then this flag set to 1 allows Initiatives to be a valid vote initiation which precedes a vote to modify the asset. If Asset Modifications are not permitted then this flag does not have any bearing on Asset Modification actions. Similar to the example for Flag 2 - token owners can collectively vote on the modification of the residential property asset from a 2 bedroom to 3 bedroom. Flag 7 - Transfers Permitted:

Page 25 of 52

If this flag is set to 1, then users are free to send, exchange, and swap tokens with other users. If this flag is set to 0, then only the issuer can send, exchange and swap tokens with users.

An example use case of when transfer restrictions will be useful is when companies want to issue loyalty points or coupons to customers, but they don’t want those points/coupons to be transferable. Another example is the issuance of licences (e.g. driver’s license, or electrical license) to users. The licenses are meant for only the user and transfers would render the license meaningless.

4.11 Operations

Please see the token operations in the specification (link below) for a detailed breakdown of the metadata associated with each action that allows for the foundational operations of the protocol:

https://github.com/tokenized/specification/tree/master/protocol/develop

4.12 Asset Types This is a list of Asset Types and their 3-letter codes. The 3-letter code will be useful for filtering search results. The list will be expanded to as new Asset Types arise and this evolving process will require the market’s input to get it ‘right’. Each Asset Type has its own unique payload that is specified in the Asset operations (e.g. Asset Definition, Asset Creation and Asset Modification actions). Four example payloads unique to each Asset Type are shown in the sections below. Please see the Asset Type Register in the table below (4.12.1) and the metadata for each Asset Type in the specification repository found here: https://github.com/tokenized/specification/tree/master/assets/develop

4.12.1 Asset Type Register:

Legal

Classification Contract Type (smart contracts) Category ASCII Asset Type

Security Real Estate Ownership Agreement RRE Residential Real Estate

Security Real Estate Ownership Agreement CRE Commercial Real Estate

Security Shareholder Agreement Equity Security SHC Share - Common

Security Shareholder Agreement Equity Security SHP Share - Preferred

Security Debenture Agreement Debt Security BFR Bond - Fixed Rate

Security Debenture Agreement Debt Security FRN Bond - Floating Rate Note

Security Debenture Agreement Debt Security TIP Bond - Inflation Indexed

Security Debenture Agreement Debt Security BCV Bond - Covered

Security Debenture Agreement Debt Security REC Receivable

Security Debenture Agreement Debt Security PAY Payable

Security Simple Agreement for Future Equity (SAFE) Hybrid Security SAF Simple Agreement for Future Equity (SAFE)

Security Debenture Agreement (with Embedded Option) Hybrid Security BCB Bond - Convertible

Security Debenture Agreement Hybrid Security ABS Asset-Backed Security

Security Debenture Agreement Hybrid Security MBS Mortgage-Backed Security

Security Debenture Agreement Collateralised Contract CDO Collateralized Debt Obligation

Page 26 of 52

Security Debenture Agreement Collateralised Contract CMO Collateralized Mortgage Obligation

Security Forward Contract Derivative Contract FWD Forward

Security Futures Contract Derivative Contract FUT Futures

Security Options Contract Derivative Contract OPT Option (Vanilla)

Security Swap Contract Derivative Contract TRS Total Return Swap

Security Swap Contract Derivative Contract CDS Credit Default Swap

Security Swap Contract Derivative Contract IRS Interest Rate Swap

Security Swap Contract Derivative Contract OIS Overnight Index Swap

Security Debt Security CUR Currency Token

Identity Identity Token IDT ID Token

Identity Identity Token LIC License

Identity Identity Token MEM Membership

Identity Identity Token PPT Passport Token

Utility Utility Token MOV Movie Ticket

Utility Utility Token AIR Airline Ticket

Utility Ticketing Service Agreement Utility Token EVN Event Ticket

Utility Ticketing Service Agreement Utility Token TIC Ticket (Admission)

Utility Utility Token ACC Accommodation Booking

Utility Utility Token LOT Lottery Ticket

Utility Utility Token PUB Public Transport Ticket

Utility Utility Token ITI Infringement Ticket

Utility Utility Token VIS Entry Visa

Utility Utility Token LOY Loyalty Points / Card

Utility Utility Token COU Coupon

Utility Utility Token CCT Carbon Credit

Utility Utility Token RCC Recycling Credit

Utility Utility Token REP Reputation Point

Utility Utility Token TCD Tax Credit

Utility Utility Token PRO Item

Utility Utility Token PRT Part

Utility Utility Token INP Input

Utility Utility Token DCO Digital Collectible

4.12.2 Share - Common (SHC):

Asset

Operation

OP_RETURN for Token Creation Txn (Asset Type: Share - Common)

Field Subfield Bytes

Hex Value (Example

Values)

ASCII (Example

Values) Comments

Data

Type

Asset Creation Header (See Asset Definition, Asset Creation and Asset Amendment Actions)

Metadata

(OP_RETURN

Payload)

Version 1 00 0

For data parsing/interpretation in the

event of protocol upgrades. uint8

Trading

Restriction

(Jurisdiction/

Group/Region

Code) 3 415553 AUS

Country Code or Custom Region Code (eg.

EU, North America, Trade Agreement

Members, etc.) string

Page 27 of 52

Dividend Type 1 43 C

C - Combination of Variable and Fixed. V -

Variable, F - Fixed. string

Dividend

(Var) 4 3ca3d70a 0.02 float32

Dividend

(Fixed) 4 461c4000 10000 float32

Distribution

Interval 1 51 Q

Q - Quarterly, M - Monthly, W - Weekly, A

- Annually, B - Biannually string

Guaranteed 1 59 Y

Guaranteed flag denotes consequences

written into the Investment Contract. Y -

Yes, N- No. Most shares will be N.

However, Distribution Guarantees backed

by equity can be managed by the smart

contract for investment risk reductions. string

Ticker 5 4d53460000 MSF string

ISIN 12

5553303030343032363

23530 US0004026250

The International Securities Identification

Number (ISIN) is a code that uniquely

identifies a specific securities issue. The

organization that allocates ISINs in any

particular country is the country's

respective National Numbering Agency

(NNA). string

Description 113

4150504c43202d204170

706c6520636f7270202d

20436f6d6d6f6e207368

6172652069737375652

0636c617373204300000

0000000000000000000

0000000000000000000

0000000000000000000

0000000000000000000

0000000000000000000

0000000000000000000

0000000000000

APPLC - Apple corp

- Common share

issue class C string

Bytes 145 Payload Output:

00415553433ca3d70a461c400051594d53460000555330303034303236323

5304150504c43202d204170706c6520636f7270202d20436f6d6d6f6e20736

861726520697373756520636c617373204300000000000000000000000000

000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000

Max Bytes 153 LENGTH: 145

4.12.3 Movie Ticket (MOV):

Asset

Operation

OP_RETURN for Token Creation Txn (Asset Type: Movie Ticket (MOV))

Field Subfield

Max

Bytes

Hex Value (Example

Values)

ASCII

(Example

Values) Comments Data Type

Metadata

(OP_RETURN

Payload)

Asset Creation Header (See Asset Definition, Asset Creation and Asset Amendment Actions)

Version 1 00 0

For data parsing/interpretation in

the event of protocol upgrades. uint8

Trading Restriction

(Jurisdiction/Group

/Region Code) 3 4e5357 NSW

Country Code or Custom Region

Code (eg. EU, North America, Trade

Agreement Members, etc). Optional. string

Age Restriction 5 31332b0000 13+

All, 18+, <18, 19+, 21+, 25+, 18-30,

5-18, etc. Restricts trading to

different age groups. Ages

determined from info from the

white list. string

Page 28 of 52

Venue 32

47656f7267652053742c2

05379646e657900000000

000000000000000000000

0

George St,

Sydney

Subset of Token Issuer's (Movie

Theatre) locations string

Valid From 8 00000166e0f45180

04/11/201

8 15:00:00

Tickets cannot be redeemed before

this period. (Start time of Movie) time

Expiration

Timestamp 8 00000166e1991d00

04/11/201

8 18:00:00

All tickets will expire after this date.

End time of Movie time

Description 88

54686520496e637265646

9626c657320322e203130

2f30362f323031382e2053

637265656e20332e20436

f75706f6e3a20322d666f7

22d3120706f70636f726e2

e00000000000000000000

000000000000000000000

00000

The

Incredibles

2.

10/06/201

8. Screen

3. Coupon:

2-for-1

popcorn.

A Description of the Event. The

timestamp above will indicate the

date of the event. The Issuer will

also be able to use the AssetID to

assign non-fungible seats. However,

they may prefer to add additional

details such as Seat & Theatre

Number. Also comments regarding

permissions. eg. Combo bundling string

Bytes 145 Payload Output:

004e535731332b000047656f7267652053742c205379646e65790

0000000000000000000000000000000000166e0f4518000000166

e1991d0054686520496e6372656469626c657320322e2031302f3

0362f323031382e2053637265656e20332e20436f75706f6e3a20

322d666f722d3120706f70636f726e2e000000000000000000000

0000000000000000000000000

Max Bytes 153 LENGTH: 145

4.12.4 Admission Ticket (TIC):

Asset

Operation

Asset Creation Txn (Example Asset Type: Admission Ticket)

Field Subfield

Max

Bytes Hex Value (Example Values)

ASCII

(Example

Values) Comments

Data

Type

Metadata

(OP_RETURN

Payload)

Asset Creation Header (See Asset Definition, Asset Creation and Asset Amendment Actions)

Version 1 00 0

For data parsing/interpretation in the

event of protocol upgrades. uint8

Trading Restriction

(Jurisdiction/Group/

Region Code) 3 313247 12G

Country Code or Custom Region Code (eg.

EU, North America, Trade Agreement

Members, etc.). Optional. string

Age Restriction 5 31382b0000 18+

All, 18+, <18, 19+, 21+, 25+, 18-30, 5-18,

etc. Restricts trading to different age

groups. Ages determined from info from

the white list. string

Valid From 8 00000166e0f45180

04/11/201

8 15:00:00

Tickets are not valid/cannot be redeemed

before this period. time

Expiration

Timestamp 8 00000166f58dc180

08/11/201

8 15:00:00 All tickets will expire after this date. time

Description 120

436f696e6765656b20436f6

e666572656e6365202d204c

6f6e646f6e20284e6f76656d

6265722032303138292e20

526567756c61722061646d

697373696f6e2e200000000

0000000000000000000000

0000000000000000000000

0000000000000000000000

0000000000000000000000

000000000000000

Coingeek

Conferenc

e - London

(Novembe

r 2018).

Regular

admission.

A Description of the Event. The timestamp

above will indicate the date of the event.

The Issuer will also be able to use the

AssetID to assign non-fungible seats.

However, they may prefer to add

additional details such as Section and Seat

numbers or the date and time. Also

comments regarding permissions. eg. '1

free drink per ticket' string

Bytes 145 Payload Output:

0031324731382b000000000166e0f4518000000166f58dc180436f

696e6765656b20436f6e666572656e6365202d204c6f6e646f6e20

284e6f76656d6265722032303138292e20526567756c617220616

46d697373696f6e2e200000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000

00000000000000000000000

Max Bytes 153 LENGTH: 145

Page 29 of 52

4.12.5 Coupon (COU):

Asset

Operation

OP_RETURN for Token Creation Txn (Asset Type: Coupon)

Field Subfield Bytes Hex Value (Example Values)

ASCII

(Example

Values) Comments

Data

Type

Metadata

(OP_RETURN

Payload)

Asset Creation Header (See Asset Definition, Asset Creation and Asset Amendment Actions)

Version 1 00 0

For data parsing/interpretation in the

event of protocol upgrades. uint8

Trading Restriction

(Jurisdiction/Group/

Region Code) 3 415553 AUS

Country Code or Custom Region Code

(eg. EU, North America, Trade

Agreement Members, etc.) string

Redeeming Entity 32

576f6f6c776f72746873000000

000000000000000000000000

00000000000000 Woolworths

Bearer of the Coupon Redemption

Liability string

Expiry Date 8 0000017655f6b400

12/12/2020

00:00:00 Coupon expiration date time

Issue Date 8 0000015195342000

12/12/2015

00:00:00 Coupon Issuance date time

Description 93

496e74276c2c20353025206f6

66620326e64204974656d000

000000000000000000000000

000000000000000000000000

000000000000000000000000

000000000000000000000000

000000000000000000000000

00000000000000000

Int'l, 50% off

2nd Item

Description of the Coupon and its

privileges. Any special clauses,

exceptions or additional requirements

can be noted here. Coupons which hold

no outright monetary value but can be

exchanged for goods/services should

have that stated here. Local vs. Int'l

redeemability notation. string

Bytes 145 Payload Output:

00415553576f6f6c776f7274687300000000000000000000000000

0000000000000000000000017655f6b4000000015195342000496

e74276c2c20353025206f666620326e64204974656d0000000000

00000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000

000000000000000000000000

Max Bytes 153 LENGTH: 145

5 System Design

5.1 Overview

The Tokenized system depends on issuers taking responsibility for creating and operating smart contracts. A smart contract is an autonomous agent that interacts with the BSV blockchain and acts on behalf of an issuer. Once the smart contract has been spun up, all instructions that an issuer is capable of making to the smart contract must be published to the BSV blockchain. The smart contract listens to the blockchain and responds to transactions that are relevant to the contract in accordance with the Tokenized protocol and the specific terms and conditions of the contract.

Tokenized is an economic system that relies on human incentives to ensure a predictable outcome, and in particular, the issuer. It is also a probabilistic system, and the security and reliability can be analyzed statistically using publicly verifiable information (e.g. p2p Bitcoin network and on-chain data). A data-informed probabilistic risk assessment of the behaviour of the token system, as well as the Bitcoin network as a whole, can be used to inform market participants as to the costs, risks and rewards. The integrity of the ledger does not have to be perfect in the sense that breaks in the chain of token transactions can happen and are acceptable. These breaks can be fixed with Reconciliation actions and can be done so, depending on

Page 30 of 52

circumstances (e.g. UTXO dependencies), without affecting downstream transactions. Ultimately, the most important thing is that users of the system are happy with their experience.

5.1.1 Control Hierarchy

The control hierarchy can best be described by the following relationships between the entities and objects/concepts. The entity/object that controls the other entity/object is denoted by the greater-than sign (e.g. the issuer is greater than the Contract, therefore the issuer controls the contract). This control structure is an abstraction that permeates throughout the Tokenized protocol and code that makes up the smart contract and is helpful for understanding the rights and duties of each entity within a legal framework.

Issuer > Contract > Asset > Token < User

5.2 Contracts

“In its essence a contract is an agreement which the law recognises as giving rise to enforceable obligations.”

-Sir Guenter Heinz Treitel, The Law of Contract

Most meaningful tokens provide value of some kind to the token owner and the issuer. This value can come in many forms, but usually involves a promise or set of promises by the issuer to provide value to the token owner at a specified time in the future. The issuer benefits from the token owner’s money used to purchase the token, and the token owner benefits from future returns such as dividends (shares), capital appreciation (securities), interest (bonds), access (tickets), goods/services (coupons) or risk mitigation (insurance) to name a few. It is important to recognize the fact that most meaningful tokens represent a legally-binding contract between two or more contracting parties, and most people - meaning the mainstream population - will expect the terms and conditions of a contract to be enforced by legal means if breached. A non-legally binding contract is far too risky for most people to take seriously enough to consider it a reliable form through which to conduct business. With this in mind, the vast majority of Tokenized tokens will be first and foremost defined by a legally-binding contract.

Page 31 of 52

A smart contract is simply a contract that uses software to facilitate, verify or enforce the negotiation or performance of some or all parts of a contract.

All Tokenized contracts will be comprised of at least two components, and usually three. The first two components will be necessary for valid and legally-binding ‘static contracts’ and the third component will be required in addition for ‘dynamic contracts’ - which shall be known simply as ‘smart contracts’. Static contracts are contracts that do not vary with time and usually are a simple agreement between contracting parties. It is enough to publish the transaction once and only use it as a reference to prove a contract’s existence and timestamp. Smart contracts are contracts that allow for variations over time. Contracting parties can change, and the terms and conditions can change. Smart contracts can benefit from the use of smart contracts to automate the bookkeeping/administrative work and enforce certain terms and conditions. The Tokenized protocol allows for both static and smart contracts, but tokens require a smart contract to be valuable in today’s market. A few examples of static contracts are as follows:

● non-disclosure agreements ● employment agreements ● bill of sale ● enterprise agreements ● trade agreements ● material transfer agreements

A few examples of contracts that can be smart contracts are as follows:

● shareholders agreement (shares/stocks) ● debenture agreements (bonds) ● derivative contracts (futures, options, swaps) ● asset-backed securities ● tickets ● carbon credits trading systems ● currency tokens (fiat tethers, gambling chips, etc.)

Static contracts generally do not require many ongoing amendments and can be entered into by contracting parties without the need for a 3rd party. Simply having a copy of the legally-binding written agreement can be enough for the terms and conditions to be enforced by a legal authority, if necessary. Smart contracts are more complex in that they generally require an entity to manage the record-keeping aspects as changes are made. An important example is where securities are traded. The challenge is in establishing who owns what at any given point in time, and in practice, various centralized databases facilitate exchanges and keep an ongoing record of the ownership. Smart contracts in the Tokenized system are managed by an autonomous agent (one per contract) and the Bitcoin ledger instead of a central database. The smart contracts perform the basic accounting/bookkeeping operations necessary for recording ownership changes and enforcing terms. The smart contract can prevent trades from happening, conduct whitelisting checks to ensure KYC/AML laws are adhered to and award/confiscate tokens based on events. The three components that are required for a valid and legally-binding Tokenized contract are a(n):

Page 32 of 52

1. Written Agreement (static and smart contracts); 2. Contract Formation Transaction (static and smart contracts); and 3. Autonomous Agent (only for smart contracts).

The first component is a written agreement. The written agreement is a legal document written in the language of the issuer’s choosing that specifies all the terms and conditions. This legal document is what gives legal meaning, specificity, and certainty to the Tokenized contract. A Tokenized written agreement will also include - where required - the investment disclosure document and any additional documentation required of any token dictated by the law that is chosen to govern the written agreement. Currently, handwritten or digital signatures are what signal intent to engage into a legally-binding contract by contracting parties. In the near term, it is expected that this convention will be followed and signatures, as well as identifying details, of all the contracting parties (where possible), will be included in the written agreement. A copy of the written agreement must be distributed to all contracting parties. A Tokenized contract also requires that a digital copy of the written agreement is passed through a hashing function, using the SHA-256 algorithm, to produce a ‘fingerprint’ of the document. The resulting hash value (32 bytes long) can be used to prove that the document has not been altered in any way. This hash value is then stored on the Bitcoin blockchain in the Contract Formation action metadata. The second component of a Tokenized contract is a Contract Formation action. A Contract Formation action is a Bitcoin transaction that is digitally signed by the contracting parties with their private keys and contains all the relevant information associated with the contract. The Contract Formation action is important because it acts as an immutable record and timestamp of the formation of the contract and it acts as a source of truth for a smart contract to determine the issuer’s intended terms and conditions. In a smart contract, the Contract Formation transaction must be preceded by a Contract Offer transaction. The Contract Offer transaction is sent by the issuer to the smart contract’s public address to initialize the smart contract and publicly announce the terms and conditions associated with the smart contract. The immutable and public nature of the Bitcoin network, in addition to the pseudonymous nature and digital signing (e.g. Elliptic-curve cryptography (ECC) or similar), presents an innovation in the world of contract law. Handwritten signatures have their limitations and can be forged quite easily - although digital signing is certainly not perfect, it vastly heightens the security relative to the handwritten alternative. The third component of a Tokenized contract is a smart contract, or autonomous agent, which is essentially a software version of the written agreement capable of recognizing and enforcing terms and conditions. In response to a Contract Offer action broadcasted by the issuer, the smart contract will publish an on-chain OP_RETURN transaction called a Contract Formation, that announces all the important details of the particular contract in addition to publicly announcing the contract’s public address. The contract’s public address is the identifier and link for of all tokens associated with the issuer for that particular contract. Double-spend attempts are managed by the smart contract using the ‘first seen’ rule and a trusted node’s receipting timestamp for all token transfer transactions. Verification of the smart contract’s performance in managing tokens in accordance with the terms and conditions of the contract are easily performed due to the public and immutable nature of the Bitcoin ledger. Users can easily monitor smart contract behaviour with watch-only versions. All response actions that the smart contract generates are also timestamped to mark when the response action was created. This helps the smart contract monitor the performance of the BSV network and rebuild its state from the blockchain. High-performance smart contracts will always be connected with a low-latency connection to a full-node that is connected to a significant portion of the BSV network’s nodes. This arrangement will allow the smart contract to take advantage of Bitcoin’s consensus rules which combined with a double-spend detection algorithm, and the sampling of mining nodes to determine transaction acceptance and distribution, allows for highly reliable 0-confirmation transactions. Relatively high-frequency trading (HFT) - meaning multiple

Page 33 of 52

transactions per minute, not multiple transactions per second - becomes feasible with the use of a high-performance smart contract. This is definitely not as fast as the trade frequencies at which modern HFT funds trade, but it will be acceptable for manual trading and even for scripted trading. The smart contract is not the limiting factor for trading frequencies, the Bitcoin network is. Dependent (parent-child) token transactions are not limited in the same way that dependent Bitcoin transactions are because the tokens are not UTXO based. However, it is likely that dependent UTXOs will often be used by wallets in chained token transactions. This is determined by the associated chain of UTXOs and transaction chain limits will equally apply to Tokenized token transactions as they will to Bitcoin transactions, at least in practice. In theory, the chained transaction limit could be worked around because the token is not tied to a UTXO, but rather an address. The difficulty lies in swapping UTXOs associated with the address out for non-dependent UTXOs to send/exchange tokens which is ultimately decided by the wallet. A much more in-depth investigation will be required to determine the robustness of the system and how ‘high-frequency’ the trading can be. Any mistakes with token ownership can be amended and errors where bitcoin ends up at the wrong address is a risk that the issuer or smart contract operator will manage, likely with insurance. The Tokenized protocol ensures that all valid contracts follow the principles and conventions of contract law. While there is some variation worldwide the basic core concepts of a contract are fairly universal. For the purposes of this paper, the Tokenized protocol has been examined using Australian contract law as the model, which is based on English common law. Further legal analysis will have to be performed to ensure that the protocol’s design is suitable to become a global standard.

5.2.1 Contract Formation

“There are five essential elements necessary for legally binding Contract Formation: 1. Agreement between the parties;

2. Consideration (a bargain requirement: generally, the supply of money, property or services or a promise to undertake, or not undertake a particular act in exchange for something of value);

3. Capacity to enter legal relations (e.g. of sound mind and legal age); 4. Intention by the parties to enter into legal relations (private non-commercial agreements between

family members may not indicate intention to enter a legally binding contract and therefore may not be enforceable); and

5. Certainty (the contract has to complete, certain, clear and binding).” 9

All of these elements are exemplified in Section 4.9.2.1 using the flow diagram for a security token offering.

5.2.1.1 Agreement The agreement criteria of contract law is satisfied in the Tokenized protocol by way of the information specified by the Contract Formation action, the Asset Creation action, the written agreement, and one of the Exchange or Swap actions. The existence of an agreement is analyzed through the rules of ‘offer and acceptance’. In the case of a token contract, the issuer (the offerer) produces an offer (Contract Formation, Asset Creation) and the investor (the offeree) accepts the offer by way of an Exchange or Swap action. The Send action is like a Bitcoin transaction in that it only requires sign-off by the Token Sender, and no consideration is required, therefore the offeree does not sign-off on the transaction and may not agree to accept the tokens being sent in the Send action. Therefore, a legally-binding agreement can only be achieved with an Exchange or Swap action.

9 J W Carter, LexisNexis, Carter on Contract (at July 2013) [Chapter 1] Page 34 of 52

5.2.1.2 Consideration Consideration will always be present in an Exchange or Swap action in the form of either a token or bitcoin. Exchange actions require a contracting party to provide bitcoin in return for their token(s). Swap actions have contracting parties swap tokens for other tokens directly without any bitcoin except for what is needed to pay any transaction fees. The consideration criteria of a legally-binding contract will also be published on-chain in a Settlement transaction where the contract actually dispenses the bitcoin and token(s) to the contracting parties involved in the transfer.

5.2.1.3 Capacity Capacity will be handled by the smart contracts and the use of registers that contain whitelisted public addresses. These whitelisted addresses get added to the whitelist only when KYC/AML compliance checks have been completed. The smart contract will not allow any transactions to go through that break the terms and conditions of the contract which are created in accordance with the choice of law selected for the contract. Other capacity issues relating to being ‘of sound mind’ (e.g. intoxication) cannot be effectively managed by the Tokenized protocol, but that may be true of any online commercial interaction.

5.2.1.4 Intention Intention is traditionally handled by context, language and a signature by all relevant contracting parties. For most token use cases the context will be supplied by the actual written agreement, and the descriptions and labels of the token. Generally, a contracting party who is looking to buy a share in a company recognizes that the share is part of a commercial-agreement. The Tokenized protocol also uses carefully chosen terminology for the various actions and metadata fields to make the intention of the actions extremely clear to all that use it. The language is precise and adheres to the concept of terms having their ordinary meaning to remove the potential for misunderstanding. Most tokens will be accompanied by a written agreement and/or supporting documentation that will have handwritten signatures of the issuer and any relevant contracting parties. However, most token owners will signal their intent to be bound to a legally-binding contract using a digital signature generated by their private key that is associated with the public key that holds the tokens. The Tokenized protocol recognizes the digital signatures of the contracting parties - in the input addresses of the Bitcoin transaction that contains the Tokenized action - as intent by the contracting parties.

5.2.1.5 Certainty Certainty is captured in the formalized and standardized metadata of the Tokenized actions. All of the important aspects of the contract are detailed and must be included for it to be considered a valid Tokenized action. The Tokenized protocol does not have control over the actual written agreement and there can be some uncertainty as to whether the written agreement is legally binding in this capacity, but this may be true of all contracts. Users will have to be vigilant with the contracts they enter into and should always seek professional legal advice if they are uncertain of a contract’s effect.

5.3 Assets Assets can be anything of value. This can be a physical object, a security, or right to attend an event. The Tokenized protocol has allowed for the creation of tokens representing tangible and intangible assets by way of the Asset operations. There are three Asset operations: Asset Definition, Asset Creation and Asset Modification. As the names imply, these operations allow for defining the characteristics of an asset, creating a token to represent the asset, and modifying the asset details. Assets are represented by an Asset Code, which is a human-readable identifier made of a 32-byte randomly generated base58 string - called the AssetID - prepended by a 3-byte string - called the Asset Type - e.g. Asset Code: SHCapm2qsznhks23z8d83u41s8019hyri3i, where ‘SHC’ (capitalized by convention to stand out from the other characters) is the Asset Type standing for a ‘Share - Common’.

Page 35 of 52

The Asset Type is a standard English alphabet string listed on the Asset Type register and hard coded into the smart contract. All tokens must be one of the Asset Types on the Asset Type register which is managed as part of the Tokenized protocol. If new Asset Types are required by the community then they can be added to the protocol using pull requests on the Tokenized protocol repository.

5.4 Token A token is a digital representation of an asset defined by the contract and managed by the smart contract. A contract may have just one single token to represent one or more assets, or it may break individual assets down into multiple tokens. The token is the smallest tradeable unit in the contract and as such can only be traded in full. A token can also be thought of as a record of ownership, or the rights and duties associated with a party to a contract. A non-fungible token would be an asset represented by one token. A fungible token is a single asset represented by two or more tokens. A token is always stored at a public address, not a UTXO. The only way a token can be transferred to another public address is by a request action followed by a confirmation action by the smart contract.

5.5 Issuers issuers are entities that create, issue and manage tokens. In order to create a token they must first define the terms and conditions of the contract which gives legal structure to the token. The contract will also define how the token will be governed in addition to the rights and duties of the issuer and the rights and duties of the token owners. The issuer must also define what the token is meant to represent (Asset Definition action). This is usually an asset of some type, but it doesn’t have to be. An issuer is defined as the owner of the public address that was in Index 1 of the input of the transaction that had the first Contract Offer action. No other issuer initiated action for a particular contract address, will be valid other than ones initiated by the issuer address.

Tokens are generally a liability to the issuer and an asset to the token owner. In many cases the issuer is also the party upon whom the total value of the token system is placed, given that they will be responsible for the value provided to users through the holding or Redemption of the issued tokens. They also manage the trading of tokens and are accountable for the management of the smart contract.

5.6 Users Users refers to token owners and prospective/former token owners. They are the people that find value in the tokens offered by issuers. They are subject to the terms and conditions of the particular contracts that relate to the tokens they own. In this way, owning a token makes the token owner – user – a party to the associated contract. Depending on the terms and conditions of the contract, users have the ability to buy and sell tokens, cast a ballot on a contract vote, revoke their tokens, create an initiative, and send messages to any public address. An issuer can also be a user.

5.7 Smart Contract Operator The smart contract operator is a proposed market participant that specializes in the provision of technical services relating to smart contract design, implementation, and operation, as well as services relating to the issuance, management, and exchange of tokens on behalf of the issuer. The smart contract operator can be thought of as a technical risk manager offering companies, organizations and individuals the ability to outsource all of their blockchain related interactions. Analogies can be drawn from the likes of Coinbase with regards to the management and custody of users’ cryptocurrencies and email service providers like Gmail and Hotmail.

Page 36 of 52

5.8 Issuer Platform The issuer platform facilitates the creation and management of smart contracts and all of the associated tokens. The platform is designed to have a user experience that provides the issuer with utility for token-related activities (minting/burning/amendments). For the creation and issuance of most security tokens, there will be a legal framework within which they must operate and while the platform provides functionality necessary to issue and manage tokens, the onus is on issuers to ensure that they meet the legal obligations required to create the token.

5.9 Issuer Wallet The issuer wallet provides an interface to the token system through a modified SPV wallet. Wallets will use plugins to connect to and interface with the issuer platform enabling the smart contract to be hosted in a physically remote location from where the issuer is managing the contract. The plugin will provide the issuer with a simple and intuitive interface to all of the tools needed to create, issue, manage and exchange tokens.

5.10 User Wallet For token owners, wallets can be simple in their design. The goal of Tokenized is to implement a set of wallet APIs that can be used to create simple plugins for SPV wallets such that any token owner can manage their tokens from the same wallet that they use to spend their cash.

For this to happen, SPV wallets will need to be modified to find Tokenized transactions, then interpret and display the metadata located in the OP_RETURN payloads. They must then be able to create and interpret transactions relevant to the basic operations of the Tokenized protocol. The simplicity of the protocol makes it straightforward for SPV wallets to become full token management platforms with all the necessary tools to receive, view and transfer tokens in-line with the rules stipulated in the contract genesis transaction. To participate in a contract, SPV wallets can simply add a watch-only public address for each contract in which it is engaged in. This can be done automatically by software upon the receipt of the wallet’s first token. For example, if a particular wallet has 100,000 tokens that are spread across 10 different contracts, then the wallet will have to monitor 10 watch-only public addresses in addition to the wallet’s main xpub key. Token addresses contain transactions which record the full history of that wallet’s interaction with the token issuer. The load on the SPV wallet can be reduced by filtering out transactions that aren’t addressed to them. They can also filter by ‘contract-wide’ transactions which have the contract’s public address as an input and output both in Index 0. All other transactions addressed to the contract can be ignored.

5.11 Registry A distributed and general-purpose registry that can be used for whitelists (including optional sublists), can be created by implementing a basic OP_RETURN protocol convention whereby organizations that have specific filtering criteria (e.g. KYC compliance, trade group, membership) can publicly broadcast users’ public addresses that corresponds to their privately stored whitelist. This will allow organizations to share private whitelists with each other and ultimately expand the pool of users that they can do business with, without having to share specific customer information with each other. Organizations (e.g. issuers) can then decide which entities’ whitelists are relevant to them based on their own criteria such as reputation, jurisdiction, and business processes, and can create their own whitelists that are a subset of the global whitelist filtered by public addresses that sent the transaction that contained the whitelist action. The distributed whitelist provides the tools and flexibility to allow for compliance in various jurisdictions. This is a completely optional feature and is opt-in, and issuers have complete control over the choice of using a whitelist or not.

Page 37 of 52

Users can engage with different market actors, e.g. exchanges, by signing a message to prove they own the private keys to a public key that is on the whitelist. They can then submit a different public key for the exchange transactions to protect their identity. The exchange will only know that the customer has been identified with KYC processes by another reputable company and which new public key is associated with the whitelisted public key. The rest of the market will be unaware and uninformed about these connections. Therefore, the user can remain pseudonymous except to the company that inducted them into their KYC database.

5.12 Messaging

The users and issuers can communicate on-chain through the Messaging operations. The Messaging operations will also allow for users to make direct offers to each other and for them to pass around partially-signed transactions (once the OP_RETURN payload restriction is raised) in a permissionless manner. The standard Message action has a sub-field called Message Types that is used to filter out different types of messages such as Invoices, Purchase Orders, Offers, Advance Shipping Notices, etc. The Message action can also be used to add receipts/notes to transactions and can be used in combination with the Diffie-Hellman (DH) key exchange algorithm, to establish secure trading relationships, where the receipting/invoicing/purchase order messaging information is encrypted and only visible to the two trading partners. This could be analogous to ‘setting up an account’ with another company for business to business trading relationships. The Message Type payloads, still being defined, can be found here: https://github.com/tokenized/specification/tree/master/messages/develop

5.12.1 Message Type Register

Message Type Code Comments

Communication Rules 0

The owner of the address declares the rules (message sent back to itself) by which

they are willing to accept messages. Certain types of messages can be excluded, and

most importantly the minimum threshold value that must be sent in order to avoid

being considered spam. Different threshold amounts can be applied to different types

of messages. The Public Key (RSA) can also be declared here.

Commercial Profile 1

Business Name, Registration Number, Address, Communication Details

(Phone/Email/etc.), Key People

Public Message (Generic) 2

Public message, public announcement. Sent to another PKH or back to the same PKH.

Can be used for an official issuer announcement.

Establish Private

Messaging (DH) YA (1 of 2) 3

YA is sent to a PKH that the sender is looking to establish a secure line of

communication with. Useful for establishing a secure communication channel for a

business-to-business relationship such as a supplier-customer relationship. YA is the

first key that is passed to create a Diffie-Hellman shared secret between two parties.

Establish Private

Messaging (DH) YB (2 of 2) 4

YB is Contract Offered in response to a YA message. Both parties can now create

encrypted messages that they can both read. Useful for establishing a secure

communication channel for a business-to-business relationship such as a

supplier-customer relationship. YB is the second key that is calculated from YB and

the user's PK to create a Diffie-Hellman shared secret between two parties.

Public Key 5

RSA public key or the like. This message is sent back to one's self to publicly broadcast

the public encryption key associated with the PKH. This allows for permissionless and

anonymous 1-way communication with the owner of the public key.

Page 38 of 52

Private Message (Generic) 6 Generic private message. DH, RSA, etc.

Trading Address (PKH) 7 The sender sends the PKH that they want to receive all of the messages/payments to.

Offer 8

A message that is meant to signal intent or specify an offer to another party (PKH).

The offer can be for a token, or for a static contract. An offer is effectively a message

with no signatures on it, and may have non-standardized communication. "I'd like to

offer you 1000 BSV for your shares in Apple." It can be the start of a negotiation.

Likely done in a private manner after establishing a secure (DH) communication

channel.

Signature Request 9

A partially signed transaction or a Payment Request. Useful for sending transactions

that require multiple signatures from different contracting parties such as in the case

of bitcoin multisig txns and exchange (token) actions. Also useful for static contract

formation. The Payment Request can be sent along with an Invoice. The Invoicee can

use the Payment Request to actually make the payment.

Receipt/Output Note 10

Either sent back to yourself, or accompanying a txn. Often encrypted (DH, RSA) to

make a note/receipt against a particular output. DH for b2b where both parties can

see the receipt/note. RSA or the like for receipts only visible to one of the transacting

parties.

Quote 11 A quote. Can be used to generate a Purchase Order.

Purchase Order 12

Sent by the customer to the supplier. Often generated in response to a quote. Can be

securitized with a Payable token. (Factoring/Reverse-Factoring)

Purchase Order

Acknowledgment 13

An official acknowledgement of a purchase order. May include information such as

ETA or material shortfalls.

Advance Ship Notice 14

Also known as a packing slip. Sent to customers as an advance notice of what has

been shipped.

Invoice 15 An invoice. Invoices can be securitized by creating a receivable token.

Product Catalog 16 An official list of products offered by a supplier. Can include pricing as well.

Planning

Schedule/Material Release 17

A forecast notification from the manufacturer to the relevant supplier of the qty of

materials needed and the time period in which they are needed.

Shipping Schedule 18

An authorization from the manufacturer to the supplier to ship goods according to a

specific short-term schedule. It provides detailed shipping requirements and adds

more specific instruction to the Planning Schedule/Material Release that may have

been provided earlier.

5.13 System Analysis 5.13.1 Impact on the UTXO Set The effect on the UTXO set can be analyzed with a rough projection based on some conservative assumptions that are informed by reference to a few real world data points. This analysis is based on the fact that there is a dust threshold limit (currently set at 546 sats), and amounts at/near that limit are used to signify roles that certain Bitcoin addresses play in the Tokenized protocol. Tokens are not associated with UTXOs, they are associated with public addresses. Therefore, there is no requirement to have near-dust UTXOs persist as near-dust UTXOs. They can be consolidated without affecting the token system.

The importance of this analysis is to identify where the UTXO set is expanded for purposes that are not related to a standard payment use case. The Tokenized system’s design effectively means that for a single token trade, two near dust level UTXO’s are created for purposes that are not directly tied to the transfer of Bitcoin from one user to another. However, the actual effect on the size of the UTXO set is dependent on users’ behaviour. Predicting whether users, on the whole, will consolidate their UTXOs is difficult. This analysis was performed with the absolute worst case scenario in mind and assumes that 100% of the near-dust UTXOs

Page 39 of 52

created by Tokenized token actions will remain as near-dust UTXOs. This is almost certainly not going to happen, but it is worth looking at the effect on the UTXO set.

Share trading can be used as the use case for the analysis because the value proposition presented by security tokens (trading costs, listing/issuing costs), in comparison to what is currently available on the market, appears to be significantly more compelling than other token use cases. It is therefore likely that shares will become the first large volume use case of tokens on the BSV network. This is just an assumption, but it is a reasonable place to start.

Public Stock Exchange - Yearly Trade Volume 10

Stock Exchange

Market

Capitalization (USD)

- End 2017 Volume/Year Shares/Year Txns/Year

New York Stock Exchange, United

States $22,081,367,000,000 $16,140,057,820,000 356,130,172,000 2,072,198,718

NASDAQ, United States $10,039,335,600,000 $33,407,130,000,000 259,235,049,378 3,493,547,791

TMX Group, Canada $2,367,131,600,000 $1,244,261,111,454 149,714,000,0000 255,750,400

Hong Kong Stock Exchange, Hong

Kong (SAR China) $4,350,500,690,666 $2,079,312,094,175 3,703,029,869,867 213,924,368

Japan Exchange Group, Japan $6,222,834,714,440 $6,612,106,608,910 655,011,460,000 873,202,420

Shanghai Stock Exchange, China $5,084,357,755,451 $7,589,309,294,821 4,482,753,120,000 2,382,995,092

Shenzhen Stock Exchange, China $3,617,883,452,783 $9,219,729,719,186 5,008,901,100,000 3,623,916,720

Deutsche Borse AG, Germany $2,262,233,411,925 $1,553,007,100,741 41,495,864,525 138,516,739

Euronext, United Kingdom,

Belgium, Portugal, France, and

the Netherlands $4,393,016,140,008 $2,854,893,827,227 81,641,322,606 223,392,800

London Stock Exchange Group,

United Kingdom and Italy $8,181,000,000,000 $1,807,609,999,500 258,709,296

Total $68,599,660,365,273 $82,507,417,576,014 14,737,911,958,377 13,536,154,344

Assumptions: 1. In the first year, Tokenized token trades will be 0.1% of trade volume (13,536,154,344 trades/yr) seen

on the major global stock exchanges listed in the table above. 2. The trade volume on the major global stock exchanges grows at 1% per year as a comparison figure.

It is assumed that most token trading activity will be represented by newly created securities. 3. Token trades on the BSV network grow in volume by 200% year-over-year, each year. 4. Each UTXO is effectively 50 bytes in size. UTXO = tx hash (32 bytes) + index (4 byte) + amount (8 bytes)

= 44 bytes. 6 extra bytes has been allowed for the real world storage footprint/calculation buffer. 5. Send/Exchange and the corresponding Settlement actions will be the majority of token transaction

types recorded on-chain. 100% is assumed for this analysis. 6. Each token trade involves the creation of two additional dust-level UTXOs that have a lower

probability of being consolidated over time as they are UTXOs owned by users. It is assumed that 100% of these UTXOs remain as near-dust level UTXOs. These UTXOs are highlighted in yellow in the transaction summary tables below. This is the worst case scenario that assumes no consolidation by users. Tokens are not associated with UTXOs, so they can be spent without affecting the token

10 https://www.londonstockexchange.com/statistics/historic/secondary-markets/secondary-markets-archive-2017/secondary-market-factsheet-december-2017.pdf http://w.world-exchanges.org/home/index.php/files/52/Annual-Statistics-Guide/504/WFE-Annual-Statistics-Guide-2017.xlsx

Page 40 of 52

system. It is highly unlikely that most of these UTXOs will never been consolidated, at least across the ecosystem, but it does depend on users’ behaviour.

7. Transaction fees captured by the smart contract operator do not meaningfully expand the UTXO set as a consolidation of their UTXOs will take place regularly.

8. Where an address sends an amount fully back to itself, no UTXO is created. This is a conservative assumption and it may actually reduce the number of UTXOs.

9. The smart contract will generally spend the entire amount received (cash flow neutral) in the request action when it broadcasts a confirmation action. Therefore, the number of UTXOs owned by the smart contract will remain stable with time. However, near-dust amounts are used to identify participants in response actions and these near-dust amounts will accumulate. Regular consolidation at the contract address will be necessary to minimize the impact of the UTXO set. Furthermore, if a smart contract were to perform an action (e.g. message to itself) that draws upon its reserves, it will always consolidate the UTXOs as it will send the full amount of stored BSV associated with that address back to itself as change. Therefore, with regular consolidation, the token trade UTXO lifecycle of Bitcoin sent to contract addresses do not result in an expansion of the UTXO set. The amount of Bitcoin required in network fees, near-dust pointing and transaction fees is always slightly overcharged in the Send/Exchange/Swap actions and the smart contract dispenses the full amount in the Settlement action. Therefore each Transfer operation does not increase the UTXOs at the contract’s address.

10. Change amounts sent back to the sender’s address does not increase the size of the UTXOs. 11. It is assumed that the Bitcoin sending addresses (Index 0 on the inputs for the Send Txn Summary and

Index 1 on the Exchange Txn Summary) are sent from one UTXO. This is a conservative assumption.

Send Txn Summary:

Index

(Input) Txn Inputs Value

(sats) Comment

s Index

(Output) Txn Outputs Value

(sats) Comments

0

Token

Sender's

Public Address

(Contracting

Party 1) 15,112 0 Contract Public Address 1,100

Enough for the costs of the

responding action + the

Contract Fee

1 1 Token Receiver's Public

Address 546 Dust limit rule minimum

value output of 546

2 2 Token Sender's Public

Address 12,916 Change

3 3 OP_RETURN (Send

Action) 0

3 4 Miner's Fee 550 ~550-1000 Bytes to account

for return data and txn data.

Exchange Txn Summary

Index

(Input) Txn Inputs Value (sats)

Com

ment

s Index

(Output) Txn Outputs Value

(sats) Comments

Page 41 of 52

0

Contracting

Party 1 (Token

Sending

Address) X 0 Contract Public

Address 700,002,0

00

The Token Receiver (buyer)

pays the Contract the money

to hold in 'momentary

escrow' (including fees). The

Contract will transfer the

money to the Token Sender

in a Transfer Txn if the

Exchange Txn is acceptable.

If the Txn is not acceptable

then the SC will send the

money back to the Token

Receiver less miner's fees

using a Rejection Action.

1

Contracting

Party 2 (Token

Receiving

Address) 700,072,550 1 Contracting Party 1

(Token Sender) X

Contracting Party 1 simply

sends any amount back to

himself. No additional UTXO

is created for typical

Exchange txns.

2 2 Contracting Party 2

(Token Receiver) 70,000 Change

3 3 OP_RETURN

(Exchange Action) 0

4 Miner's Fee 550 ~550-1000 Bytes to account

for return data and txn data.

Settlement Txn Summary: Token Sender and Token Receiver

Index

(Input) Txn Inputs

(1st txn) Value

(sats) Comments Index

(Output) Txn Outputs Value

(sats) Comments

0

Contract

Public

Address 700,07

2,550

Sample

number.

Contract 1 in

response to a

Swap action. 0

Token Sender's

Public Address

(Contracting Party 1) 700,067,

458 Token Sender (or seller) is

paid 7 BSV (in this example).

1

Contract

Public

Address

(Contracting

Party 2's

Token) 546

Only used in

response to

Swap actions

only. 1

Token Receiver's

Public Address

(Contracting Party 2) X

Change for response to

Exchange/Swap. For

response to Sends, it should

be a nominal amount of 546

sats.

2 2 Contract 1 Public

Address 546 Dust limit rule minimum

value output of 546

3 3 Contract 2 Public

Address (Swap Only) 546

Response to Swaps only.

Dust limit rule minimum

value output of 546

4 4 Contract Fee

Address (Optional) 2,000 Contract Operator's Fee

(Optional) Page 42 of 52

5 5 Contract Fee

Address (Optional) 2,000 Contract Operator's Fee

(Optional)

6 6 Exchange Fee

Address (Optional) 2,000 Exchange Fee (Optional)

7 7 OP_RETURN

(Settlement Action) 0

Token Sender and Receiver's

token balances are adjusted

up/down by X tokens in

accordance with the

Send/Exchange/Swap txn.

8 Miner's Fee 550 ~550-1000 Bytes to account

for return data and txn data.

Non-Payment Related UTXO Growth Projection (Worst Case)

Item Year (2019) Year (2020) Year (2021) Year (2022) Year (2023) Year (2024)

Global Stock Exchanges

(Trades/Year) 13,536,154,344 13,671,515,887 13,808,231,046 13,946,313,357 14,085,776,490 14,226,634,255

Tokens (Trades/Year) 13,536,154 27,072,309 54,144,617 108,289,235 216,578,470 433,156,939

Token Volume Growth (% YoY) 200.00% 200.00% 200.00% 200.00% 200.00%

% of Global Stock Exchanges

(Trades/Year) 0.10% 0.20% 0.39% 0.78% 1.54% 3.04%

Tokens (Trades/Day) 37,085 74,171 148,341 296,683 593,366 1,186,731

Tokens (Txns/Year) 27,072,309 54,144,617 108,289,235 216,578,470 433,156,939 866,313,878

Tokens (Txns/Day) 74,171 148,341 296,683 593,366 1,186,731 2,373,463

UTXO Growth (Bytes) 1,353,615,434 2,707,230,869 5,414,461,738 10,828,923,475 21,657,846,950 43,315,693,901

UTXO Growth (GB) 1.35 2.71 5.41 10.83 21.66 43.32

5.13.2 Minimization of Near-Dust UTXOs (Optional Proposal) The risk of Tokenized specific - near-dust/non-payment related - UTXO set growth can be significantly minimized, if not completely eliminated, with the introduction of a new consensus rule whereby addresses that have 0 satoshis in both the input and output of Bitcoin transactions are considered to be valid transactions. This would mean, that during validation of a Tokenized transaction, nodes would verify the signatures (scriptSig) of addresses that have a 0 amount against them, but will not need to verify, nor update the UTXO set. For this to work, the ‘vin’ would still include a valid scriptSig (signed message and a public key), but the ‘txid’, ‘vout’ and ‘sequence’ would be effectively null values. For ‘vout’ the value would be 0, and the scriptPubkey would simply have to have the public address required by the particular token transaction (token receiving address in a Send action for example). Because a 0-value output has no Bitcoin to spend, the locking script is unimportant, since it will never actually be unlocked. To save on transaction space, the scriptPubkey can be minimal and would not require many of the standard OP_CODES (e.g. OP_EQUALVERIFY and OP_CHECKSIG).

This rule can be included without needing to change the dust threshold limit - by permitting bitcoin values of 0 and greater than 546 satoshis (current rule). Non-paying/receiving addresses are then provably unspendable and can be pruned by uninterested nodes. This proposal can also work quite well by only changing the rule to allow for 0-value outputs thus leaving the input side alone. However there are use cases where signatures on transactions without contributing bitcoin could be desirable for static contracts and even for having ‘witnesses’ sign-off on regular Bitcoin transactions without unnecessarily sending BSV back to themselves which adds unnecessary data to txns.

Page 43 of 52

5.13.3 Transaction Ordering Tokens are associated with public addresses, not UTXOs. The smart contract operates on the first-seen rule and each request-response pair is connected in sequence by the UTXOs that thread through the two transactions. However, unlike the Bitcoin network, the smart contract's first-seen ordering (natural order) will take priority over the actual order of transactions within a block. As long as the transactions are included in a block, the time that the transaction was received by the trusted full node is what determines the order of token transactions for the particular smart contract. Smart contracts will always be connected to a trusted full node that interfaces with the network. The full node's database of transactions, along with timestamp data, will act as a source of truth for that smart contract. When a smart contract re-syncs, it will request txn data from the full node that it is connected to and use the timestamp data provided by that full node to catch back up and broadcast the necessary confirmation actions (Settlement/Rejection/etc). All confirmation actions use the UTXOs from the request action to pay mining, and transaction fees, as well as any other Bitcoin payments required by the confirmation action in accordance with the instructions of the request action. All confirmation actions will also include a TX-ID from the request transaction that it is responding to, therefore all confirmation transactions are linked to the request actions. Any orderings (or reorderings) of the transactions within a block will not affect the token transactions unless transactions are dropped. All responding actions will include a timestamp subfield in the on-chain metadata to help the smart contract with the sequence of events if it needs to rebuild its state. The on-chain timestamps in the response actions are also useful for user/issuer feedback to determine the performance and integrity of the smart contract and the BSV network. 5.13.4 0-Confirmation Reliability The Tokenized system can operate on the basis of 0-confirmation. However, it is important to note that Tokenized is a probabilistic system and it is also an economic system. Risks are managed by users, issuers and exchanges using statistics and cost-versus-reward calculations. The key question is whether previous token actions can be relied upon to make subsequent chained transactions, and how quickly can these subsequent transactions be made. Otherwise, the risk that merchants/users face when transferring tokens using 0-conf are the same as the risks of transferring bitcoin. The risk of a valid request transaction that has been validated and added to the mempool of most nodes in the network, but then dropped by the network completely is extremely low. However, if this were to occur, then all of the subsequent transactions that utilize the UTXOs (and tokens) from the request transaction would be invalid and would also not be included in a block, which is important because it means the dependent response action would also be invalid. There is no chance of a response action being confirmed without the preceding request action also being confirmed prior. If a double-spend attempt is successful then the same logic applies in that the responding confirmation action will become invalid as the input UTXO(s) are no longer valid. The biggest challenge lies in chained token transactions where a link in the chain is dropped and different UTXOs are used for each of the subsequent Transfer operations. Since the tokens are associated with public addresses, it is possible for a break in the link to result in an incorrect balance at one or more public addresses. This is handled by risk management techniques by users (wallets), smart contract operators and exchanges/businesses. It is also worth noting that most token use cases do not require high-frequency chained transactions. For day trading of security tokens, where this is most desirable, configurable options in the smart contract (on the road map) such as a Safe Mode (wait N confirmations before a response action is published) and transaction value

Page 44 of 52

thresholds (resort to Safe Mode for high-value transaction values above a certain threshold) can be employed to manage the risk of loss for users and the associated exchanges. These risks will be managed with data-informed models, locking scripts and various algorithms. Mistakes can be corrected manually with Enforcement operations and can be supported by insurance. If a request action is confirmed, but the smart contract’s confirmation action is dropped from the network, then the smart contract can automatically rectify the situation at a later time, either with a state rebuild algorithm, or manually by the smart contract operator. From a smart contract operator’s perspective, it will be trivial to monitor the balance of BSV at all of the contract addresses. Over time, the net income should be fairly stable. If an unusual positive balance of BSV is observed at a contract address for more than ~X confirmations then that could trigger an alert for a Contract Operator to investigate, and correct manually with an Enforcement operation, if required. 5.13.5 Double-Spend Detection A UTXO double-spend detection algorithm is used by the smart contract to reduce the likelihood that the first-seen transaction by the trusted node will not actually be included in a block. Where a double-spend is detected (sampling other nodes for ~0-3 seconds), the smart contract will respond with a Rejection action. The main issue with a double-spend only applies to request transactions that are used to pay for real world goods and for chained token transactions that are vulnerable to block reorganizations or links in the chain being dropped which will affect the token balances. For example, if a user wanted to redeem a coupon-type token in a store and the user attempted to double-spend the UTXOs associated with the token Send action, then the smart contract would respond with a Rejection action to signal to the merchant and user that the token Transfer operation was not successful. Ideally, the token receiving wallet would also have double-spend detection which can inform them of the potential for the token payment not to go through, but regardless, the Rejection action will be enough for the merchant to know not to hand over the goods or service. Token double-spends - as opposed to UTXO double-spends - are not a significant problem because each smart contract maintains its own record of ownership for token balances against public addresses (UTXO set equivalent for tokens on a particular contract). Distributed consensus is not a factor for each smart contract. Token transfer actions are processed and responded to on a first-seen basis and processed according to the rules of the contract. As long as UTXO double-spend risks are managed, and the contract employs high standards for what transactions are likely to be included in the next block, then token double-spends should be very, very rare. In the unlikely event that a glitch, or bug results in an error causing a token double-spend then the smart contract operator can fix the issue on a case by case basis using the Reconciliation action. If the smart contract accidently sends Bitcoin to the wrong address, then this will be handled by the issuer/smart contract operator as part of their business operations. 5.13.6 Chain Splits Smart contracts do not need to do anything special for chain splits. A smart contract is simply a specialized and autonomous wallet. The smart contract is dependent upon a node to pass transactions both to and from the BSV network. Smart contracts will always have a trusted node(s) that they connect to. The standard procedure that any node goes through to deal with a chain split is all that is needed. The smart contract simply needs to continue to connect to the node to continue to operate correctly. If the issuer or smart contract operator disagrees with the trusted node's choice of chain, then they can connect to a different full node that is operating on the chain that they support. It will probably be wise to pause (take offline) the smart contract during the switchover and have it catch back up with a 'catch back up' algorithm. Mistakes can be corrected and token ownership can be adjusted with the Enforcement operations.

Page 45 of 52

The biggest challenge will likely be the public communication aspect that the issuer/smart contract operator must do to announce the chain that they will support/run on to all of the token owners/prospective owners/customers.

5.13.7 Chain Reorganizations Most chain reorganizations will likely not cause any issues for smart contracts. An orphaned block(s) will still likely contain all of the same transactions that were broadcasted to the network and in roughly the same order as the blocks that make it into the blockchain. Slight differences that may appear with some transactions that are missing or included due to different fee acceptance policies by miners, or network communication errors, are inconsequential for the most part, as the smart contract operates on the first-seen principle, and all responding transactions are dependent on the request transaction being valid because the UTXOs thread through both. It is also worth noting that smart contracts can use fee policies that require higher Mining Fees than what is generally accepted by most nodes to reduce the risk of valid token transactions not being included in a block due to a low fee. That is, as long as a transaction is included in a block, then the timestamp of when the node first received the transaction, is all that matters with respect to the token transaction ordering. As long as the first-seen rule is a Bitcoin consensus rule and respected by the network, then the first-seen rule used by the smart contract will work. The main risk a chain reorganization presents is the possibility of breaking a link in the chain of token transactions. This is because dependent token transactions do not necessarily have dependent UTXOs threading through them all. It is possible to transfer tokens with different UTXOs then which are linked to the transaction where the tokens were received. If any links in the token chain are lost, then the potential exists for the total outstanding tokens to change and for the integrity of the tokens ledger to be broken. However, any mistakes can be manually corrected by the smart contract operator using the Reconciliation action to restore the state of a particular contract by ‘fixing’ the missing link. Disputes with respect to the time stamp/token transaction ordering enforced by the smart contract can be validated against other nodes' timestamps to show that the transaction was received within a second or so of all the other nodes. While this is not on-chain definitive proof, it will be more than good enough to keep the market assured. Smart contracts can also sample the network to measure the likelihood that a transaction will be accepted before responding to request actions. Each response action that the smart contract creates is timestamped to allow the smart contract easy state rebuilds, even if the blockchain is in a different order than what was seen by the smart contract in the first place. For malicious chain reorganizations done by miners with significant control of the network, serious problems can occur with the token trade history to the point where it becomes impractical to fix manually. This type of event is likely to be a catastrophic event for the smart contracts seriously affected by the reorganization. However, a malicious reorganization would undermine the value proposition of the BSV network and would likely spell disaster for the network as a whole.

5.13.8 Technical Risks The most prominent technical risk to the Tokenized system is the risk of sending Bitcoin to the wrong address. This risk can be broadly broken down into two categories of error: user error and smart contract error. For user error, if the user enters in the wrong public address, then that bitcoin will be lost and the chances of getting it back are very low. The Tokenized system does not introduce any additional risks with respect to user errors in comparison to a regular Bitcoin transaction. The user error can be because of many reasons, including typos, bugs in the software of the wallet/exchange they are using, typos on exchanges or where the

Page 46 of 52

issuer has publicly identified their contract address. These risks are all managed outside of the Tokenized system and are beyond the scope of this paper. Another risk to the system is the vulnerability of smart contracts to hijacking by a bad actor. If a black hat hacker is able to penetrate the security of the server that is hosting the smart contract and get control of the smart contract then bitcoin and/or tokens can be stolen by manipulating the request/response transaction structure and bypassing validation algorithms. A way to mitigate the risk is for smart contracts to be spread across multiple servers and use 2 of 3 multisig or threshold signatures (split-key) to sign all responding messages.

6 Use Case Methods

6.1 Single Usage Tokens: Tokens that require the user to spend, redeem or trade their tokens away to access the underlying value that the token represents must utilize the Transfer operations to move the token from one public address to another. In the case of a concert ticket, the user scans a payment request made by the ticket collector, and sends the token to the ticket collectors’ (issuer) address. Most Utility Tokens that are redeemed will operate on this basis, however, the Confiscation action can be used such that the ticket collector pays for the bitcoin Mining Fees associated with the Redemption. Security tokens will generally be traded with Exchange or Swap actions and this can be done by passing partially-signed transactions around to each contracting party and then having the last contracting party broadcast the transaction.

6.2 Repeated Usage Tokens: The way the Tokenized system handles 'access/privilege/admission' tokens, which effectively provide the owner with unlimited usage/access rights during a specified period (e.g. railway season ticket, club membership, driver's license, passport, travel visa, Identity Tokens, etc.), is by simply having the token owner prove ownership of the public address that owns the token using a digital signature (ECDSA signed message). In this way, the token owner always maintains ownership of the token, and no Transfer operations (Action Prefix Codes: T1-T4) are required to access the token's rights, except for the initial transfer from the issuer to the owner during the purchase of the token. In other words, repeated usage tokens only need the token owners to prove that they own the token. Redemption is not necessary. The Asset Type can be the same as a ticket that gets redeemed (Admission Ticket (TIC)), however, the 'Valid From' to 'Expiry' period would likely be much longer on a season ticket than a concert ticket which would likely only have a period range of a few hours to a few days.

In the railway season ticket example, a train ticket 'collector' may ask the ticket holder to 'show their ticket' by providing a randomly generated string (similar to the approach taken with services that use the Time-based One-Time Password algorithm used in 2FA) to the token owner, who will use their private key to sign the string. The ticket owner can then show the ticket collector the signed message (the string could also be a signed message from the ticket collector with a public address associated with their employee ID or something similar) and their public address by way of a QR code/NFC/RFID/Bluetooth. The ticket collector could then verify that the public address owns a valid railway ticket token and that the right message (string) was signed correctly by the owner of the public address. The ticket collector can then save this signed message to their own off-chain database for record keeping, or they could save it to the blockchain by sending a message action (M1) to the public address their company has set up for that type of record keeping.

Page 47 of 52

The Tokenized protocol also allows for another method where the ticket collector can provide a string and the company's 'ticket receipt messaging address' to the ticket holder (QR code, speaking/reading). The token owner could then send a Message action (M1) Bitcoin transaction to the ticket receipt messaging address. The company's back-end software can simply verify that the sending address does indeed own the relevant ticket token by searching the transactions associated with the railway ticket's smart contract address. This would provide a timestamped on-chain record of the ticket being 'collected' by the ticket collector without actually transferring possession of the ticket token. The whole process can easily be done from a smartphone.

To prevent multiple users fraudulently sharing/using the season ticket, the railway company can set the controlling smart contract's authorizations to restrict transferring the season ticket and put the token owner’s driver’s license number in the Description sub-field of the on-chain token metadata. If there has been a large number of 'ticket collections' that day from the same token owner’s address, the ticket collector may ask for the token owner to show his driver’s license to prove his identity. There are also many variations on these approaches that can be used.

Another way the Tokenized protocol could be used to implement a repeat usage token, is by using the Enforcement operations to Freeze and Thaw a ticket. The Freeze action would be interpreted by the service provider (railway company) in this use case as 'checking in' or 'collecting the ticket' when the ticket holder gets on the train. The Thaw action would be interpreted to mean 'checking out' when getting off the train. This is an interesting approach because it allows the ticket to be tradeable and not tied to one identity, yet it still prevents the ticket from being fraudulently used by multiple users at any given time.

6.3 Multiple Concurrent Usages (e.g. streaming TV service subscription): The Tokenized system handles multiple concurrent usages in the same way as the repeat usage use case above. At login, the service provider could provide a randomly generated string (e.g. one-time password) to the token owner. The token owner would then sign a message with the private key associated with the public address that owned the token. The service provider would verify that the public address did, in fact, own the token, and that the token was valid (not expired). Streaming could then commence. The service provider could maintain a list of concurrent usages associated with that public key and remove access from older IP addresses as the concurrency limit was reached.

Alternatively, the service provider could issue the membership token (1x Asset Code) with ~3 tokens, for example, that can be shared/traded with friends/family members. Then the service provider could then limit streaming to one token at a time. There are a few variations of these basic principles, and the messaging example could also apply nicely to this use case as well. This use case could also be easily served with a great user experience by browser wallets and/or web wallets using API calls to pass the string, sign the message and pass the message and public address back to the service.

7 Definitions Ballot Cast:

A vote cast by a token owner in response to a Vote action.

Contract:

An established set of issuer-defined features and rules that facilitate the creation of tokens. A Tokenized contract can be a static or dynamic (‘smart’) contract. A static contract does not change with time (e.g. non-disclosure agreement, service agreement, employment agreement). A smart contract changes with time as the parties to the contract usually hold tradable tokens that represent rights and duties within the contract. The trading of these tokens requires record keeping and general management duties that are handled by an autonomous agent.

Page 48 of 52

Contract Fee:

A fee that is paid to the smart contract operator for the operation of the smart contract.

Currency Token:

A currency other than Bitcoin (BSV) represented by a token.

Exchange:

A voluntary trade between owners of tokens, currency or some other value.

Exchange Fee:

A fee that is paid to an exchange for facilitating the trade.

Identity Token:

A non-fungible token that represents an identity.

Initiative:

A proposal made by any token owner to capture votes from other token owners.

Issuer:

Organisation responsible for the creation and governance of tokens.

Miner:

An entity or consortium of entities involved in adding and confirming transaction records on the blockchain. Mining/Network Fee:

The Bitcoin transaction fee paid to the miner that wins the block that the transaction. Also known as a Network Fee.

Referendum:

A proposal made by the issuer to capture votes from token owners using predefined outcomes.

Redemption:

A token owner returns a token to the issuer for some value in exchange.

Safe Mode:

A config setting in the smart contract. When enabled, the smart contract will always wait for 6 confirmations (default) before publishing a response action for any token action that is dependent upon a preceding transaction that is unconfirmed. Safe Mode can be activated for certain request actions when double-spends are detected and/or for high value transactions whereby the value of bitcoin exceeds a specified threshold value.

Security Token:

A token that is legally defined to be a security.

Send:

Page 49 of 52

A transfer action that requires no consideration and no sign-off by the receiving party. A token can be sent to any bitcoin address that the smart contract permits.

Settlement:

The action from a smart contract to publicly announce that the previous Transfer operation action was accepted by the smart contract.

Smart Contract Operator:

Technical service provider that works on behalf of issuers. Smart contract operators write and operate smart contracts and facilitate the issuance, management and exchange of tokens on behalf of the issuer.

Swap:

The transfer of tokens directly in exchange for other tokens.

Token Offering:

An offering - public or private - that involves a utility or security token.

Token Owner:

An entity that owns the private key for a wallet that owns tokens.

Token Receiver:

The public key address for a buyer that is receiving the token, commonly via Exchange, Swap or Send action.

Token Sender:

The public key address for the owner disposing of the token as part of a sale or exchange.

User:

An entity that is a current, prospective or former token owner. An issuer can also be a user.

User Revocation:

Voluntary surrender of tokens back to the issuer made by the token owner. A user simply needs to send tokens back to the issuer.

Utility Token:

A token that represents a 1:1 fixed relationship with something of value.

Page 50 of 52

Page 51 of 52