Origo Whitepaper

Friday, February 14, 2020
Download document
Save for later
Add to list

Origo Privacy Preserving Platform For Decentralized Applications Origo Foundation [email protected] Version 0.2 Last Update: Jan 28th 2019 Disclaimer: this paper is intended to be a technical overview. It is not intended to be comprehensive nor to be the final design. Noncritical aspects are not covered.

ii Important Notice YOU MUST READ THE FULL LEGAL DISCLAIMER AND RISK FACTORS IN APPENDIX BEFORE CONTINUING READING THIS WHITE PAPER

Contents 1. Introduction 1 1.1. Privacy Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview 3 2.1. Scope of Aimed Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Origo Protocol 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Limitations of Current Solution . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Technical Design 9 4.1. Protocol Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Protocol Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Initialize Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Commit Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Execute Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. Settle Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Zero Knowledge Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. ZKP In Origo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Trusted Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Comparison with Secure Multi-Party Computation . . . . . . . 15 4.3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Infrastructure 16 5.1. Ethereum Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Confidential Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 iii

Contents iv 6. Future Improvements 18 6.1. Consensus Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.1. Computation Sharding . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2.2. State Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Applications 24 7.1. Applications Enabled by Origo . . . . . . . . . . . . . . . . . . . . . . . 24 7.1.1. Privacy against Public . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1.2. Privacy against Participant Party . . . . . . . . . . . . . . . . . . 25 7.2. Privacy Preserving Application Platform(PPAP) . . . . . . . . . . . . . 25 7.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Security 28 8.1. Fairness Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Execution Completeness - Party . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Execution Completeness - Executor . . . . . . . . . . . . . . . . . . . . . 29 9. Cryptoeconomics Design 30 9.1. Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Incentives and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Roadmap 33 Bibliography 34 List of figures 37 List of tables 38 A. LEGAL DISCLAIMER 39 B. RISK FACTORS 52

Chapter 1. Introduction Ethereum [1] has advanced Bitcoin [2] through smart contract to make digital assets being directly controlled by a piece of code, which creates possibility for more complex applications [3]. Yet, current smart contract has no privacy. The input data to the smart contract, and the execution result is public visible to the whole network, which limits the usage and adoption by many real-world privacy-concerned companies and indi- viduals [4]. While blockchain's powerful technologies have allowed untrusted parties to interact with each other securely and correctly, Origo strengthens that in addition to security and correctness, privacy is the key towards a broader adoption of blockchain. Although progresses like Zerocash [5] have enabled private transaction, Origo furthers such privacy work based on related research such as Hawk [6], Bulletproofs [7] etc. by enabling parties to create and execute smart contract without revealing private input and output. 1.1. Privacy Problems Real world governments and centralized private corporations are increasing om- nipresent surveillance on their citizens and users. Soon or later there will be a moment when citizens and users start demanding their fundamental human rights to privacy. With the growing global concern about privacy, public media has repeatedly covered controversial privacy related incidents. One examples is the story about government surveillance [8], and another example is Facebook's large-scale scientific experiment that was apparently conducted without explicitly informing participants [9]. 1

Introduction 2 Business and individuals have concerns when all of their privacy is viewed with- out restrictions on public blockchain, as such exposure might cause issues such as intellectual property ownership and rights, data misuse, inimical behaviors etc. In terms of contracts, many entities have major concerns on sensitive data/details, such as contract monetary amount, key data of performance/measurement, and contract execution prerequisites. Traditional smart contracts like Ethereum failed to protect these sensitive contract details, hence restricting industrial and personal usage. 1.2. Contributions • Privacy Preserving Application Platform: By combining an innovative privacy protocol with an efficient zero knowledge proof(ZKP) framework, Origo's Privacy Preserving Application Platform(PPAP) guards the input/output data privacy and transaction privacy for decentralized applications. • Off-chain Computation: Origo supports off-chain execution of decentralized applications, which not only protects the privacy of application execution, but also significantly improves the on-chain performance. • Future Work: multiple interesting future work could be introduced in later ver- sions: support of cross chain for privacy preserving applications, zero knowledge proof framework without trusted setup, formal verification tools for decentralized applications, adopting a high scalable architecture, which is achieved by imple- menting numerous promising technologies focusing on improving performance: enhanced consensus protocol, state-of-the-art sharding, stateless client, improved application runtime environment(Virtual Machine), and more.

Chapter 2. Overview 2.1. Scope of Aimed Privacy While recent projects like Monero [10], ZCash, etc. have strived to solve privacy issues by creating new private cryptocurrencies. Yet, these projects aim to achieve confidential transactions mainly through mechanisms of Zero-Knowledge Proofs and other cryptography primitives. Origo aims to provide more privacy preserving ability: not only confidential transactions, but also input/output data privacy for decentralized applications written in smart contracts. Therefore Origo's results much more complexity than those projects mentioned above. Here is a comparison of scope of aimed privacy between Origo and those confidential transaction focused projects. As it is shown in Table 2.1, if one illustrates Monero/ZCash/MimbleWimble as a fork of Bitcoin that support confidential transactions, then Origo is more aligned with an enhanced Ethereum-liked decentralized application platform which guards input/output data privacy of applications. Monero/ZCash Origo Sender Address Sender Address Transaction Amount Transaction Amount Receiver Address Receiver Address - Application Input - Application Output Table 2.1.: Comparison of privacy scope between Origo and Monero/ZCash 3

Chapter 3. Origo Protocol 3.1. Design Principles Privacy-preserving application platform provides more functionality than confidential transaction. Confidential transaction means to protect the sender and receiver along with the amount of money. Privacy preserving applications require more than that, including the functionality of confidential transaction, and also the ability of protecting input/output data privacy. Parties provide their input data (e.g., choices in a gamble game) and the currency units (e.g., bids in an auction) to the system. After receiving all the inputs, the system executes the application in off-chain, and then it encrypted outputs the payout distribution amongst the parties. The system needs to ensure the privacy of the inputs and the fairness of the execution: • Privacy of the inputs/outputs: The inputs and outputs of applications(including data and amount of currencies) should be protected against public. In other words, the inputs/outputs are cryptographically hidden from the public. To achieve this, all the information sent to/from blockchain is encrypted and uses zero knowledge proofs to ensure the correctness of contract execution. • Fairness of the execution: for decentralized applications, especially when there are multi-party involved, only protecting the privacy against public is not enough. Assuming the participants are selfish to maximize their own interest, they may abort before the execution. The system also need to ensure the fairness among the parties. 4

Origo Protocol 5 Origo proposes a solution to execute decentralized application securely and pri- vately. To protect input/output data privacy, Origo execute decentralized applications in an off-chain environment. A proof of off-chain execution should be submitted to on-chain for verification of correct computation. Application developers do not need to have knowledge about cryptography. At Origo privacy-preserving application platform (PPAP), they can write application in the original way and Origo PPAP compiles and executes application without leaking its input and output. PPAP empowers developers to build privacy-protecting applications easily and conveniently. To ensure efficiency and privacy, Origo has provided both on-chain and off-chain computation stages. The execution and proof of correctness for application requires privacy is done off-chain; the verification of computation for privacy preserving appli- cation and execution of normal application is done on-chain. We use zero knowledge proof to ensure that the public blockchain can verify the correctness of off-chain ap- plication execution, while maintaining execution details private. Origo also proposes proper economic mechanism to prevent malicious party aborting the contract. 3.2. Limitations of Current Solution There's no simple way to implement Turing complete, privacy preserving application using existing blockchain technology. Ethereum is a public permissionless blockchain that supports Turing complete applications. It does not provide any transaction privacy. Each node need run the contract to verify contracts are executed correctly. So the input, intermediate status and output of a contract is available to every node in Ethereum. There are some techniques that could preserve some privacy for certain applications in Ethereum. For example, when two parties are playing rock-paper-scissors games using Ethereum smart contract, if one party directly post its choice to the contact, the other party could take advantage of this by reading the first party's choice and post an adversary one. Instead, they could first post the hash of their choice plus a random string to the contract, and after both parties have committed their input, then they could reveal their input by submit their choice of random string to the contract. Then the contract can get input from each parties by checking if the hash of

Origo Protocol 6 their claimed input plus random string matches their submitted hash value. Code 3.1 demonstrates the described solution. Such techniques allows two parties to play this game, without worrying about one party could see another party's choice and adjust his choice accordingly. However, the outcome of this game is still public. Everyone could know who won the game and how much is paid to the winner. 1 def commit ( party , c h o i c e , random_string ) : 2 commitment = HASH_FUNC( c h o i c e , random_string ) 3 p a r t y . send ( commitment ) 4 5 def r e v e a l ( party , c h o i c e , random_string ) : 6 WAIT_UNTIL( l e n ( commitments ) == 2 , TIMEOUT( T ) ) 7 expected_commitment = HASH_FUNC( c h o i c e , random_string ) 8 received_commitment = commitments [ p a r t y ] 9 i f expected_commitment == received_commitment : 10 r e t u r n ( party , c h o i c e ) 11 r e t u r n ( party , NULL_CHOICE) 12 13 def e x e c u t e ( p a r t i e s , p a r t y _ c h o i c e s ) : 14 i f winner ( p a r t y _ c h o i c e s ) == p a r t i e s [ 0 ] : 15 transfer_all_fund_to ( parties [0]) 16 e l i f winner ( p a r t y _ c h o i c e s ) == p a r t i e s [ 1 ] : 17 transfer_all_fund_to ( parties [1]) 18 else : 19 refund_all_parties ( parties ) Listing 3.1: Pseudocode of smart contract on Ethereum to play rock-paper-scissors game Cryptocurrencies like Zcash or Monero partially solved this problem by supporting confidential transactions. However they do not support smart contract. Origo will support confidential transaction and smart contract for decentralized applications. And to prevent the input/out data of those privacy preserving applications becoming public, they will be executed off chain. But the execution could still be verified without revealing the actual result using zero knowledge proof. And proper protocol has been designed to incentivize each party to behave by the rules.

Origo Protocol 7 Figure 3.1.: Protocol Illustration 3.3. Protocol Overview To address above limitations, Origo supports private transaction and smart contract. Inspired by the work from Hawk [6], we introduce a protocol combining on-chain and off-chain computation, which preserves the privacy of smart contract when executing. As shown in Figure 3.1, there are four phases in our protocol: Initialize, Commit, Execute and Settle. Here's a brief explanation of the four phases. Most of the details are described in next chapter. In Initialize phase, an executor from the network will be elected for later execution phase. In Commit phase, each party will freeze their coins to the contract, and they will submit a commitment including their private input and coin. By using the commitment schema, the input and coin will be private, but the party can't change it after commitment. After all parties have submitted the commitment or the timeout of this phrase has reached, and the deposit has been verified. It moves to next phase. In the Execution phase, each party will reveal their private input to an offline executor. Executor will execute smart contract offline, in this way the input and execution result will not be revealed to public.

Origo Protocol 8 After contract is executed. Executor will generate a zero knowledge proof that the contract is executed correctly. Once the blockchain verifies the correctness, the fund will be distributed to each party based on execution result. By using this protocol, user input, transaction amount and contract execution details are kept private. But everyone could still verify whether contract is correctly executed.

Chapter 4. Technical Design 4.1. Protocol Roles Origo protocol contains three major roles involved in the full life cycle of smart contract execution: • Parties: P1 , · · · , PN , a set of users participating the Smart Contract SC. Parties of- priv priv pub pub fer private input I1 , · · · , IN , public input I1 , · · · , IN and coins C1 , · · · , CN . • Blockchain:B, an open, distributed ledger that can record transactions between parties efficiently and in a verifiable and permanent way. • Executor:PE, a special party facilitates the execution of Origo's smart contract. Executor outputs the result O1 , · · · , O N for each party. 4.2. Protocol Phases The Origo protocol has four phases: Initialize, Commit, Execute, Settle, These four phases are strictly bounded by two timeouts:T1 and T2 , while Tcommit < T1 and T1 ≤ Texecute < T2. Here are the technical details of each phase. 4.2.1. Initialize Phase Parties elects a node Ni in Blockchain B as executor PE , PE 's public key KE is shared to all parties. 9

Technical Design 10 4.2.2. Commit Phase Each Party Pi (i ∈ [ N ]) freeze the coin Ci (i ∈ [ N ]) they want to deposit into the priv smart contract from its wallet. Each party will compute a commitment cm = comm(Ci || Ii ) , and zero knowledge proof Proo f Ci (i ∈ [ N ]) of its frozen coin Ci . The commitment cm and Proo f Ci is supposed to be sent to blockchain B before T1 , otherwise parties will not be accepted as contract's participants. Blockchain B is responsible for verifying Proo f Ci sent by each party, and guarantee no new parties is accepted after T1 . If all the required parties have committed their input and coins, the contract will move to Execute phase. Otherwise the contract will be aborted and all the committed coins will be refunded to each party. The purpose of this phase is to let each party submit their input and coins privately. No one (even the executor) could know other parties'input or coin at this phase. Their input and coins deposit to smart contract are immutable after this phase. No one could take advantage by changing his own input or coin after knowing other parties'input. 4.2.3. Execute Phase priv Each Party Pi (i ∈ [ N ]) encrypts its private input Ii (i [ N ]) and coins Ci (i ∈ [ N ]) in- formation with executor PE 's public key KE . And a zero knowledge proof Proo f Ei (i ∈ [ N ]) is built to prove that the encrypted value matches his commitment cm. The encrypted priv data ENC ( Ii ||Ci ) and corresponding proof Proo f Ei will be send to blockchain. Once blockchain receives the encrypted data and proof from each party. B will priv verify that for each party, the encrypted data ENC ( Ii ||Ci ) matches the commitment priv cm = comm(Ci || Ii ) submitted in commit phase. This prevents any party alert their input data after other parties submitted their encrypted data. After B successfully verified Proo f Ei and checked current time T1 ≤ T < T2 , it sends the encrypted data to executor PE . After receiving the verified encrypted data from blockchain B, executor PE decrypts priv it with his private key PKE to get Ii ) and Ci for each party, and executes the smart contract. Before T2 , if any parties failed to send the encrypted data and proof to blockchain, or if the proof is not correct, that party will be considered as aborting the contract.

Technical Design 11 Proper punishment could be applied to his deposit based on the requirement of the contract. If the executor failed to send the output and proof to the blockchain before timeout, executor will be considered as aborting. Since a malicious executor could on purpose abort the contract if the execution result is not in certain party's favor. To prevent this, we could require executor to pay certain amount of deposits. When executor failed to submit the result or proof, he will lose his deposit. To make sure executor will not disclose each party's input or outcome after execu- tion, it is a good idea to run execution on trusted hardware like Intel SGX [11]. 4.2.4. Settle Phase Once executor PE finished its execution, outputs O1 , · · · , O N for each party Pi (i ∈ [ N ]) is produced. PE builds proof Proo f E to prove the outputs are correctly compute from parties'inputs and the smart contract, and encrypt the outputs O1 , · · · , O N with each party's public key KPi (i ∈ [ N ]) as ENC (O1 ), · · · , ENC (O N ). Then PE sends Proo f E and ENC (O1 ), · · · , ENC (O N ) to blockchain B, B verifies Proo f E to check the contract is executed correctly, and distributes the coins to each party based on execution result. Lastly, each party decrypts the output. If he gets any coin from the contract, he could deposit it to his wallet using private transaction. 4.3. Zero Knowledge Proof Zero Knowledge Proof (ZKP) is key technique for Origo to ensure the privacy of the smart contract while executing the contract correctly and completely. ZKP is a well established method in cryptography. In ZKP, there two parties, one party, called prover can prove to another party, called verifier, some statements holds without sharing any information about why it holds. ZKP protocol must satisfy the following properties: • Completeness: given honest prover and honest verifier, the protocol succeeds with overwhelming probability.

Technical Design 12 • Soundness: no one who does not know the secret can convince the verifier with the non-negligible probability. • Zero Knowledge: the proof does not leak any additional information. The very intuitive way to create a ZKP protocol is to allow the interactive communi- cation between prover and verifier, called Interactive Zero Knowledge Proof, IZKP. Verifier can construct any question (even randomly) for prover based on the assump- tion that prover knows the secret information and prover can answer that question only if possessing announced secret information, of course constructing questions based the previous replies from the prover is also allowed. It is possible to convert any IZKP (if the verifier is a public coin verifier, i.e. the random choices made by the verifier are made public) into a non-interactive protocol that is secure and zero-knowledge in the random oracle model using the Fiat-Shamir heuristic [12] — All random challenges are replaced by hashes. More specifically, Non-Interactive Zero Knowledge Proofs (NIZK) have been proposed as the tool to enable smart contracts which do not expose the user inputs in academia [6, 13, 14]. But NIZK has its own limitation for the practical usage of smart contracts. Due to the fact the communication over the blockchain equipped with smart contract is expensive and the smart contract's own computation ability is very limited. Even the current widely adopted SNARKs [15], which is a neutral choice for smart contracts require a complex trusted setup. The core of the trusted setup, common reference strings (CRS) are usually long and specific to each individual smart contract and makes the schema unreliable because of the possible trapdoors. Arithmetic circuit (AC), as the core of every digital circuit, can be used to form any mathematical representation. It is a combination of small logic operations, like addition, subtraction, multiplication, and division. For example, Figure 4.1 shows the AC format for computation ( a + b) × c/d. Based on the fact that (a) any computational condition can be represented by AC, which takes some input and output a boolean value, true or false; (b) smart contract, which is turing complete in a formally specified language, can be viewed as a complicated collection and interaction of computational conditions. So, transferring smart contract to arithmetic circuit is not a surprise. Different techniques has been proposed [7, 16] to create efficient zero-knowledge argument for arbitrary arithmetic circuit (AC), i.e. prover can prove the possession of certain input to satisfy the AC, or

Technical Design 13 Figure 4.1.: Example of arithmetic circuit say making the AC output true. So proving the correctness of the contract execution without sharing contract data/information becomes possible. 4.3.1. ZKP In Origo In Orgio, ZKP is used to shield transaction information(send/receiver address, trans- action amount) and input/output of smart contract. Based on section 3.3, when executing a private smart contract, multiple phases require ZKP to prove and verify commitment from both parties Pi (i ∈ [ N ]) and executor PE : • Commit Phase: parties Pi (i ∈ [ N ]) need to prove they have put sufficient coins Ci (i ∈ [ N ]) into the smart contract SC: – statement := N IZK.Prove( Pi , (Ci ||Ki ), witness) (i ∈ [ N ]) – N IZK.Veri f y( Pi , statement) priv • Compute Phase: parties Pi (i ∈ [ N ]) need to prove their private inputs Ii (i ∈ [ N ]) of smart contract SC are correctly encrypted with executor's public key KE : priv – Ii := ENC ( Ii , KE ) (i [ N ])(Off-chain) priv – statement := N IZK.Prove( Pi , Ii , witness) (i ∈ [ N ]) – N IZK.Veri f y( Pi , statement) • Settle Phase: executor PE needs to prove it successfully executed smart contract SC with correct output Oi (i ∈ [ N ]): – statement := N IZK.Prove( Pi , Oi , witness) (i ∈ [ N ])

Technical Design 14 Proof System zk-SNARKs zk-STARKs Bulletproofs Proof Size Short Medium to short Short Prover Time FFT FFT(high memory consumption) Linear Verifier Time Efficient Efficient Linear Trusted Setup Required Not Required Not Required Practical Yes No Yes Table 4.1.: Comparison of different ZKP systems priv – statement := N IZK.Prove( Pi , Ii , witness) (i ∈ [ N ]) All proving processes in Origo described above are proceeded off-chain, which could possibility take a few seconds to minutes for being finished. While for verifying, different NIZK systems show variant performance while verifying on-chain. The variance of verifying performance is traded off between requirement of setup process and proof/verification size. 4.3.2. Trusted Setup As we described above, most of the current techniques requires a trusted setup step for each application, then either a trusted third party or multi-party computation (MPC) has to be used. However, since Origo is designed to support privacy preserving smart contract, so each smart contract needs a trusted setup for creating unique CRS. No matter which trusted setup process we could take, it makes creating a privacy preserving smart contract very heavy and inflexible. Therefore, for privacy preserving smart contract, no trusted setup is essential for making Origo practical. Note that, for private transaction, we could tolerate trusted setup, because it only need to be done once, and industry already had showcases for running a valid setup ceremony. We investigated several new techniques [7,15] provide a valid ZKP protocol without trusted setup, as illustrated in Table 4.1, currently practical proof system without trusted setup has worse verifier efficiency. More expensive verifier could further degrade consensus speed, if verification is required to be done on chain. To work around this, off-chain verification is necessary to minimize the drawbacks caused by new proof system without trusted setup.

Technical Design 15 Features Secure Multi-Party Computation Origo Performance Poor Acceptable Privacy of Output No Yes Synchronization Required Not Required Table 4.2.: Comparison of Secure Multi-Party Computation and Origo 4.3.3. Comparison with Secure Multi-Party Computation Besides ZKP, we also researched several other privacy preserving technologies such as homomorphic encryption and secure multi-party computation. Secure multi-party computation allow parties to jointly compute a function over their inputs while keep- ing those inputs private. When applied to smart contract, it also allows participating parties to jointly compute the out of smart contract execution, and keep their input data private. However, MPC requires multiple rounds of interactions between parties, but non- interactive zero knowledge proof does not require this between proofer and verifier. Also, there's no existing approach for execution results to be privately preserved by all participating parties. Most importantly, the computation complexity of MPC is much higher than ZKP, and it could only be applied to limited scope in real applications. Therefore, we think ZKP is a better solution to build privacy preserving application platform. 4.3.4. Conclusion To ensure the efficiency of private transaction, we prefer to apply ZKP that require trusted setup for private transaction verification. Because it has more efficient veri- fication time and the verification could be done on blockchain. And requiring each privacy preserving smart contract to perform its own trusted setup is not practical. Therefore we prefer to apply ZKP techniques that does not require trusted set up to verify contract execution.

Chapter 5. Infrastructure 5.1. Ethereum Compatibility As our current status, Origo's chain infrastructure is Ethereum compatible: PoW consensus, EVM, Solidity. Initially we developed our platform based on Ethereum's byzantium fork. The reasons that chooses Ethereum compatible infrastructure as the first step are: Ethereum community has the largest groups of active developers; We could invest more resources on our privacy technologies to make them optimal. The block gas limit of our current platform is designed to be higher than what cur- rent Ethereum has, because privacy preserving features require more computation resources. However, Ethereum compatible infrastructure has several scalability chal- lenges, we are willing to overcome these challenges in the later versions of Origo platform. 5.2. Confidential Transaction The goal of confidential transaction is to ensure that the data in the transaction remains private. Similar to Zcash, confidential transaction uses private addresses. The transac- tion between two private addresses will not leak any information about the sender, receiver or transaction amount to the third party. User could also transfer token from public address to private address, and vice versa. We utilize zero knowledge proof system zkSNARKs to keep the transaction data private. And the correctness of the confidential transaction(such as sender knows the secrete to spend the token from the 16

Infrastructure 17 private address, and the sum of input token equals the sum of output token), could still be verified by the public.

Chapter 6. Future Improvements Ethereum-like infrastructure suffers several limitations on scalability to make the platform to be extremely efficient. Therefore, our future improvements on the platform will be mostly focus on implementing more scalability features: • Optimized Consensus - a hybrid consensus to improve the throughput of trans- actions. • Sharding - a state-of-the-art sharding protocol to make Origo linearly scalable. • Enhanced Virtual Machine - a new virtual machine standard to improve the execution speed of smart contract. In this whitepaper, below sections introduce these techniques briefly. Once we have more concrete design on each of these potential techniques, we will publish more detailed documents. 6.1. Consensus Protocol Consensus specifies how a group of nodes in network reach agreements on a value. Consensus protocol should be resilient to failures of nodes, network partitioning, out-of-order/corrupted messages or message delays. Selfish node or deliberately malicious node could also breaks the consensus or leads to wrong state. There are two key properties in consensus: i) non-faulty nodes should produce output even- tually(liveness); ii) all nodes participating in the consensus produces identical and valid output(consistency). Consensus is not a new problem: the academic world has 18

Future Improvements 19 Classical Consensus Blockchain Consensus Example pBFT, Paxos PoW, PoS, PoA Transaction Throughput High Low to medium Network Size Small Large Openness Permissioned Permissionless Table 6.1.: Comparison between classical consensuses and blockchain focused consensuses been studying it extensively for several decades, and developed numerous practical solutions which could tolerate malicious nodes [17, 18]. However, these solutions are aimed for closed, permissioned, low latency network. Bitcoin's fundamental innovation was to enable consensus on open, permissionless and decentralized network. It was achieved by a leader election procedure called Proof-of-Work(PoW): all participants attempt to solve a mathematical puzzle and the participant who wins has the right add next block. PoW has very strong guarantee of security on permissionless network, however it suffers from poor performance without fundamental redesign [19] and it consumes a huge amount of energy. With the rapid growth of blockchain industry, numerous proposals have been made to address above issues [20]. Some researches focused on reduce the energy consump- tion(e,g. Proof-of-Stake, PoS [21]), while others focused on modify the original PoW protocol to have better performance [22]. Compared to classical consensus protocol on permissioned network, performance of these protocols are still not quite ideal when adopting blockchain into real world applications. Table 6.1 illustrates between classical consensuses and blockchain focused consensuses. Given the fact that both classical consensus and blockchain focused consensus are not quite ideal for massive adoption in current blockchain environment. We believe a hybrid consensus protocol, which is able to achieve similar performance like classical consensus, and it does not require permissioned settings, should be considered to be a long term consensus engine for our platform. Figure 6.1 demonstrates the future possible architecture of Origo Consensus: • To address the requirement of node awareness in pBFT consensus, we need an identity chain. The identity chain uses current widely adopted blockchain focused consensus like PoW or PoS, or any other consensus that is resilient to

Future Improvements 20 Figure 6.1.: Origo Consensus Architecture sybil attack [23]. The identity chain is a chain of Identity Block, each block contains a list of nodes which are eligible for being transaction chain validators. • pBFT should be adopted as the consensus of transaction chain. Due to pBFT has best performance in relatively small network(e.g. a few hundreds of nodes), therefore a periodical validator election is implemented, a fixed but configurable number validators are randomly elected from nodes recorded in identity chain to perform pBFT consensus. • A random beacon based on BLS signature [24] has to be implemented as a secure source of distributed randomness. The randomness is required for electing validators from candidates, and also sharding the network. We will have more design and implementation details about Origo's hybrid con- sensus in future documents. 6.2. Sharding In most current blockchain designs, each node stores all on-chain data, processing all transactions. Though this mechanism largely protects the security, however it sacrafices performance a lot. Blockchains like Ethereum or Bitcoin could only process less than tens of transactions per second. To address these issues, We concluded there are two types of sharding mechanism: computation sharding and state sharding.

Future Improvements 21 6.2.1. Computation Sharding Computation sharding indicates nodes are split into multiple groups, each group processes a subset of transactions. Therefore the network is linearly scalable with the increasing number of groups. However a secure deterministic random generator is essential for grantee security. Without a secure and deterministic random generator, the shard assignment will be deductible. A deductible shard assignment would greatly decrease security, the difficulty of attacking a single shard is much less than attacking the entire network. As we mentioned in 6.1, we need a BLS signature [24] to generate random number with group of pre-elected validators. The shard assignment will be recorded into Identity Block, and client uses this information send transaction to corresponding shards. Using sender address of a transaction as the sharding criteria, would guarantee all transactions from same account will be processed in same shard, which minimize the cross shard communication requirement. 6.2.2. State Sharding To further improve scalability, State sharding should be also adopted. State sharding indicates nodes are sharded to store partial block data. Compared to computation sharding, state sharding has much more challenging issues: i) it needs to extensive work to make it secure ii) cross shard communication is necessary and often, because it’s very likely a transaction needs to involve state cross multiple shards, but cross shard communication would hurt the overall throughput. 6.3. Virtual Machine Virtual Machine is the runtime environment for smart contract, which is one of the most crucial part of blockchain to support smart contract. Future Origo VM should be based on an emerging virtual machine standard: WebAssembly (or WASM for short), a new, portable, size- and load-time-efficient format. WebAssembly is currently being designed as an open standard by a W3C Community Group. WASM is not only efficient and performant, but also contains support from LLVM as compilation backend, which could support multiple programing languages as input. In the long

Future Improvements 22 term, Future Origo VM will support more developer friendly language like Python or Java. Figure 6.2 illustrates the process of compiling and executing a smart contract. Figure 6.2.: Ethereum's Compile and execute process of smart contract Origo's privacy preserving smart contract, which relies on Zero Knowledge Proof(ZKP) to proof and verify privacy preserving smart contract execution, requires compiler and VM integrated with ZKP systems. A privacy preserving smart contract needs to be compiled into arithmetic circuits as provable program in ZKP system. The VM should be able to run the circuits to produce proofs and verify proofs. Because Origo supports both public and privacy preserving smart contract, an Origo VM instance is designed to be able to run both public and privacy preserving smart contract. Therefore the above normal pipeline of compiling and executing smart contract would not be able to meet our requirement. In the long term, a pipeline which accepts both public and privacy preserving smart contract is necessary. illustrated as Figure 6.3. Currently, Origo's Virtual Machine is EVM compatible with extended opcode to support ZKP prove and verify operation with circuits. Moreover, Origo's privacy preserving smart contract language is a limited Solidity with strict on certain operations to achieve better performance. Note that Origo public smart contract is complete Solidity. We intend to use Solidity as Origo DSL because of minimum effort is required for migrating smart contract from Ethereum to Origo.

Future Improvements 23 Figure 6.3.: Origo's Compile and execute process of smart contract

Chapter 7. Applications 7.1. Applications Enabled by Origo Origo' Privacy Preserving Protocol enables broad adoption of decentralized applica- tions that requires privacy. As mentioned in section 2.1, we classify them into two categories: 7.1.1. Privacy against Public In this category participants want to keep input and output private from public, but they are fine to share these information between participants. Here are some examples of applications at each domain: Finance: • Private exchange • Credit scoring • Online lending • Insurance • Options and futures contracts Enterprise: • Salary/bonus contracts 24

Applications 25 • Employee stock incentive plans • Supply chain contracts • Corporate compliance Health Care: • Personalized medicine • Diagnostics • Medical records Others: • IoT For applications in this category such as payroll, employee and employer involved just want to keep the salary private from public. In this case, either employer or employee can execute the contract locally and submit a zero knowledge proof to blockchain. So the Origo protocol could be optimized to improve the efficiency for these application. 7.1.2. Privacy against Participant Party In this category, each participant want to keep his input, output and transaction amount private from everyone else. So the full origo protocol will be applied to satisfy the privacy requirement. Examples of such applications include: • Fundraising(e.g. token fundraising) • Auction • Voting 7.2. Privacy Preserving Application Platform(PPAP) With Origo PPAP, developers can build Privacy-Preserving applications without knowledge of cryptography, since Origo PPAP provides a compiler which auto-

Applications 26 matically generates cryptographic protocols, using cryptographic primitives such as Zero-Knowledge Proofs. 7.3. Example We present the pseudocode for the payroll that uses Origo application platform: 1 # Employer o f f c h a i n 2 def commit ( r a t e , c o i n ) : 3 cm = commitment ( r a t e , c o i n . value ) 4 proof = ZKP . prove ( c o i n i s v a l i d ) 5 # i n t e r a c t with b l o c k c h a i n 6 BlockChain . _commit ( proof , coin , cm) 7 8 def e x e c u t e ( r a t e , c o i n ) : 9 e n c r y p t e d _ i n p u t = e n c r y p t ( e x e c u t o r . epk , [ r a t e , c o i n . value ] ) 10 proof = ZKP . prove ( e n c r y p t e d _ i n p u t c o r r e c t l y encrypted ) 11 # i n t e r a c t with b l o c k c h a i n 12 BlockChain . _ e x e c u t e ( proof , e n c r y p t e d _ i n p u t ) 13 14 # BlockChain 15 def _commit ( proof , coin , cm) : 16 ZKP . v e r i f y ( proof , c o i n i s v a l i d ) 17 check ( not_spend ( c o i n ) ) 18 freeze_coi n_to_contract ( coin ) 19 20 def _ e x e c u t e ( proof , e n c r y p t e d _ i n p u t ) : 21 ZKP . v e r i f y ( proof , e n c r y p t e d _ i n p u t c o r r e c t l y encrypted ) 22 # send e n c r y p t e d _ i n p u t t o e x e c u t o r . 23 c a l l Executor . e x e c u t e ( e n c r y p t e d _ i n p u t ) 24 25 def _ s e t t l e ( output , [ coin_employee , coin_employer ] , p r o o f s ) : 26 ZKP . v e r i f y ( proofs , c o n t r a c t i s c o r r e c t l y executed and [ coin_employee , coin_employer ] a r e v a l i d ) 27 _send ( coin_employee , employee )

Applications 27 28 f r e e z e _ c o i n _ t o _ c o n t r a c t ( coin_employer ) # f o r l a t e r use 29 30 # Executor o f f c h a i n 31 def e x e c u t e ( e n c r y p t e d _ i n p u t ) : 32 r a t e , c o i n _ v a l u e = decrypt ( e n c r y p t e d _ i n p u t ) 33 s a l a r y = r a t e * hour 34 balance = coin_value − salary 35 output = e n c r y p t ( { b a l a n c e } , employer . enc_key ) 36 i f balance > 0 : 37 coin_employee = c o i n ( s a l a r y ) 38 coin_employer = c o i n ( b a l a n c e ) 39 else : 40 h a n d l e _ e r r o r ( " not enough b a l a n c e " ) 41 coin_employee = c o i n ( c o i n _ v a l u e ) 42 coin_employer = c o i n ( 0 ) 43 44 p r o o f s = [ZKP . prove ( c o n t r a c t i s c o r r e c t l y executed ) , ZKP . prove ( [ coin_employee , coin_employer ] a r e v a l i d ) ] 45 # i n t e r a c t with b l o c k c h a i n 46 BlockChain . _ s e t t l e ( output , [ coin_employee , coin_employer ] , p r o o f s ) Listing 7.1: Pseudocode of smart contract on Origo to execute a payroll The employer offchain part is auto generated, and the code on the blockchain part is built in by Origo. Developers just need to implement the logic within the executor part. It would be very similar as writing a smart contract in Ethereum.

Chapter 8. Security 8.1. Fairness Assurance To ensure the fairness of the execution of smart contract, inputs and execution are separated into two steps. All contract's participants must prepare and commit their encrypted inputs (including money) before starting execution. Since all of these commits are encrypted, if they do not want to disclose to other parties, all inputs will be hidden from each other. When the commit step ends, none of the parties can change the input anymore. After commit step finishes, parties need to open their inputs to the executor so that the executor can process the smart contract. In this step, even arbitrary parties know others'inputs, because all inputs are immutable after the commit, they can not change the inputs anymore. By this design, none of the parties can affect the result of the execution. 8.2. Execution Completeness - Party Since the design ensure the fairness among all the participants, none of them can change the execution result, the only thing they can do is to abort to prevent loss if arbitrary parties know others' inputs and predict the result (e.g., gamble game). Deposit mechanism is introduced to prevent this. For contracts need to prevent quitting (e.g., gamble game), Origo provides a deposit framework for contract designer, which allows all parties make deposit before participating. Therefore, if any parties abort the contract, all their deposit will be shared by other participants. In this way, the parties won't have the motivation to abort the contract. 28

Security 29 8.3. Execution Completeness - Executor Unlike parties' abortion, deposit is not enough for executor. By default, the executor will also make deposit to execute the contract. Once it fails, the deposit will be distributed among all participants. For contracts with high availability requirement, backup executor mechanism is designed. There will be another executor/group runs the same contract and serve as verifiers. Normally, it will only check the result of the main executor, if the executor abort, it will be the backup.

Chapter 9. Cryptoeconomics Design 9.1. Design Principles Former decentralized systems like torrent platform have failed due to lack of economic incentives for users to follow rules, such as keeping seeds to share the file with the network for others to download in torrent's case. Bitcoin has improved these decentralized systems by establishing a proper crytoeconomic mechanism for users to not only follow the rules, but also overcome Byzantine General's Problem to create a perfect consensus system. On Origo platform, rules (shown later in this chapter) mainly focus on issues with privacy that, for instance, each role of Origo DOES NOT conduct any intended or unintended behaviors related to smart contract privacy such as info leak and privacy preserving contract execution abort. In order to reach consensus based on rules of Origo, incentive mechanism alone would be insufficient as consensus algorithms like POW and POS could cause “double spending” or “nothing at stake” problems, due to a lack of punishment (negative incentive) mechanism. Therefore, Origo applies a hybrid consensus algorithm combine BFT consensus with stake based blockchain consensus. 9.2. Incentives and Roles First of all, Origo Consensus consist of two incentive sets described in Table 9.1. 30

Cryptoeconomics Design 31 Incentive Set #1 - Basic Set Origo Token Origo Token serves a similar “gas fee” function as ETH on Ethereum. Roles who actively participate and con- tribute to the blockchain get assigned cryptocurrencies for their efforts. Privileges Roles can use Origo Token for various purposes within Origo ecosystem. Incentive Set #2 - Advanced Set Deposits Origo Token required as deposits to perform certain tasks, such as bidding for an Executor job. Payments Participants pay certain amount of Origo Token in or- der to participate certain activities, including transac- tion fees. Rewards Good participants at Origo get Token rewards for do- ing well. Punishments Bad participants lose portion or all of their deposits or their certain rights are taken away for behaving badly according to rules. Table 9.1.: Incentive Set Origo defines these denotations for such incentives for later discussion: • Token Rewards: R1 , · · · , Rn of the nth party • Payment:P1 , · · · , Pn of the nth party • Deposits: D1 , · · · , Dn of the nth party • Punishments: Pun1 , · · · , Punn of the nth party In addition, Origo defines four roles on its platform: • Validators: Vi ∈ V, who provides computation power to the platform to execute various tasks such as proof verification and block validation; Vi receives RVi after mining a block or computing a certain task. • Users: Ui ∈ U, who utilize contracts or DApps on the platform; Ui makes a deposit DUi and/or payment PUi in exchange of a service/product through smart contracts and DApps; Ui could also gain rewards RUi through a contract or DAPP if such mechanisms are created by developers.

Cryptoeconomics Design 32 • Contract/DAPP Developers: Devi ∈ Dev, who create privacy preserving smart contracts and DApps; Devi make a payment PDevi for using computation resource and obtain rewards R Devi for generating smart contracts and DApps. • Executor: Ei ∈ E, who conduct privacy related tasks in Zero Knowledge Proof. Ei is forced to make a deposit DEi by Origo to prevent misconducting, otherwise receives a punishment Pun Ei . Ei can also obtain rewards R Ei after completing a privacy related task. In order to make incentives sets work for each role, these are the fundamental protocols: 1. For any activity i on Origo platform, DUi + PUi + PDevi + DEi ≥ R Mi + RUi + R Devi + Pun Ei + R Ei always applies, where DUi , PUi , PDevi , DEi , R Mi , RUi , R Devi , Pun Ei , R Ei ≥ 0 all the time. 2. While Origo lets the supply and demand law decide the exact amount of DUi , PUi , PDevi , DEi , RVi , RUi , R Devi , Pun Ei , R Ei on platform, ∑ DUi + PUi + PDevi + DEi ≥ ∑ RVi + RUi + RDevi + PunEi + REi at all time to maintain platform sustainability.

Chapter 10. Roadmap • 2018 December: Originis: Test net release with confidential transaction. • 2019 4th Quarter: Medietas: Main Net release. • 2020 1st Quarter: Adscensus: Enable Built-in privacy preserving smart contracts. • 2020 2nd Quarter: Infinitas: Enable developers to create their own Privacy Pre- serving, Secure and Verifiable smart contracts. 33

Bibliography [1] G. Wood, Ethereum Project Yellow Paper 151, 1 (2014). [2] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, 2009. [3] V. Buterin, (2014). [4] T. Macheel, Banks's Privacy Concerns Shaping Blockchain Vendors’ Strategies, https://www.americanbanker.com/news/ banks-privacy-concerns-shaping-blockchain-vendors-strategies, 2016, [Online; accessed 15-March-2018]. [5] E. B. Sasson et al., Zerocash: Decentralized anonymous payments from bitcoin, in Security and Privacy (SP), 2014 IEEE Symposium on, pp. 459–474, IEEE, 2014. [6] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, Hawk: The blockchain model of cryptography and privacy-preserving smart contracts, in Security and Privacy (SP), 2016 IEEE Symposium on, pp. 839–858, IEEE, 2016. [7] B. BÃijnz et al., Bulletproofs: Short proofs for confidential transactions and more, Cryptology ePrint Archive, Report 2017/1066, 2017, https://eprint.iacr.org/ 2017/1066. [8] J. Ball, NSA's Prism surveillance program: how it works and what it can do, https://www.theguardian.com/world/2013/jun/08/ nsa-prism-server-collection-facebook-google, 2013, [Online; accessed 15-March-2018]. [9] V. Goel, Facebook Tinkers With Users'Emotions in News Feed Experiment, Stirring Outcry, http://nyti.ms/2eFHePr, 2014, [Online; accessed 15-March- 2018]. [10] N. van Saberhagen, Crypto Note v2.0, howpublished = "https://github.com/ monero-project/research-lab/blob/master/whitepaper/whitepaper.pdf", 34

BIBLIOGRAPHY 35 year = 2016, note = "[online; accessed 15-march-2018]". [11] Intel, Intel Software Guard Extensions, https://software.intel.com/en-us/ sgx, 2017, [Online; accessed 15-March-2018]. [12] M. Bellare and P. Rogaway, Random oracles are practical: A paradigm for designing efficient protocols, in CCS ’93, Proceedings of the 1st ACM Conference on Computer and Communications Security, Fairfax, Virginia, USA, November 3-5, 1993., pp. 62–73, 1993. [13] P. McCorry, S. F. Shahandashti, and F. Hao, A smart contract for boardroom voting with maximum voter privacy, in Financial Cryptography and Data Security - 21st International Conference, FC 2017, Sliema, Malta, April 3-7, 2017, Revised Selected Papers, pp. 357–375, 2017. [14] M. Campanelli, R. Gennaro, S. Goldfeder, and L. Nizzardo, Zero-knowledge contingent payments revisited: Attacks and payments for services, Cryptology ePrint Archive, Report 2017/566, 2017, https://eprint.iacr.org/2017/566. [15] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, Succinct non-interactive zero knowledge for a von neumann architecture, in Proceedings of the 23rd USENIX Conference on Security Symposium, SEC’14, pp. 781–796, Berkeley, CA, USA, 2014, USENIX Association. [16] J. Bootle and J. Groth, Efficient batch zero-knowledge arguments for low degree polynomials, Cryptology ePrint Archive, Report 2018/045, 2018, https://eprint. iacr.org/2018/045. [17] L. Lamport, ACM Transactions on Computer Systems (TOCS) 16, 133 (1998). [18] M. Castro et al., Practical byzantine fault tolerance, in OSDI Vol. 99, pp. 173–186, 1999. [19] K. Croman et al., On scaling decentralized blockchains, in International Conference on Financial Cryptography and Data Security, pp. 106–125, Springer, 2016. [20] S. Bano, M. Al-Bassam, and G. Danezis, USENIX; login: magazine (2017). [21] S. King and S. Nadal, self-published paper, August 19 (2012). [22] A. Gervais et al., On the security and performance of proof of work blockchains, in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications

BIBLIOGRAPHY 36 Security, pp. 3–16, ACM, 2016. [23] Wikipedia, Sybil attack — Wikipedia, the free encyclopedia, http://en. wikipedia.org/w/index.php?title=Sybil%20attack&oldid=833940724, 2018, [Online; accessed 05-May-2018]. [24] D. Boneh, B. Lynn, and H. Shacham, Short signatures from the weil pairing, in International Conference on the Theory and Application of Cryptology and Information Security, pp. 514–532, Springer, 2001.

List of figures 3.1. Protocol Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Example of arithmetic circuit . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Origo Consensus Architecture . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Ethereum's Compile and execute process of smart contract . . . . . . . 22 6.3. Origo's Compile and execute process of smart contract . . . . . . . . . 23 37

List of tables 2.1. Comparison of privacy scope between Origo and Monero/ZCash . . . 3 4.1. Comparison of different ZKP systems . . . . . . . . . . . . . . . . . . . 14 4.2. Comparison of Secure Multi-Party Computation and Origo . . . . . . . 15 6.1. Comparison between classical consensuses and blockchain focused consensuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Incentive Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 38

Appendix A. LEGAL DISCLAIMER The sale ("Token Sale") of the Origo Token ("Origo Tokens"), the exchange medium for participants on the Origo platform as detailed in this whitepaper (the "Whitepaper") is only intended for, made to or directed at, only certain persons. Moreover, this Whitepaper is not a prospectus or offer document of any sort and is not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction. No regulatory authority has examined or approved of any of the information set out in this Whitepaper. This Whitepaper has not been registered with any regulatory authority in any jurisdiction. By accessing and/or accepting possession of any information in this Whitepaper or such part thereof (as the case may be), you represent and warrant to Origo Foundation (Singapore Foundation Registration No. 201808339D) (the "Project Company",the "Token Issuer") that: • (a) you are not located in the People's Republic of China and you are not a citizen or resident (tax or otherwise) of, or domiciled in, the People's Republic of China; • (b) you are not located in the United States of America and you are not a citizen, resident (tax or otherwise) or green card holder of, or domiciled in, the United States of America unless you are a U.S. Qualified Person (as defined herein); • (c) you are not located in a jurisdiction where the Token Sale is prohibited, re- stricted or unauthorized in any form or manner whether in full or in part under its laws, regulatory requirements or rules; • (d) you agree to be bound by the limitations and restrictions described herein; 39

LEGAL DISCLAIMER 40 • (e) you acknowledge that this Whitepaper has been prepared for delivery to you so as to assist you in making a decision as to whether to purchase the Origo Tokens. IMPORTANT NOTICE This Whitepaper in current form is being circulated for general information and to invite investor feedback only on the Origo platform as presently conceived, and is subject to review and revision by the directors of the Token Issuer and/or the Project Company, the advisers, and/or legal advisers of the Token Issuer and/or the Project Company. Please do not replicate or distribute any part of this Whitepaper without this note in accompaniment. No part of this Whitepaper is intended to create legal relations between a recipient of this Whitepaper or to be legally binding or enforceable by such recipient against the Token Issuer and/or the Project Company. An updated version of this Whitepaper may be published on a date to be determined and announced by the Token Issuer and/or the Project Company in due course. PLEASE READ THIS SECTION AND THE FOLLOWING SECTIONS ENTITLED DISCLAIMER OF LIABILITY, NO REPRESENTATIONS AND WARRANTIES, REPRE- SENTATIONS AND WARRANTIES BY YOU, CAUTIONARY NOTE ON FORWARD- LOOKING STATEMENTS, THIRD PARTY INFORMATION AND NO CONSENT OF OTHER PERSONS, TERMS USED, NO ADVICE, NO FURTHER INFORMATION OR UP DATE, RESTRICTIONS ON DISTRIBUTION AND DISSEMINATION, NO OFFER OF INVESTMENT OR REGISTRATION AND RISKS AND UNCERTAINTIES CAREFULLY. IF YOU ARE IN ANY DOUBT AS TO THE ACTION YOU SHOULD TAKE, YOU SHOULD CONSULT YOUR LEGAL, FINANCIAL, TAX OR OTHER PROFESSIONAL ADVISOR(S). The Origo Tokens are not intended to constitute securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment in any jurisdiction. This Whitepaper does not constitute a prospectus or offer document of any sort and is not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction.

LEGAL DISCLAIMER 41 This Whitepaper does not constitute or form part of any opinion or any advice to acquire, sell, or any solicitation of any offer by the Project Company or the Token Issuer to acquire any Origo Tokens nor shall it or any part of it nor the fact of its presentation form the basis of, or be relied upon in connection with, any contract or investment decision. The proceeds from the sale of the Origo Tokens will be deployed to support ongoing development and growth of the Origo platform, business development, partnerships and community support activities. No person is bound to enter into any contract or binding legal commitment in relation to the acquisition of Origo Tokens and no cryptocurrency or other form of payment is to be accepted on the basis of this Whitepaper. Any agreement as between the Token Issuer and you as a participant in the Token Sale, and in relation to any purchase of Origo Tokens, is to be governed by only a separate document setting out the terms and conditions (the "Token Sale Terms") of such agreement. In the event of any inconsistencies between the Token Sale Terms and this Whitepaper, the former shall prevail. PLEASE NOTE THAT THE TOKEN ISSUER WILL NOT OFFER OR SELL TO YOU, AND YOU ARE NOT ELIGIBLE TO PURCHASE ANY Origo Tokens IN THE TOKEN SALE IF: (A) YOU ARE LOCATED IN THE PEOPLE'S REPUBLIC OF CHINA OR IF YOU ARE A CITIZEN OR RESIDENT (TAX OR OTHERWISE) OF, OR DOMI- CILED IN, THE PEOPLE'S REPUBLIC OF CHINA; (B) YOU ARE LOCATED IN THE UNITED STATES OF AMERICA OR IF YOU ARE A CITIZEN, RESIDENT (TAX OR OTHERWISE) OR GREEN CARD HOLDER OF, OR DOMICILED IN, THE UNITED STATES OF AMERICA, UNLESS YOU ARE A U.S. QUALIFIED PERSON; OR (C) SUCH TOKEN SALE IS PROHIBITED, RESTRICTED OR UNAUTHORIZED IN ANY FORM OR MANNER WHETHER IN FULL OR IN PART UNDER THE LAWS, REG- ULATORY REQUIREMENTS OR RULES IN THE JURISDICTION IN WHICH YOU ARE LOCATED, AT THE TIME OF YOUR INTENDED PURCHASE OR PURCHASE OF THE Origo Tokens IN THE TOKEN SALE. No regulatory authority has examined or approved of any of the information set out in this Whitepaper. No such action has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of this Whitepaper does not imply that the applicable laws, regulatory requirements or rules have been complied with.

LEGAL DISCLAIMER 42 There are risks and uncertainties associated with the Project Company and the Token Issuer and their business and operations, the Origo Tokens, the Token Sale, and the Origo platform. Please refer to the section entitled Risks and Disclosures set out at the end of this Whitepaper. This Whitepaper, any part thereof and any copy thereof must not be taken or transmitted to any country where distribution or dissemination of this Whitepaper is prohibited or restricted. No part of this Whitepaper is to be reproduced, distributed or disseminated with- out including this section and the following sections entitled "Disclaimer of Liability", "No Representations and Warranties", "Representations and Warranties By You", "Cau- tionary Note On Forward-Looking Statements", "Third Party Information and No Consent of Other Persons", "Terms Used", "No Advice", "No Further Information or Update", "Restrictions On Distribution and Dissemination", "No Offer of Investment Or Registration" and "Risks and Uncertainties". DISCLAIMER OF LIABILITY To the maximum extent permitted by the applicable laws, regulations and rules, the Project Company and/or the Token Issuer shall not be liable for any indirect, special, incidental, consequential or other losses of any kind, in tort, contract or otherwise (including but not limited to loss of revenue, income or profits, and loss of use or data), arising out of or in connection with any acceptance of or reliance on this Whitepaper or any part thereof by you. NO REPRESENTATIONS AND WARRANTIES The Project Company and the Token Issuer do not make or purport to make, and hereby disclaim, any representation, warranty or undertaking in any form whatsoever to any entity or person, including any representation, warranty or undertaking in relation to the truth, accuracy and completeness of any of the information set out in this Whitepaper.

LEGAL DISCLAIMER 43 REPRESENTATIONS AND WARRANTIES BY YOU By accessing and/or accepting possession of any information in this Whitepaper or such part thereof (as the case may be), you represent and warrant to the Project Company and the Token Issuer as follows: (a) you agree and acknowledge that the Origo Tokens do not constitute securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment in any jurisdiction; (b) you are not: • (i) located in the People's Republic of China or a citizen or resident (tax or other- wise) of, or domiciled in, the People's Republic of China; • (ii) located in the United States of America or a citizen, resident (tax or otherwise) or green card holder of, or domiciled in, the United States of America, unless you are a U.S. Qualified Person (as defined herein); OR • (iii) located in a jurisdiction where the Token Sale is prohibited, restricted or unauthorized in any form or manner whether in full or in part under the laws, regulatory requirements or rules in such jurisdiction; (c) if you are located in the United States of America or a citizen, resident(tax or otherwise)or green card holder of, or domiciled in, the United States of America, you are a U.S. Qualified Person, being a person (being either an individual or legal entity or a person, including without limitation a governmental authority) who is an Accredited Investor as defined in Rule 501(a) of Regulation D under the U.S. Securities Act of 1933, as may be modified, amended or supplemented from time to time; (d) you agree and acknowledge that this Whitepaper does not constitute a prospec- tus or offer document of any sort and is not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment in any jurisdiction, or a solicitation for any form of invest- ment, and you are not bound to enter into any contract or binding legal commitment and no cryptocurrency or other form of payment is to be accepted on the basis of this Whitepaper; (e) you acknowledge and understand that no Origo Tokens should be construed, interpreted, classified or treated as enabling, or according any opportunity to, token

LEGAL DISCLAIMER 44 holders to participate in or receive profits, income, or other payments or returns arising from or in connection with the Origo Tokens or the proceeds of the Token Sale, or to receive sums paid out of such profits, income, or other payments or returns; (f) you agree and acknowledge that no regulatory authority has examined or approved of the information set out in this Whitepaper, no action has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction and the publication, distribution or dissemination of this Whitepaper to you does not imply that the applicable laws, regulatory requirements or rules have been complied with; (g) you agree and acknowledge that this Whitepaper, the undertaking and/or the completion of the Token Sale, or future trading of Origo Tokens on any cryptocurrency exchange, shall not be construed, interpreted or deemed by you as an indication of the merits of the Project Company, the Token Issuer, the Origo Tokens, the Token Sale, and the Origo platform; (h) the distribution or dissemination of this Whitepaper, any part thereof or any copy thereof, or acceptance of the same by you, is not prohibited or restricted by the applicable laws, regulations or rules in your jurisdiction, and where any restrictions in relation to possession are applicable, you have observed and complied with all such restrictions at your own expense and without liability to the Project Company and/or the Token Issuer; (i) you agree and acknowledge that in the case where you wish to acquire any Origo Tokens, Origo Tokens are not to be construed, interpreted, classified or treated as • (i) any kind of currency other than cryptocurrency; • (ii) debentures, stocks or shares issued by any person or entity; • (iii) rights, options or derivatives in respect of such debentures, stocks or shares; • (iv) rights under a contract for differences or under any other contract the purpose or pretended purpose of which is to secure a profit or avoid a loss; • (v) units in a collective investment scheme; • (vi) units in a business trust; • (vii) derivatives of units in a business trust; or • (viii) any form of investment;

LEGAL DISCLAIMER 45 (j) you are legally permitted to participate in the Token Sale and all actions contem- plated or associated with such participation, including the holding and use of Origo Tokens; (k) the amounts that you use to acquire the Origo Tokens were not and are not di- rectly or indirectly derived from any activities that contravene the laws and regulations of any jurisdiction, including anti-money laundering laws and regulations; (l) if you are a natural person, you are of sufficient age and capacity under the applicable laws of the jurisdiction in which you reside and the jurisdiction of which you are a citizen to participate in the Token Sale; (m) you are not obtaining or using Origo Tokens for any illegal purpose; (n) you have a basic degree of understanding of the operation, functionality, usage, storage, transmission mechanisms and other material characteristics of cryptocurren- cies, blockchain-based software systems, cryptocurrency wallets or other related token storage mechanisms, blockchain technology, and smart contract technology; (o) you are fully aware and understand that in the case where you wish to purchase any OrigoTokens, there are risks associated with the Project Company and the Token Issuer and their business and operations, Origo Tokens, the Token Sale, and the Origo platform; (p) you bear the sole responsibility to determine what tax implications a purchase of Origo Tokens may have for you and agree not to hold the Project Company, the Token Issuer and/or any other person involved in the Token Sale liable for any tax liability associated with or arising therefrom; (q) you agree and acknowledge that the Project Company and the Token Issuer are not liable for any direct, indirect, special, incidental, consequential or other losses of any kind, in tort, contract or otherwise (including but not limited to loss of revenue, income or profits, and loss of use or data), arising out of or in connection with any acceptance of or reliance on this Whitepaper or any part thereof by you; (r) you waive the right to participate in a class action lawsuit or a class wide arbitration against the Project Company, the Token Issuer and/or any person involved in the Token Sale and/or with the creation and distribution of Origo Tokens; and (s) all of the above representations and warranties are true, complete, accurate and non-misleading from the time of your access to and/or acceptance of possession this

LEGAL DISCLAIMER 46 Whitepaper or such part thereof (as the case may be). CAUTIONARY NOTE ON FORWARD-LOOKING STATEMENTS All statements contained in this Whitepaper, statements made in press releases or in any place accessible by the public and oral statements that may be made by the Project Company or its directors, executive officers or employees acting on be- half of the Project Company and/or the Token Issuer (as the case may be), that are not statements of historical fact, constitute "forward-looking statements". Some of these statements can be identified by forward-looking terms such as "aim", "target", "anticipate", "believe", "could", "estimate", "expect", "if", "intend", "may", "plan", "possi- ble", "probable", "project", "should", "would", "will" or other similar terms. However, these terms are not the exclusive means of identifying forward-looking statements. All statements regarding the Project Company and/or the Token Issuer's business strategies, plans and prospects and the future prospects of the industry which the Project Company and/or the Token Issuer is in are forward-looking statements. These forward-looking statements, including but not limited to statements as to the Project Company and/or the Token Issuer's prospects, future plans, other expected industry trends and other matters discussed in this Whitepaper regarding the Project Company and/or the Token Issuer are matters that are not historical facts, but only predictions. These forward-looking statements involve known and unknown risks, uncertainties and other factors that may cause the actual future results, performance or achievements of the Project Company and/or the Token Issuer to be materially different from any future results, performance or achievements expected, expressed or implied by such forward-looking statements. These factors include, amongst others: • (a) changes in political, social, economic and stock or cryptocurrency market conditions, and the regulatory environment in the countries in which the Project Company and/or the Token Issuer conduct their business and operations; • (b) the risk that the Project Company may be unable to execute or implement its business strategies and future plans; • (c) changes in interest rates and exchange rates of fiat currencies and cryptocur- rencies;

LEGAL DISCLAIMER 47 • (d) changes in the anticipated growth strategies and expected internal growth of the Project Company and the Origo platform; • (e) changes in the availability and fees payable to the Project Company in connec- tion with its businesses and operations or in the Origo platform; • (f) changes in the availability and salaries of employees who are required by the Project Company and/or the Token Issuer to operate their business and operations; • (g) changes in preferences of users of the Origo platform; • (h) changes in competitive conditions under which the Project Company operates, and the ability of the Project Company to compete under such conditions; • (i) changes in the future capital needs of the Project Company and the availability of financing and capital to fund such needs; • (j) war or acts of international or domestic terrorism; • (k) occurrences of catastrophic events, natural disasters and acts of God that affect the businesses and/or operations of the Project Company and/or the Token Issuer; • (l) other factors beyond the control of the Project Company and/or the Token Issuer; and • (m) any risk and uncertainties associated with the Project Company and the Token Issuer and their business and operations, the Origo Tokens, the Token Sale, and the Origo platform. All forward-looking statements made by or attributable to the Project Company, the Token Issuer and/or persons acting on behalf of the Project Company and/or the Token Issuer are expressly qualified in their entirety by such factors. Given that risks and uncertainties that may cause the actual future results, performance or achievements of the Project Company and/or the Token Issuer to be materially different from that expected, expressed or implied by the forward-looking statements in this Whitepaper, undue reliance must not be placed on these statements. These forward-looking statements are applicable only as of the date of this Whitepaper. None of the Project Company, the Token Issuer or any other person represents, warrants, and/or undertakes that the actual future results, performance or achieve-

LEGAL DISCLAIMER 48 ments of the Project Company and/or the Token Issuer will be as discussed in those forward-looking statements. The actual results, performance or achievements of the Project Company and/or the Token Issuer may differ materially from those anticipated in these forward-looking statements. Nothing contained in this Whitepaper is or may be relied upon as a promise, representation or undertaking as to the future performance or policies of the Project Company and/or the Token Issuer. Further, the Project Company and the Token Issuer disclaim any responsibility to update any of those forward-looking statements or publicly announce any revisions to those forward-looking statements to reflect future developments, events or circum- stances, even if new information becomes available or other events occur in the future. THIRD PARTY INFORMATION AND NO CONSENT OF OTHER PERSONS This Whitepaper includes information obtained from various third-party sources ("Third Party Information"). None of the publishers of Third Party Information has consented to the inclusion of Third Party Information in this Whitepaper and is there- fore not liable for Third Party Information. While reasonable action has been taken to ensure that Third Party Information has been included in their proper form and con- text, neither the Project Company and the Token Issuer nor their respective directors, executive officers, and employees acting on its behalf, has independently verified the accuracy, reliability, completeness of the contents, or ascertained any applicable under- lying assumption, of the relevant Third-Party Information. Consequently, neither the Project Company and the Token Issuer nor their respective directors, executive officers and employees acting on their behalf makes any representation or warranty as to the accuracy, reliability or completeness of such information and shall not be obliged to provide any updates on the same. TERMS USED To facilitate a better understanding of the Origo Tokens being the subject of the sale conducted by the Token Issuer, and the business and operations of the Project Company and the Token Issuer, certain technical terms and abbreviations, as well

LEGAL DISCLAIMER 49 as, in certain instances, their descriptions, have been used in this Whitepaper. These descriptions and assigned meanings should not be treated as being definitive of their meanings and may not correspond to standard industry meanings or usage. Words importing the singular shall, where applicable, include the plural and vice versa and words importing the masculine gender shall, where applicable, include the feminine and neuter genders and vice versa. References to persons shall include corporations. NO ADVICE No information in this Whitepaper should be considered to be business, legal, financial or tax advice regarding the Project Company, the Token Issuer, the Origo Tokens, the Token Sale, or the Origo platform. You should consult your own legal, financial, tax or other professional adviser regarding the Project Company and the Token Issuer and their business and operations, the Origo Tokens, the Token Sale, and the Origo platform. You should be aware that you may be required to bear the financial risk of any purchase of Origo Tokens for an indefinite period of time. NO FURTHER INFORMATION OR UPDATE No person has been or is authorized to give any information or representation not contained in this Whitepaper in connection with the Project Company and the Token Issuer and their business and operations, the Origo Tokens, the Token Sale, or the Origo blockchain, if given, such information or representation must not be relied upon as having been authorized by or on behalf of the Project Company or the Token Issuer. The Token Sale shall not, under any circumstances, constitute a continuing representation or create any suggestion or implication that there has been no change, or development reasonably likely to involve a material change in the affairs, conditions and prospects of the Project Company and/or the Token Issuer or in any statement of fact or information contained in this Whitepaper since the date hereof. RESTRICTIONS ON DISTRIBUTION AND DISSEMINATION

LEGAL DISCLAIMER 50 The distribution or dissemination of this Whitepaper or any part thereof may be prohibited or restricted by the laws, regulatory requirements, and rules of any jurisdiction. In the case where any restriction applies, you are to inform yourself about, and to observe, any restrictions which are applicable to your possession of this Whitepaper or such part thereof (as the case may be) at your own expense and without liability to the Project Company and the Token Issuer. Persons to whom a copy of this Whitepaper has been distributed or disseminated, provided access to or who otherwise have the Whitepaper in their possession shall not circulate it to any other persons, reproduce or otherwise distribute this Whitepaper or any information contained herein for any purpose whatsoever nor permit or cause the same to occur. NO OFFER OF INVESTMENT OR REGISTRATION This Whitepaper does not constitute a prospectus or offer document of any sort and is not intended to constitute an offer of securities of any form, units in a business trust, units in a collective investment scheme or any other form of investment, or a solicitation for any form of investment in any jurisdiction. No person is bound to enter into any contract or binding legal commitment and no cryptocurrency or other form of payment is to be accepted on the basis of this Whitepaper. No regulatory authority has examined or approved of any of the information set out in this Whitepaper. No such action has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of this Whitepaper does not imply that the applicable laws, regulatory requirements or rules have been complied with. RISKS AND UNCERTAINTIES Prospective purchasers of Origo Tokens should carefully consider and evaluate all risks and uncertainties associated with the Project Company and the Token Issuer and their business and operations, the Origo Tokens, the Token Sale, and the Origo platform, all information set out in this Whitepaper and the Token Sale Terms prior to any purchase of the Origo Tokens. If any of such risks and uncertainties develops into

LEGAL DISCLAIMER 51 actual events, the business, financial condition, results of operations and prospects of the Project Company and/or the Token Issuer could be materially and adversely affected. In such cases, you may lose all or part of the value of the Origo Tokens. Please refer to the risk factors set out in the last part of this Whitepaper.

Appendix B. RISK FACTORS RISKS RELATING TO PARTICIPATION IN THE TOKEN SALE Investments in startups such as the Token Issuer and the Project Company involve a high degree of risk. Financial and operating risks confronting startups are significant and Token Is- suer and the Project Company are not immune to these. Startups often experience unexpected problems in the areas of product development, marketing, financing, and general management, among others, which frequently cannot be solved. The Token Issuer and/or the Project Company may be forced to cease operations. It is possible that, due to any number of reasons, including, but not limited to, an unfavorable fluctuation in the value of cryptographic and fiat currencies, the inability by the Token Issuer and/or the Project Company to establish the Origo platform or the Origo Tokens'utility, the failure of commercial relationships, or intellectual property ownership challenges, the Token Issuer and/or the Project Company may no longer be viable to operate and the Token Issuer and/or the Project Company may dissolve or take actions that result in a dissolution of the Token Issuer and/or the Project Company. The tax treatment of the Token Sale Terms, the purchase rights contained therein and the Token Sale is uncertain and there may be adverse tax consequences for purchasers upon certain future events. The tax characterization of the Token Sale Terms and the Origo Tokens is uncertain, and each purchaser must seek its own tax advice in connection with an investment in 52

RISK FACTORS 53 the Origo Tokens. An investment pursuant to the Token Sale Terms and the purchase of Origo Tokens pursuant thereto may result in adverse tax consequences to the purchaser, including withholding taxes, income taxes and tax reporting requirements. Each purchaser should consult with and must rely upon the advice of its own professional tax advisors with respect tax treatment of an investment in the Origo Tokens pursuant to the Token Sale Terms. There is no prior market for Origo Tokens and the Token Sale may not result in an active or liquid market for the Tokens Prior to the Token Sale, there has been no public market for the Origo Tokens. In the event that the Origo Tokens are traded on a cryptocurrency exchange, there is no assurance that an active or liquid trading market for the Origo Tokens will develop or if developed, be sustained after the Origo Tokens have been made available for trading on such cryptocurrency exchange. There is also no assurance that the market price of the Origo Tokens will not decline below the consideration at which the purchaser acquired the Origo Tokens at. Such purchase consideration may not be indicative of the market price of the Origo Tokens after they have been made available for trading on a cryptocurrency exchange. A Origo Token is not a currency issued by any central bank or national, supranational or quasi-national organisation, nor is it backed by any hard assets or other credit. The Token Issuer is not responsible for nor does it pursue the circulation and trading of Origo Tokens on the market. Trading of Origo Tokens merely depends on the consensus on its value between the relevant market participants, and no one is obliged to purchase any Origo Token from any holder of the Origo Token, nor does anyone guarantee the liquidity or market price of Origo Tokens to any extent at any time. Accordingly, the Token Issuer cannot ensure that there will be any demand or market for Origo Tokens, or that the purchase consideration is indicative of the market price of Origo Tokens after they have been made available for trading on a cryptocurrency exchange. Future sales of the Origo Tokens could materially and adversely affect the market price of Origo Tokens Any future sale of the Origo Tokens (which were not available for sale in the Token Sale) would increase the supply of Origo Tokens in the market and this may result in a downward price pressure on the Origo Token. The sale or distribution of a significant number of Origo Tokens outside of the Token Sale, or the perception that such further

RISK FACTORS 54 sales or issuance may occur, could adversely affect the trading price of the Origo Tokens. Negative publicity may materially and adversely affect the price of the Origo Tokens Negative publicity involving (a) the Token Issuer and/or the Project Company; (b) the Origo plat- form; (c) the Origo Tokens; or (d) any of the key personnel of the Token Issuer and/or the Project Company, may materially and adversely affect the market perception or market price of the Origo Tokens, whether or not such publicity is justified. There is no assurance of any success of Origo platform The value of, and demand for, the Origo Tokens hinges heavily on the performance of the Origo platform. There is no assurance that the Origo platform will gain traction after its launch and achieve any commercial success. The Origo platform has not been fully developed, finalized and integrated and is subject to further changes, updates and adjustments prior to its launch. Such changes may result in unexpected and unforeseen effects on its projected appeal to users, and hence impact its success. While the Token Issuer has made every effort to provide a realistic estimate, there is also no assurance that the cryptocurrencies raised in the Token Sale will be sufficient for the development and integration of the Origo platform. For the foregoing or any other reason, the development and integration of the Origo platform may not be completed and there is no assurance that it will be launched at all. As such, distributed Origo Tokens may hold little worth or value, and this would impact its trading price. The trading price of the Origo Tokens may fluctuate following the Token Sale The prices of cryptographic tokens in general tend to be relatively volatile, and can fluctuate significantly over short periods of time. The demand for, and corresponding the market price of, the Origo Tokens may fluctuate significantly and rapidly in response to, among others, the following factors, some of which are beyond the control of the Token Issuer and/or the Project Company: • (a) new technical innovations;

RISK FACTORS 55 • (b) analysts'speculations, recommendations, perceptions or estimates of the Origo Token's market price or the Token Issuer's and/or the Project Company's financial and business performance; • (c) changes in market valuations and token prices of entities with operations similar to that of the Token Issuer and/or the Project Company that may be made available for sale and purchase on the same cryptocurrency exchanges as the Origo Tokens; • (d) announcements by the Token Issuer and/or the Project Company of significant events, for example partnerships, sponsorships, new product developments; • (d) fluctuations in market prices and trading volume of cryptocurrencies on cryptocurrency exchanges; • (e) additions or departures of key personnel of the Token Issuer and/or the Project Company; • (f) success or failure of the management of the Token Issuer and/or the Project Company in implementing business and growth strategies; and • (g) changes in conditions affecting the blockchain or financial technology industry, the general economic conditions or market sentiments, or other events or factors. RISKS RELATING TO THE WALLET The loss or compromise of information relating to your Wallet (as defined below) may affect your access and possession of the Origo Tokens For purposes of receipt of your Origo Tokens, you are to establish and maintain access to a cryptocurrency wallet (Wallet). Your access to the Origo Tokens in the Wallet depends on, among other things, the safeguards to the information to such Wallet, including but not limited to the user account information, address, private key and password. In the event that any of the foregoing is lost or compromised, your access to the Wallet may be curtailed and thereby adversely affecting your access and possession to the Origo Tokens, including such Origo Tokens being unrecoverable and permanently lost.

RISK FACTORS 56 The Wallet or Wallet service provider may not be technically compatible with the Origo Tokens The Wallet or Wallet service provider may not be technically compatible with the Origo Tokens which may result in the delivery of Origo Tokens being unsuccessful or affect your access to such Origo Tokens. RISKS RELATING TO THE TOKEN ISSUER AND THE PROJECT COMPANY The Origo platform is intended to be developed, operated and maintained by the Token issuer and/or the Project Company. Any events or circumstances which adversely affect the Token Issuer and/or the Project Company may have a correspond- ing adverse effect on the Token Issuer and/or the Project Company if such events or circumstances affect the Token Issuer's and/or the Project Company's ability to maintain the Origo platform. This would correspondingly have an impact the trading price of the Origo Tokens. The Token Issuer and/or the Project Company may be materially and adversely affected if they fail to effectively manage its operations as their business develops and evolves, which would have a direct impact on their ability to maintain the Origo platform and consequently the trading price of the Origo Tokens. The financial technology and cryptocurrency industries and the markets in which the Token Issuer and the Project Company compete have grown rapidly and continue to grow rapidly, and continue to evolve in response to new technological advances, changing business models and other factors. As a result of this constantly changing environment, the Token Issuer and/or the Project Company may face operational difficulties in adjusting to the changes, and the sustainability of the Token Issuer and the Project Company will depend on their ability to manage their respective operations, adapt to technological advances and market trends and ensure that they hire qualified and competent employees, and provide proper training for their personnel. As their respective business evolves, the Token Issuer and the Project Company must also expand and adapt its operational infrastructure. The Token Issuer's and the Project Company's respective businesses rely on blockchain-based software systems, cryptocurrency wallets or other related token storage mechanisms, blockchain technol- ogy and smart contract technology, and to manage technical support infrastructure

RISK FACTORS 57 for the Origo platform effectively, the Token Issuer and the Project Company will need to continue to upgrade and improve their data systems and other operational systems, procedures and controls. These upgrades and improvements will require a dedication of resources, are likely to be complex and increasingly rely on hosted computer services from third parties that the Token Issuer and/or the Project Com- pany do not control. If the Token Issuer and/or the Project Company are unable to adapt their respective systems and organization in a timely, efficient and cost-effective manner to accommodate changing circumstances, its business, financial condition and results of operations may be adversely affected. If the third parties whom the Token Issuer and/or the Project Company rely on are subject to a security breach or otherwise suffer disruptions that impact the respective services the Token Issuer and/or the Project Company utilize, the integrity and availability of their respective internal information could be compromised, which may consequently cause the loss of confidential or proprietary information, and economic loss. The loss of financial, labor or other resources, and any other adverse effect on the Token Issuer's and/or the Project Company's respective business, financial condition and operations, would have a direct adverse effect on the Token Issuer's and the Project Company's ability to maintain the Origo platform. As the Origo platform is the main product to which the Origo Tokens relate, this may adversely impact the trading price of the Origo Tokens. The Token Issuer and/or the Project Company may experience system failures, unplanned interruptions in its network or services, hardware or software defects, security breaches or other causes that could adversely affect the Token Issuer's and/or the Project Company's infrastructure network, and/or the Origo platform The Token Issuer and the Project Company are unable to anticipate when there would be occurrences of hacks, cyber-attacks, mining attacks (including but not limited to double-spend attacks, majority mining power attacks and selfish-mining attacks), distributed denials of service or errors, vulnerabilities or defects in the Origo platform, the Origo Tokens, the Wallet or any technology (including but not limited to smart contract technology) on which the Token Issuer and/or the Project Company, the Origo platform, the Origo Tokens and the Wallet relies or on the Ethereum blockchain or any other blockchain. Such events may include, for example, flaws in programming or source code leading to exploitation or abuse thereof. The Token Issuer and/or the Project Company may not be able to detect such hacks, mining attacks (including but not limited to double-spend attacks, majority mining power attacks and selfish-mining attacks), cyber-attacks, distributed denials of service errors vulnerabilities or defects

RISK FACTORS 58 in a timely manner, and may not have sufficient resources to efficiently cope with multiple service incidents happening simultaneously or in rapid succession. The Token Issuer's and/or the Project Company's respective network or services, which would include the Origo platform, could be disrupted by numerous events, including natural disasters, equipment breakdown, network connectivity downtime, power losses, or even intentional disruptions of their respective services, such as disruptions caused by software viruses or attacks by unauthorized users, some of which are beyond the Token Issuer's and/or the Project Company's control. Although the Token Issuer and the Project Company will be taking steps against malicious attacks on their respective appliances or infrastructure, which are critical for the maintenance of the Origo platform and their respective other services, there can be no assurance that cyber-attacks, such as distributed denials of service, will not be attempted in the future, and that any of the Token Issuer's and the Project Company's intended enhanced security measures will be effective. The Token Issuer and the Project Company may also be prone to attacks on their respective infrastructure intended to steal information about their respective technology, financial data or user information or take other actions that would be damaging to the Token Issuer, the Project Company and users of the Origo platform. Any significant breach of the Token Issuer's and/or the Project Company's intended security measures or other disruptions resulting in a compromise of the usability, stability and security of the Token Issuer's and/or the Project Company's network or services (including the Origo platform) may adversely affect the trading price of the Origo Tokens. The Token Issuer and the Project Company are dependent in part on the location and data centre facilities of third parties The Token Issuer's and the Project Company's infrastructure network will be in part established through servers that which they respectively own and house at the location facilities of third parties, and servers that they respectively rent at data center facilities of third parties. If the Token Issuer and/or the Project Company are unable to renew their respective data facility lease on commercially reasonable terms or at all, the Token Issuer and/or the Project Company may be required to transfer their respective servers to a new data center facility, and may incur significant costs and possible service interruption in connection with the relocation. These facilities are also vulnerable to damage or interruption from, among others, natural disasters, arson, terrorist attacks, power losses, and telecommunication failures. Additionally, the third party providers of such facilities may suffer a breach of security as a result of

RISK FACTORS 59 third party action, employee error, malfeasance or otherwise and a third party may obtain unauthorized access to the data in such servers. As techniques used to obtain unauthorized access to, or to sabotage systems change frequently and generally are not recognized until launched against a target, the Token Issuer, the Project Company and the providers of such facilities may be unable to anticipate these techniques or to implement adequate preventive measures. Any such security breaches or damages which occur which impact upon the Token Issuer's and/or the Project Company's infrastructure network and/or the Origo platform may adversely impact the price of the Origo Tokens. General global market and economic conditions may have an adverse impact on the Token Issuer's and/or the Project Company's operating performance, results of operations and cash flows The Token Issuer and/or the Project Company could be affected by general global economic and market conditions. Challenging economic conditions worldwide have from time to time, contributed, and may continue to contribute, to slowdowns in the information technology industry at large. Weakness in the economy could have a negative effect on the Token Issuer's and/or the Project Company's respective business, operations and financial condition, including decreases in revenue and operating cash flows. Additionally, in a down-cycle economic environment, the Token Issuer and/or the Project Company may experience the negative effects of increased competitive pricing pressure and a slowdown in commerce and usage of the Origo platform. Suppliers on which the Token Issuer and/or the Project Company rely for servers, bandwidth, location and other services could also be negatively impacted by economic conditions that, in turn, could have a negative impact on the Token Issuer's and/or the Project Company's respective operations or expenses. There can be no assurance, therefore, that current economic conditions or worsening economic conditions or a prolonged or recurring recession will not have a significant adverse impact on the Token Issuer's and/or the Project Company's respective business, financial condition and results of operations and hence the Origo platform, which would correspondingly impact the trading price of the Origo Tokens. The Token Issuer, the Project Company and/or the Origo Tokens may be affected by newly implemented regulations Cryptocurrency trading is generally unregulated worldwide, but numerous reg- ulatory authorities across jurisdictions have been outspoken about considering the

RISK FACTORS 60 implementation of regulatory regimes which govern cryptocurrency or cryptocurrency markets. The Token Issuer, the Project Company and/or the Origo Tokens may be affected by newly implemented regulations relating to cryptocurrencies or cryptocur- rency markets, including having to take measures to comply with such regulations, or having to deal with queries, notices, requests or enforcement actions by regulatory authorities, which may come at a substantial cost and may also require substantial modifications to the Origo Tokens and/or the Origo platform. This may impact the appeal of the Origo Tokens and/or the Origo platform for users and result in decreased usage of the Origo Tokens and/or the Origo platform. Further, should the costs (finan- cial or otherwise) of complying with such newly implemented regulations exceed a certain threshold, maintaining the Origo Tokens and/or the Origo platform may no longer be commercially viable and the Token Issuer and/or the Project Company may opt to discontinue the Origo Tokens and/or the Origo platform. Further, it is difficult to predict how or whether government or regulatory authori- ties may implement any changes to laws and regulations affecting distributed ledger technology and its applications, including the Origo Tokens and the Origo platform. The Token Issuer and/or the Project Company may also have to cease their respective operations in a jurisdiction that makes it illegal to operate in such jurisdiction, or make it commercially unviable or undesirable to obtain the necessary regulatory approval(s) to operate in such jurisdiction. In scenarios such as the foregoing, the trading price of Origo Tokens will be adversely affected or Origo Tokens may cease to be traded. The regulatory regime governing the blockchain technologies, cryptocurrencies, tokens and token offerings such as Token Sale, the Origo platform and the Origo Tokens is uncertain, and regulations or policies may materially adversely affect the development of the Origo platform and the utility of the Origo Tokens Regulation of tokens (including the Origo Tokens) and token offerings such as the Token Sale, cryptocurrencies, blockchain technologies, and cryptocurrency exchanges currently is undeveloped and likely to rapidly evolve, varies significantly among inter- national, federal, state and local jurisdictions and is subject to significant uncertainty. Various legislative and executive bodies in Singapore and other countries may in the future, adopt laws, regulations, guidance, or other actions, which may severely impact the development and growth of the Origo platform and the adoption and utility of the Origo Tokens. Failure by the Token Issuer, the Project Company or users of the Origo platform to comply with any laws, rules and regulations, some of which may not exist yet or are subject to interpretation and may be subject to change, could result

RISK FACTORS 61 in a variety of adverse consequences, including civil penalties and fines. Blockchain networks also face an uncertain regulatory landscape in many foreign jurisdictions such as the European Union, China, South Korea and Russia. Various foreign jurisdic- tions may, in the near future, adopt laws, regulations or directives that affect the Origo platform. Such laws, regulations or directives may directly and negatively impact the Token Issuer's and/or the Project Company's respective business. The effect of any future regulatory change is impossible to predict, but such change could be substantial and materially adverse to the development and growth of the Origo platform and the adoption and utility of the Tokens. New or changing laws and regulations or interpretations of existing laws and regulations may materially and adversely impact the value of the currency in which the Origo Tokens may be sold, the value of the distributions that may be made by the Token Issuer and/or the Project Company, the liquidity of the Origo Tokens, the ability to access marketplaces or exchanges on which to trade the Origo Tokens, and the structure, rights and transferability of Origo Tokens. Origo Token holders will have no control on the Token Issuer or the Project Company The holders of Origo Tokens are not and will not be entitled, to vote or receive dividends or be deemed the holder of capital stock of the Token Issuer or the Project Company for any purpose, nor will anything be construed to confer on the purchasers any of the rights of a stockholder of the Token Issuer or the Project Company or any right to vote for the election of directors or upon any matter submitted to stockholders at any meeting thereof, or to give or withhold consent to any corporate action or to receive notice of meetings, or to receive subscription rights or otherwise. Purchasers may lack information for monitoring their investment the purchasers of Origo Tokens may not be able to obtain all information it would want regarding the Token Issuer, the Project Company, the Origo Tokens, or the Origo platform, on a timely basis or at all. It is possible that purchasers may not be aware on a timely basis of material adverse changes that have occurred. While the Token Issuer has made efforts to use open-source development for Origo Tokens, this information may be highly technical by nature. As a result of these difficulties, as well as other uncertainties, Purchasers may not have accurate or accessible information about the Origo platform. There may be unanticipated risks arising from the Origo Tokens Cryptographic tokens such as the Origo Tokens are a relatively new and dynamic technology. In addition to the risks included in this section, there are other risks

RISK FACTORS 62 associated with the purchase, holding and use of the Origo Tokens, including those that the Token Issuer and the Project Company cannot anticipate. Such risks may further materialize as unanticipated variations or combinations of the risks discussed in this document.