Cocos-BCX Whitepaper

Friday, November 20, 2020
Download document
Save for later
Add to list
Whitepaper.io is a project of OpenBook

Project Cocos-BCX Cocos BlockChain Expedition A Development and Operating Environment for Decentralized Gaming Applications and Digital Assets Technical Whitepaper 1.1.3 0

Project Cocos-BCX ersion: 1.1.3 Our Mission To Assetize the Content of the Digital World, Building A Consistent Value System between the Producers and the Consumers CHEN Haozhi Founder of Cocos BlockChain Expedition 1

Project Cocos-BCX Abstr act Pr oject Objectives In this WhitePaper, we introduce the concepts and implementations of Cocos BlockChain Expedition (“Cocos-BCX” or the “Platform”), a platform for the development, operation and management of decentralized applications (“DApps”) and the circulation of in-app assets (“dAssets”) on blockchain. The Platform includes: (1) A development framework that supports multiple operating systems and blockchains. (2) A data-driven IDE for dApps that is fully scripted and component-based. And (3) A blockchain system and essential functional components for high performance applications based on the improved Graphene technology framework (“CocosChain”). Cocos-BCX enables developers to program, debug and release blockchain-based dApps and hybrid applications. Meanwhile, the platform integrates a blockchain-based distributed ledger system, crypto wallet system and digital assets circulation platform, allowing the permanent off-chain storage and cross-chain use of in-app assets. Phase-I Objectives It is from the needs of developers and users in game industry that we started to design the initial version of the project, since the game is one of the earliest and largest field for blockchain application. The technology, products, economic system design and use cases discussed in this whitepaper are based on the application scenario of game. 2

Project Cocos-BCX Table of Contents Abstract.................................................................................................................................................2 Project Objectives........................................................................................................................................... 2 Phase-I Objectives...........................................................................................................................................2 1. Project Background.......................................................................................................................... 5 1.1. Blockchain Ecosystem and Digital Assets Are One of the Economic Development Directions with a Value Base...................................................................................................................................................... 5 1.2. Problems Expected to be Solved by Cocos-BCX.................................................................................... 5 1.3. The Four Stages of Blockchain Gaming.................................................................................................. 7 1.3.1. Fungible Token as a Settlement Measure of In-Game Economy.......................................................................7 1.3.2. Free Exchange of Game Coins and Assets........................................................................................................ 8 1.3.3. Key Game Algorithms Running on Blockchain................................................................................................. 8 1.3.4. The Game as a whole Running on the Blockchain............................................................................................ 9 2. Project Advantages and Technology Optimization........................................................................ 11 2.1. Technical Goal....................................................................................................................................... 11 2.2. Advanced Technical Highlights.............................................................................................................12 2.3. Optimization of “Impossible Triangle”..................................................................................................12 3. Business and Operation.................................................................................................................. 15 3.1. Complete Wallet and Blockchain Explorer............................................................................................15 3.2. Iterative Smart Contract System............................................................................................................ 15 3.3. Multiverse Statement............................................................................................................................. 16 3.4. Cross-World Item “Traveling”...............................................................................................................16 3.5. Smithy Mechanism.................................................................................................................................18 3.6. Nested Props Combination.....................................................................................................................19 3.7. Props Circulation Platform.....................................................................................................................19 3.8. Implementation of Props Circulation Platform...................................................................................... 20 3.9. Enhanced Permission System................................................................................................................ 21 3.9.1. Specified Permission System and On-Chain Operations to Support more Business Segments.......................21 3.9.2. Implementation of New Business Models by Contract and OP....................................................................... 22 3.10. Player Autonomy and Assets Security.................................................................................................24 3.11. Visualized Smart Contract Editor........................................................................................................ 24 4. System Architecture....................................................................................................................... 25 4.1. Integrated Blockchain-interactive Runtime Environment for Games....................................................25 4.1.1. Game Runtime Environment With Multi-System Compatibility...................................................................... 25 4.1.2. Interactive Interfaces of Blockchain................................................................................................................ 26 4.2. Exchange Gateway Supporting the Homogeneous and Non-Homogeneous Assets and Cross-Chain Transactions.................................................................................................................................................. 26 4.2.1. Exchange of Digital Game Assets....................................................................................................................27 4.2.2. Exchange of Non-homogeneous Digital Game Assets.....................................................................................27 4.3. CocosChain: Improvement and Extension to the Existing Blockchain................................................. 28 4.3.1. Improved Data Structure of Non-homogeneous Assets................................................................................... 28 4.3.2. Separately Stored Assets and Contract Data...................................................................................................29 4.3.3. Improved DPoS Consensus Mechanism.......................................................................................................... 30 4.3.4. Security Provided by Modern Cryptography...................................................................................................30 4.3.5. Low Forking Risk.............................................................................................................................................31 3

Project Cocos-BCX 4.3.6. Multi-Chain Interoperability........................................................................................................................... 31 4.3.7. Merges of Multi-Operations to Ensure Atomicity............................................................................................31 4.4. BCX Testnet: High-Performance Blockchain and High-Speed Contract Virtual Machine...................33 4.5. Further Enhancement of the Distributed Ledger System for Blockchain Gaming................................ 34 4.5.1. Light Nodes...................................................................................................................................................... 35 4.5.2. Continual Execution of Smart Contracts......................................................................................................... 36 4.5.3. Session............................................................................................................................................................. 36 4.5.4. Support consensus tasks at the syntax level.....................................................................................................36 4.5.5. Priority of Contract Consensus....................................................................................................................... 37 4.5.6. Minimum Transaction Latency........................................................................................................................ 38 4.5.7. Delegate-Type Transaction Mechanism.......................................................................................................... 39 4.5.8. Implementation of On-Chain Trusted Random Process.................................................................................. 40 4.5.9. On-Chain Trusted Randomness....................................................................................................................... 40 4.5.10. Timer and Heartbeat......................................................................................................................................42 4.5.11. Standardized Non-Homogeneous Assets........................................................................................................42 4.5.12. Design Tools for Established Rules............................................................................................................... 43 4.6. Cheat-proof Transaction Verification Mechanism to Prevent BP/ Developers from Cheating.............43 4.6.1. Dynamic Encryption Transmission..................................................................................................................44 4.6.2. Prevent Custom Nodes from Accessing the Network.......................................................................................44 4.6.3. Concealed Process Variables.......................................................................................................................... 45 4.6.4. Contract Mechanism with Execution Authentication...................................................................................... 46 4.6.5. Internal Trusted Environment for Execution of Sensitive Processes...............................................................46 5. Economic System of The Platform.................................................................................................48 5.1. Substantial Changes Blockchain Brings to Gaming.............................................................................. 48 5.2. Design Principle of Cocos-BCX Economy............................................................................................50 5.3. Basic Use Model of COCOS Digital Assets.......................................................................................... 51 5.3.1. Distribution and Acquisition of COCOS Token...............................................................................................52 5.3.2. Use and Consumption of COCOS Token......................................................................................................... 53 5.4. Allocation of COCOS Token................................................................................................................. 53 6. Strategic Investors.......................................................................................................................... 56 7. Summary.........................................................................................................................................56 4

Project Cocos-BCX 1. Pr oject Backgr ound 1.1. Blockchain Ecosystem and Digital Assets Ar e One of the Economic Development Dir ections with a Value Base Since 2019, discussions on blockchains and digital currencies have gradually expanded from technology to economics, sociology, politics and many other sectors. The public are more concerned about the impact of blockchain on social development and the role of digital currency in world economic activities. Under the circumstances of bottlenecks in global technological progress, rising resource consumption, an aging population, and increased geopolitical conflicts, the government-led approach to productivity in some regions or industries is likely to change. The corresponding monetary system may also change from “government - fiat currency” to “non-government productivity organizers - multiple consensus currency”. We believe that the decentralized social forms based on blockchain technology and economic mechanism will be the outcome of production order transformation in some regions, populations and industries in some period of the future, which is the value base for the blockchain economics and the existence of digital currencies. Compared with traditional physical assets, digital assets are more vital due to the blockchain mechanism. In the digital economy, people are the absolute dominant factor of productivity. While the production, use and distribution of digital assets can form a closed loop on the blockchain, which is more independent of the centralized resource allocator. On the other hand, the decentralized digital content can be maintained in a single or multiple blockchain ecosystems(s), and be publicly and fairly priced, thus becoming a truly “digital asset” with independent property rights, and creating new business models and social values. Among the various types of decentralized applications, game is one of those fields with the most mature development model, highest rate of commercialization, and broadest base of developers and users. In the first phase of this project, our goal is to conduct R&D to solve existing problems in the field of blockchain games. 1.2. Pr oblems Expected to be Solved by Cocos-BCX Our goal is to provide an improved and easy-to-use blockchain gaming infrastructure for game developers, including a visualized development kit and an on-chain ecosystem. Developers can develop blockchain games directly in a graphical way without the need to solve any blockchain technical problems, which greatly lowers the barriers and raises the efficiency. Our aim is to provide game players a just, fair and open game environment with transparent data and clear rules, which is free from item drops caused by behind-the-scenes manipulations and revulsive consumption, enabling players to save their assets in a permanent, secure and decentralized way. 5

Project Cocos-BCX At the same time, we hope to help developers and players ensure a consistent benefit for developers through the economic model of digital assets supported by blockchain technology: To help the developers assetize the contents they produce for sustainable earnings from the use, management and circulation of the content assets, and provide convenient and decentralized channels for game distribution; To help players convert the data generated by the time and energy they spend and items obtained through consumption into assets that can be safely stored, managed and circulated, giving players the rights to commercialize them. 6

Project Cocos-BCX 1.3. The Four Stages of Blockchain Gaming 1.3.1. Fungible Token as a Settlement Measur e of In-Game Economy In the beginning, tokens were used as a way for the settlements of in-game currencies circulated in the blockchain games, represented by the ERC20 homogeneous asset standard of the Ethereum system. The standard is now widely used in blockchain projects. The homogeneous assets of many projects are based on Ethereum’s ERC 20 Standard, which is easy to exchange and more compatible with essential functions available on DApps. The holder of the asset has full control over the asset and tracks the journey of the assets circulated on different platforms through a blockchain explorer for example, including the addresses and amount. The key problems solved by blockchain in this stage includes:  Transparency of the output and circulation of in-game coins;  Cross-game circulation of in-game coins;  Exchange of in-game coins for other cryptocurrencies. Typical projects in this stage: Candy Shooter and Candy game platform Candy Shooter is a STG game on Candy.One platform, similar to “Raiden” released years ago. Users need to pay 100 Candy, the token of the game, each time to start a game. The player controls a small aircraft to shoot all “enemies” without getting shot down by others. By defeating the boss at the end of each level, user can get more Candy tokens as a reward. The game is over when a player clears all the level or his/her shooter crashes. The game points that users obtained in the game, together with other homogeneous assets provided by other sponsors, are then converted into Candy at a certain ratio by the settlement system. These homogeneous assets, including Candy, are accepted by Big. One and other digital assets platforms, and can be applied to respective scenarios. [Figure 1-3-1] Screenshot of Candy Shooter 7

Project Cocos-BCX The digital assets at this stage are homogeneous that reflect only the value of scores or tokens, which are used to settle the game results. 1.3.2. Fr ee Exchange of Game Coins and Assets ERC20 can only be used to release fungible tokens to represent various fungible items. It determines whether an identical/ similar items or quantities can be completely swapped during the process of circulation or use. Therefore, the project asset can only act as an single-valued medium, such as a security, score and digital asset. However, the truth is that any people, thing or item with unique attributes are non-fungible, and their value cannot be measured by a fungible token despite that they can be replaced by any digital assets. Therefore, Ethereum’s improvement proposal (EIP) introduces the Non-Fungible Token Standard ERC-721. The BCX-NHAS-1808 is a non-homogeneous digital asset standard for COCOS applications, which is applied to decentralized distributed ledger network. Non-homogeneous digital assets can be circulated in any platforms, of which the value is determined by the uniqueness and scarcity associated with each asset, such as equipment, props and high-level user accounts. The popular game Cryptokitties was an example of non-homogeneous digital asset standard. In this game, each kitty is an indivisible creature with unique genes rather than a homogeneous currency, and has its own label, price and other unique attributes. That is to say, any special game props or any item with a certain collection value can be matched with an asset to indicate its identity. Non-homogeneous digital assets are unique, inseparable and indivisible to some extent. At this stage, the objects - such as props, equipment and user accounts – are all measured by non- homogeneous digital assets, and all generalized asset circulation is settled in the form of homogeneous and non-homogeneous digital assets, including but not limited to prop transfer, assets circulation and prop drops. Specific game content, such as MOD, can even be issued and circulated as a digital asset. The value carrier with a unified standard provides a basic value system for game content to be circulated on the blockchain, and players can exchange one type of game assets into another through homogeneous and non-homogeneous digital assets. Compared with the first stage, props are recorded as the only non-homogeneous identifiers on the blockchain in this stage. The issuance and transactions of props and tokens are transparent, although production algorithms are still in a black box and fixed. Yet, operation rules are executed off chain. Cocos- BCX has realized all the features in this stage, and is trying to find solutions in the next stage. 1.3.3. Key Game Algor ithms Running on Blockchain In this stage, the basic setting and key algorithms required for on-chain games will be written into blocks to be witnessed in the form of contract or other way that is easy to make public to ensure fairness and transparency. For example, the value logic of the game, including the probability of Gashapon, the enemy setting in the RPG game, loot box drops and card dealing rules, will be written into blockchain to ensure the openness, transparency and immutability of the rules and the fairness of the game, thereby improving user experience and confidence. 8

Project Cocos-BCX This feature effectively relieves the players from the fear of game fraud, improving the confidence of the player group and more participation, which contributes to the construction and development of the community. It takes time to run and witness the contract. Taking the loading of loot box in SLG game as an example, it can be summarized as:  All the loot boxes are generated in the contract at one time upon the loading of the map. In this mode, contract is executed upon the loading of the scene, which brings relatively low pressure on the network. There need no other time-consuming operations in addition to the recording of props obtaining in the running of the contract, thus bringing a faster response and a smoother game experience. However, it lacks flexibility and universality when the item generated is highly derivative to the contextual variables of the scenes.  Contract operated every time a loot box is opened In this mode, contract is executed every time a loot box is opened to calculate the production logic of props in real time. It imposes a heavy load on the blockchain but offers greater flexibility on the item generation and quicker response to the contextual variables of the scenes. At this stage, blockchain games have a lot of rules and data executed on chain, and user growth will lead to a sharp increase in the pressure on the blockchain network. Before any breakthrough, the technology of this stage can only be applied to games with Cool-Down Time. The trade-off between decentralization and performance remains to be the bottleneck before any fundamental technology breakthrough, such as high- performance consensus mechanism and contract virtual machine. Technologies, such as the DAG with low latency, may be a potential breakthrough, but it is still far from the final solution. 1.3.4. The Game as a whole Running on the Blockchain All the contents of a game running on blockchain is the final form of the industry. The game logic codes are executed on blockchain, and the data is carried and stored by decentralized distributed network, under which case, the games themselves become contracts. A trusted and efficient integrated operating environment with lowest latency and light blockchain nodes are necessary for the operation of the game, though there is no final technical solution at this moment in the industry. Cryptokitties is designed to run the game on blockchain. However, both the data interaction and content carrying are greatly limited due to the throughput of the Ethereum network. In the end, it adopts the strategy of “data interacted on chain and game operation off chain”, that is the key game algorithms on blockchain we mentioned above. Cocos-BCX aims to provide a full set of solutions at the next stage, including: 1. A light full node environment for players; 2. Service Stack running in blockchain environment; 3. Game engine as one of the infrastructures of the nodes; 9

Project Cocos-BCX 4. A development/debugging environment with an engine, visualized IDE, and blockchain interoperable interfaces. 5. A trusted engine environment ensured by asynchronous consensus between nodes, which may be differentiated based on the characteristics of key engine function object code. 6. Game code (contract) executed by a trusted virtual machine controlled by the engine; Key numerical computation of the contract executed in a trusted environment separately from the contract. 7. Key process of the contract witnessed by adjacent or related nodes (such as players in the same instance) in consensus. 10

Project Cocos-BCX 2. Pr oject Advantages and Technology Optimization 2.1. Technical Goal Cocos-BCX aims to build a complete runtime environment for multi-system games, providing blockchain game developers with the maximum convenience and improved ecosystem, while bringing a brand-new gaming experience as well as gaming forms that are different from the previous ones to players. Users will enjoy considerable autonomy in the disposal of the game assets, and a fair and open gaming environment. Therefore, Cocos-BCX is designed to deliver the following technical features, including but not limited to: 1. Multi-platform game runtime environment with blockchain interoperable interface; 2. Improved consensus mechanism based on Delegate Proof-of-Stake (DPoS) and delegated witness mode; 3. TestNet with improved data transmission and high-performance virtual machine; 4. A cross-chain exchange gateway supporting both homogeneous and non-homogeneous digital assets 5. BCX-NHAS-1808 non-homogeneous digital asset standard; 6. Enhanced asset permission system; 7. Smart contracts executable across blocks; 8. Atomic transaction operation; 9. Support for consensus tasks at the syntax level; 10. Support for delegated transaction mechanism; 11. Small-scale consensus and random numbers; 12. On-chain trusted random process; 13. Support minimum on chain transaction validation cycles; 14. Smart contracts support to key game functions, such as accurate timer, standby and heartbeat; 15. Transaction verification mechanism to prevent BP/developer from cheating. 11

Project Cocos-BCX Meanwhile, Cocos-BCX provides functions including but not limited to: 1. Disintermediated assets (props) interoperable interfaces; 2. Examples of non-homogeneous assets circulation platform; 3. Player autonomy and the Smithy mechanism; 4. Visualized IDE (game program and contract visual edition); 5. Complete crypto wallet, user account system and block explorer; 6. Iterative smart contract system. Theoretically, the throughput of CocosChain TestNet can reach up to 100,000 tps. We tested 5,100 tps with block intervals of 3 seconds in experimental environment, that is, it takes 3 seconds for the information to be broadcasted to the entire network. The performance will be further improved after the completion of contract-defined partitioned consensus, multi-chain scaling and witness delegation. Key algorithms of most games can be run on blockchain, and “transaction confirmation with lowest latency” technology will further enhance the experience of the asset circulation process. CocosChain TestNet based wallet can be integrated into the asset circulation platform where users can evaluate the value of game coins, items and accounts based on the exchange rate of the game’s digital assets and the main chain’s base currency. Cocos-BCX is directly supported by COCOS Creator, a visual game editor, by which the game produced can be run in the Cocos-BCX blockchain runtime environment. 2.2. Advanced Technical Highlights Cocos-BCX project has a number of technical highlights, including iterative smart contract system, the Smithy mechanism, nested items combination, exchange gateway that support multi-chain and asset riveting, improved DPoS consensus mechanism, visualized contract editor, high-performance network and contract VM, multi-chain connected transaction verification mechanism to prevent BP/developer from cheating, Cocos-BCX economy principle design and an asset circulation platform that supports the circulation of multiple digital assets. The technical features mentioned here are detailed below. Targeting at the pain points of game industry, Cocos-BCX proposes the vision of value uniformity between the producers and consumers of contents in combination with the development opportunities of blockchain technology. Based on the overall technical framework, every technical segment and organization has its own target and logic, on which basis many improved multi-module technical solutions or mechanisms are proposed. 2.3. Optimization of “Impossible Tr iangle” 12

Project Cocos-BCX The “Impossible Triangle” represents three features that are difficult to be balance in blockchain system. Cocos-BCX is also unable to make the best of the three features at the same time, but we have made the “length” of the impossible triangle as short as possible through our design principles. (1) Decentr alization  Improved DPoS mechanism The consensus layer of CocosChain is improved based on the traditional DPoS consensus algorithm. All active witnesses share the same scheduled block generation probability in the witness scheduling algorithm of the DPoS consensus algorithm, which ensures consistent block generation probabilities and rewards for all witnesses;  Low Risk of Forking Cocos-BCX Chain uses DPoS consensus mechanism that involves no miners, effectively lowering the risk of forking caused by the centralization of computing power. A fork may only take place when more than 1/3 of the witnesses disagree to the consensus under DPoS mechanism.  Light Nodes In Cocos-BCX, a light node is essentially an environment with interoperability with the chain. Different from full nodes, a light node do not need to synchronize data of the entire network but necessary contract information and environmental data. Such a design significantly reduces the amount of data to be synchronized and time for synchronization, so that the game software on the blockchain has a feasible actual capacity and time cost. (2) Secur ity Player Autonomy and Asset Security: Due to the openness and transparency of the blockchain network, the information of digital assets obtained by the player in the game can be browsed through blockchain explorer, providing a protection mechanism for the security of the game assets.  Assets operation permission In-game props are owned and can be disposed only by the player, and the destruction of items will be allowed only with user authorization;  Atomization of key operations on-chain Actions such as assets creation/circulation is submitted to the Smithy or the circulation platform. All operations in the process of creation/circulation are regarded as an indivisible atomic transaction.  Scalable multi-step verification In addition to the verification password for blockchain transaction, the game developer will further set a 2-step authenticator and random code verification to further improve the security of the player's assets;  Secured by modern cryptography 13

Project Cocos-BCX Cocos-BCX chain uses ECC (elliptic-curve cryptography) for encrytion to ensure blockchain information security;  Transaction verification mechanism to prevent BP/developer from cheating Cocos-BCX designs a set of transaction execution, message transmission and running mechanisms to prevent BP and developers from cheating;  Iterative smart contract system Cocos-BCX supports logic updates and bug fixes for on-chain smart contract to ensure security and timeliness of the smart contract. (3) Scalability The top-layer is designed to be scalable to build a business ecosystem with an overall solution for the making of decentralized game and the running of game economy, through the combination of game engine, development environment and Cocos-BCX based game chain, hence to connect the global game ecosystem. The key participants of the ecosystem include: developers, users, content creation and the blockchain system. The scalability designed for the top-layer includes: Multi-platform game runtime environment, blockchain interactive interfaces, exchange gateways that support multi-chain and asset riveting, multi-chain connected and optimization and expansion of existing blockchain systems. The design of top-layer scalability brings about a diversified ecosystem and continued possibilities. In addition, it expands the project’s fusion boundary through at least five technologies and solutions including the integrated multi-platform game runtime environment and blockchain interactive interface. 14

Project Cocos-BCX 3. Business and Oper ation 3.1. Complete Wallet and Blockchain Explor er Cocos-BCX provides digital asset wallets to a variety of operating platforms, such as Android, iOS and Windows, ensuring that mainstream users can participate in assets circulation. Users can store game digital assets and ERC20 imported through the exchange gateway in the wallet, making it easier to transfer and purchase game coins on the circulation platform. On the other hand, Cocos-BCX ensures the security of the digital assets stored by the user in the wallet with the financial-level algorithm and KYC authentication. Cocos-BCX wallet is imbedded with a blockchain explorer for users to check on-chain information recorded in each block. Each blockchain system has its own explorer. Cocos-BCX offers a complete blockchain explorer with search and jump functions, for example, when a rare prop asset is generated, relevant data will be recorded on the mainchain. Users may then find relevant transactions information in the blockchain explorer. Cocos-BCX blockchain explorer also supports users to check information of atomic swap. Assets distribution is more transparent on the blockchain explorer with all data recorded on chain, which is authentic and tamper-resistant. 3.2. Iter ative Smar t Contr act System For contract systems represented by Ethereum, the smart contract can’t be modified once released, which makes it difficult to meet the requirements of the game logic update and bug fixes. To solve these problems, we developed an iterative smart contract system. [Figure 3-2-1] Iterative Updates of Smart Contract The system allows authorized users to update the contract with the modified one after the developers release the defined contract on the blockchain. Although the old version still exists (to ensure openness and 15

Project Cocos-BCX fairness), the on-chain address will be overwritten by the new contract data, and the references of multiple- contract application will be updated automatically. 3.3. Multiver se Statement Most items are universal in current game system. In order to reduce repeated design, increase the efficiency of game development and make it more interesting, Cocos-BCX introduces the concept of multiverse. Game assets and props with the same universe can be interoperable. The universe of blockchain games is an identification used to distinguish between story settings and characters/items/rules settings and utility scope. Game items follow unified specification in the universe, where the game assets and items with the same universe can be migrated and circulated in different games under this universe by paying the “migration fee”, that is “traveling” of game props. In Cocos-BCX, the universe defines the application scenarios, circulation rules and registration for the NH assets, as well as the basic information of the universe (universe ID) and the symbol of circulative tokens. Taking TYPE-MOON as an example, the multiverse is unified. Therefore, the system will be updated once new games sharing this universe. Its works include:  Tsukihime, the doujin game;  Kara no Kyoukai, the novel;  Fate/Stay Night, the NO.1 commercial game;  Fan disc Fate/Hollow Ataraxia of Fate/Stay Night;  Melty Blood series, the scenario-based fighting game. The characters, items and plot settings in each work with the same universe are universal, and it's common in the real world that game makers develop various works in the same universe. Cocos-BCX allows game developers to declare a universe at the time of creation. In addition, the universe is allowed to have its own governance committee (and consensus committee), which may further be allowed to have its independent blockchain environment in the future. 3.4. Cr oss-Wor ld Item “Tr aveling” Game assets and props under the same universe are interoperable across different games. For example, the props of game B can be used in game A and game C as shown in Figure 3-4-1 below. 16

Project Cocos-BCX [Figure 3-4-1] Circulation of Game Items under the Same or Similar Universe The game props following the unified rules in the multiverse can be transferred across different games by paying migration fee, which is the “traveling“ of game props. Props ares a non-homogeneous digital asset for blockchain-based games. The “traveling“ of props is the process of applying the asset under the same universe in different games. The modification to the asset by different games is stored in the game's respective zone data. The data of different games is independent of each other under the default setting, and only internal modification to zone data is allowed. [Figure 3-4-2] Examples of On-Chain Game Assets Migrating Across Different Games under the Same Universe 17

Project Cocos-BCX 3.5. Smithy Mechanism The Smithy is a series of accounts with the right to generate props and equipment, and a series of contracts. As one of the core functions of all games, the Smithy can be managed by game makers or by game guilds and designer studios. Players convert game coins and materials into props or purchase items directly in the Smithy. This open and transparent process endows props with uniqueness as other props, which can be retrieved and searched in the blockchain explorer. [Figure 3-5-1] The Smithy Forges Assets and Supports Assets Circulation The combination of props in the Smithy mechanism is an atomic operation to ensure the atomicity. All operations of the transaction will either succeed or fail simultaneously. The core of “player-the Smithy- player” consists of two parts, that is, the player submits materials to the Smithy, and the latter returns the finished props to the players, which together can be regarded as a complete transaction. The information of the two parts will be recorded on-chain to ensure that users’ asset transfer is true, reliable and tamper- resistant. In doing so, circulated materials, tokens and other digital assets released by players are free from being manipulated in the same way as that in centralized game system, and data loss can also be prevented, thereby protecting the interest of the players. The Smithy has the following features:  It is a series of accounts with the right to generate props and equipment, and a series of contracts;  It is where props can be generated independent of the game;  Props generated here are unique;  Props generation, attributes setting and ownership transfer to users are all combined into one atomic operation;  It is managed by multiverse management committee (game developer, player guilds and the union of designers) 18

Project Cocos-BCX Cocos-BCX empowers the Smithy with props generation right under the multiverse. For example, Excalibur can be circulated across works in Arthur Legendary universe or in TYPE MOON universe, with the homogeneous asset under a unified multiverse as the transfer standard. 3.6. Nested Pr ops Combination Game props and equipment may be composed of multiple components and items. In Cocos-BCX, non- homogeneous digital assets of the blockchain game, i.e., props, can also be nested and contained. Each prop may involve multiple items. The parent asset may contain one or more child assets, and child asset can have other child assets. For example, Nested props combination below, “Red Comet” in Figure 3-6- 1 consists of three sub-props, “Engine”, “Wheel” , and “Weapon”, and the sub-props “Engine” and “Wheel” are respectively composed of other sub-props – “Fuel”, “Filter” and “Gear”, “Tire”. [Figure 3-6-1] Nested Props Combination 3.7. Pr ops Cir culation Platfor m In Cocos-BCX, props transactions are mainly implemented by two functions: The purchase of props is a multi-step atomic operation, where the props data of the user account is updated while paying the fee. If any action in the updating of the assets data is not recognized by the block of the mainchain, the entire transaction will be rolled back. 19

Project Cocos-BCX For the sale of the props, the functions provided by Cocos-BCX do not directly change the ownership of specific assets, but send a request for assets transfer to the OTC asset circulation platform (centralized or decentralized). In principle, users can only operate (transfer or sell) on their own assets, which should not be controlled by any third party, such as the platform. The OTC asset circulation platform needs to record orderObject after the function is executed successfully. Or the getItems function is called before the request is send to list user props for user to select. It is essentially a peer-to-peer matching of the requests after the purchase request is received. Unlike traditional game transaction platforms, there’s no intermediary on Cocos-BCX’s decentralized digital assets circulation platform, which improves transaction efficiency of both parties. On the other hand, fees go directly to sellers rather than the intermediary, allowing sellers to gain more benefits and buyers to consume less. Players can make transfer and purchase of non-homogeneous assets, such as game coins and in-game prop assets, on props circulation platform. The platform adopts a smart contract for the automatic matching of orders to provide a more efficient exchange service throughout the process of circulation. The circulation platform will be connected with game data running on multiple platforms. With an optimal compatibility and customization, game makers can flexibly and independently design their own on- chain game storage structure and connect game data to the circulation platform. Therefore, users can easily access the coins and prop assets of various games on the platform, providing a strong support for asset circulation within the game. After being authorized to log in to the platform, users may submit their game prop assets to the platform through orders. The purchase and sell orders that meet the requirements will be automatically matched by the system. The transaction covers both homogeneous and non-homogeneous assets, such as in-game currencies, props, equipment, and game data. The order information will be written into blockchain upon release. The corresponding assets in the game will also be frozen at the same time. A typical asset transaction process is shown as: [Figure 3-7-1] Process of Digital Assets Circulation 3.8. Implementation of Pr ops Cir culation Platfor m The exchange platform supports the free transactions of COCOS, independently issued “game coins” (homogeneous digital assets), and prop assets (non-homogeneous assets). The services provided by the exchange platform includes exchange of COCOS for other game coins, and the exchanges of different game coins, the price of which is determined by their exchange rate against 20

Project Cocos-BCX COCOS. The exchange platform can improve the game industry liquidity while providing a unified evaluation basis for the value of different game coins. Game contents circulation on the platform mainly indicates the exchange and circulation among COCOS, game coins and props. As data of game items are highly customizable, the data of different game props may be possibly inconsistent, so that it requires the game makers to authorize and provide analytic method for contents of the games to be connected to the circulation platform. When users submit a transaction order on the content exchange platform, the related game assets (coins or props) will be locked and cannot be used. The order contains the account ID of the seller and the content of the assets to be sold. When the order is matched, the system will automatically transfer the assets ownership and release to the seller the fees paid by the buyer. In the process of the transaction, the transfer of digital assets between the two parties will be merged as an atomic operation, which is to pack the operations of the two parties into one transaction. The state of these actions is consistent. The normal completion of the transaction will result in a unique transaction ID that can be checked on the blockchain, as shown in Figure 3-8-1: [Figure 3-8-1] Process of Game Content Request/Match 3.9. Enhanced Per mission System 3.9.1. Specified Per mission System and On-Chain Oper ations to Suppor t mor e Business Segments Cocos-BCX’s design of separating the assets ownership from the right to use specifies existing permission system of the assets. The use right determines whether the user has the permission on most operations, while the ownership determines whether the user has the actual ownership and key rights to operate the assets. Certain operations are required to be co-signed by the owner and user. 21

Project Cocos-BCX [Figure 3-9-1] Separation of Assets Ownership and User Right With specified operations, Cocos-BCX provides operations that can be called by the contract. The operations support transfer of ownership and use right, and enable the creation of a timed task. The operations of creating a timed task can specify the tasks to be executed upon expiration (if one contract function is called). [Figure3-9-2] Refined On-Chain Operations 3.9.2. Implementation of New Business Models by Contr act and OP Improved Cocos-BCX chain adds a variety of atomic operations and data structures for possible new- type business. Based on BCX contract system, developers can easily deliver the business logic unable to be implemented with traditional blockchain/contract system, such as asset leasing, mortgages and pledges. Lease The functions for each process of the leasing business are defined in the smart contract. When the lease agreement is reached, the contract functions implement the behaviors including paying rents and transferring the permissions by combining the ownership change OP and the general transaction OP. The blockchain- based timed task OP defines business activities such as reclaiming the use right upon expiration. 22

Project Cocos-BCX [Figure3-9-3] Process of Assets Lease Pledge The functions for each process of the pledge business are defined in the smart contract. When a pledge occurred, the contract functions implement the behaviors including paying the pledge and transferring the permissions by combining the ownership change OP and the general transaction OP. The blockchain-based timed task OP defines business activities such as reclaiming the use right upon expiration or returning ownership in the case of redemption during pledge. [Figure3-9-4] Process of Assets Pledge Pawn The functions for each process of the pledge business are defined in the smart contract. When a pledge agreement is reached, the contract functions will implement the behaviors including paying the pledge and transferring the permissions by combining the ownership change OP and the general transaction OP. The blockchain-based timed task OP defines business activities such as reclaiming the use right upon expiration or returning use right in the case of redemption during pledge. [Figure3-9-5] Process of Assets Pawn 23

Project Cocos-BCX 3.10. Player Autonomy and Assets Secur ity Cocos-BCX’s node toolkit will be open sourced, where game developers, operators, player guilds and designer studios can be nodes and participate in the election of council nodes. Due to the openness and transparency of the blockchain network, in-game digital assets information is accessible to everyone through the blockchain explorer. Since the accounts with high-value non- homogeneous assets in the games tend to be the preferred target for hackers, Cocos-BCX attaches great importance to the security of player account, and provides the following security mechanisms:  Operation permission The ownership and disposal right of in-game props are solely owned by the player, therefore the oepration to destroy any item shall be handled or permitted by the player himself;  Atomization of key operations When an order to exchange or create an asset is submitted to the platform or the Smithy, all operations in the process are considered as an indivisible atomic transaction. This means that the participation in these processes can only be approved by consensus. If any of the operations are not recognized by the blockchain network, the entire operation will be rolled back to avoid any abnormal transaction.  Scalable multi-step verification In addition to the blockchain transaction verification password, the game maker also provides password authenticator and random code verification to further improve the security of player’s assets. 3.11. Visualized Smar t Contr act Editor Cocos-BCX provides a visualized contract editor for developers to edit smart contracts, which is simplified from a user-friendly point of view. The editor graphically presents the functions and methods commonly used in the contract to the user, allowing users who do not have the ability to write scripts to easily compile a contract as needed while advanced features are available for programmers with proficiency in script languages. Visualized editor is an editing tool that assists developers in rapid development with graphical interfaces. Taking Click Wizard as an example, the software efficiently displays most of the common methods on the toolbar, which enables developers to compile and insert the script code in an interactive environment by simply clicking, dragging and filling in the parameters. 24

Project Cocos-BCX 4. System Ar chitectur e 4.1. Integr ated Blockchain-inter active Runtime Envir onment for Games [Figure 4-1-1] Cocos-BCX on-Chain Game Run-time Environment Architecture 4.1.1. Game Runtime Envir onment With Multi-System Compatibility Cocos-BCX believes the run-time environment of future blockchain game should involve the following features:  Full blockchain interoperable interfaces;  Transparent downward inheritance;  Packaged atomic operations;  Compatible with multiple operating systems. To simplify development process, Cocos-BCX designs an integrated run-time environment for various Apps and supporting interoperable interfaces. Combined with COCOS Creator, it simplifies the connection between game programs and the blockchain, making interactions transparent to developers, allowing traditional game developers to develop or migrate blockchain games without any barriers. Cocos-BCX SDK is integrated into the Cocos Runtime to provide a complete blockchain interactive interface for the game. The developers can connect game content with blockchain network based on Cocos- BCX SDK for the transparent and structured interactions, which frees the game development team from investing in R&D to be compatible with the blockchain network and different devices. The runtime environment will be compatible with Android, iOS and PC Web, mobile H5 and other systems and environments. The games in the runtime environment can be run across different platforms. 25

Project Cocos-BCX 4.1.2. Inter active Inter faces of Blockchain Cocos-BCX provides an interoperable environment that allows developers to easily interact with the blockchain. Cocos-BCX blockchain interfaces integrate with multi-system SDK, including Android, iOS, JavaScript for front-end web applications and back-end python and PHP. Those developing environments can facilitate the development of blockchain software, and data interaction, such as account registration, user information, assets operation and user data operation. On-chain data interfaces allow users to store homogeneous or non-homogeneous asset data, featuring compatibility and customization. Blockchain system does not demand clear text of digital assets. Game developers enjoy greater flexibility to structure on-chain data storage and guarantee safely transferable information across Client and market plug-in parser. Currently, the blockchain interactive environment provides mainly the packaging of functions including the search and transfer of homogeneous and non-homogeneous assets and props, changes in ownership, transaction submission, proposal and voting. 4.2. Exchange Gateway Suppor ting the Homogeneous and Non- Homogeneous Assets and Cr oss-Chain Tr ansactions Homogeneous and non-homogeneous assets are separated from the smart contract in Cocos-BCX. It is foreseeable that there will be a large number of ongoing transactions in Cocos-BCX network. It is necessary to reduce computational cost of assets analysis and circulation as much as possible to achieve cross-chain exchange of non-homogeneous assets. The separation of assets and contracts proves to be a safer design. [Figure 4-2-1] Exchange Gateway 26

Project Cocos-BCX Cocos-BCX provides a set of gateways for the automatic exchange of coins and props, which enables the smooth transfer of contents among different on-chain games and platforms under a unified value system. Contents that can be exchanged includes game coins, equipment data and etc. 4.2.1. Exchange of Digital Game Assets The exchange of game digital assets and Ethereum ERC20 digital assets is as follows: [Figure 4-2-2] Exchange of ERC20 Digital Assets Game coins can be transferred across consortium chains and private chains through exchange gateway. 4.2.2. Exchange of Non-homogeneous Digital Game Assets [Figure 4-2-3] Exchange between Cocos-BCX and ERC721 Digital Assets BCX-NHAS-1808 is a non-homogeneous digital asset standard for the decentralized and distributed ledger network in the use of COCOS tokens. Compatible with other standards for non-homogeneous assets, it features separation between assets and contracts and a scalable and customizable data zone. The ERC875 and ERC721 standards are Ethereum’s standard protocols for non-homogeneous digital assets. To some extent, ERC875 standard is more like an upgraded version of a simplified ERC721 standard, which is the very first of its kind. ERC841 and ERC821 standards are its optimized and amended versions while ERC875 standard is simpler and more direct. Its defined functions including name, symbol, balanceOf, transfer, transferFrom, totalSupply, ownerOf, and trade. Compared with ERC721 standard, the function of ERC875 standard is much simpler. Further expanding the digital asset technologies supported by exchange gateway allows the gateway to support non-homogeneous complex contracts represented by ERC721, ERC875 and BCX-NHAS-1808 standards. The gateway is equivalent to a specific compiler in the exchange of game props and non- homogeneous contracts. By translating and exchanging structured data, it realizes two-way exchange 27

Project Cocos-BCX between non-homogeneous contracts and on-chain game props. Compatible with more types of prop exchanges inside and outside the chains, it provides richer game content and user experience. 4.3. CocosChain: Impr ovement and Extension to the Existing Blockchain 4.3.1. Impr oved Data Str uctur e of Non-homogeneous Assets Non-homogeneous digital assets are a type of digital assets applied to distributed ledger network with unique assets instance. Optimized structure of non-homogeneous digital assets facilitates more flexible service to blockchain gaming. Cocos-BCX redesigns the data structure and adds custom data storage to accommodate possible game data and extended content. Meanwhile, consensus, witness, block generation and other crucial process are adjusted accordingly to be matched with new data structure. Item data in Cocos-BCX will be recorded in full in the block data only in the case of generation and any attribute change. While in the common transaction and transfer, only the hash pointer will be recorded to prevent block size from growing too fast with the accumulation of transactions. [Figure 4-3-1] Relationship Between Each Part and Data Structure of Non-homogeneous Assets 28

Project Cocos-BCX The non-homogeneous digital assets data structure in the blockchain network is divided into fixed data zone and scalable data zone. The former stores the basic information of non-homogeneous digital assets, including assets ID, multiverse statement and basic data zone. The assets ID is the unique identifier of assets instance in distributed ledger network, and the unique credential to access, check and modify the assets. Multiverse statement, including the multiverse ID, the type of game in which the asset is in effect and supported, the world and the currencies supporting the circulation of assets in the network. The basic data zone further consists of information including basic description of the assets, production time, producer, owner, user, black & white list of use right, etc. Scalable data zone is a functional section designed for attribute extension of non-homogeneous digital assets, including zone data and data with combination relationship. Data with combination relationship describes asset portfolios, nesting and affiliations. The scalable data zone stores specific transaction data under supported multiverse, the data unit of which is called “zone”. Different games or other business entities have exclusive zone IDs and data area in terms of zone data, which is isolated from each other. Zone data is stored in the form of key-value pairs of zone identity and data, representing the data of specific games, such as Attack, Defense and Durability. In addition, the design of separated use right and ownership makes the business designs of complex financial models including lease, mortgage and pledge based on on-chain permission system available. Cocos BCX-NHAS-1808 has many advantages over other non-homogeneous digital assets standards of Ethereum, such as the separation of assets and contracts, scalable and customizable data zone and compatibility with other non-homogeneous assets standards. [Figure 4-3-2] Comparison of Existing Non-homogeneous Digital Assets Standards 4.3.2. Separ ately Stor ed Assets and Contr act Data Homogeneous & non-homogeneous assets data, and smart contracts are stored separately on the blockchain. There are a lot of continuous transactions in Cocos-BCX, which makes it necessary to reduce computational cost of assets analysis and transfer. Separation of assets and contracts can contribute to individual execution of contracts and necessary results on chain. 29

Project Cocos-BCX Under this circumstance, the owner of the asset has full permission over the asset, and the operation of the asset can only be done by the owner's authorization. In this way, modifying the contract content to destroy assets attributes or call others’ asset can be avoided. Besides, Ruling out constraints of contracts is conducive to achieving cross-chain exchange of non-homogeneous assets. Therefore, the separation of assets and contracts proves to be a safer design. 4.3.3. Impr oved DPoS Consensus Mechanism The consensus layer of Cocos-BCX TestNet adopts the DPoS consensus algorithm. DPoS algorithm infers the block producers and block generating time based on the scheduled witness and allocated time slot. Usually the time slot interval is 5 seconds. In actual application, the interval is set to 3 seconds for faster broadcasting and larger throughput. If the scheduled witness arrives in the allocated time slot but there is no normal production due to network error or equipment failure, blocks will not be generated in that time slot. The network will wait till the next time slot and select the next scheduled witness to produce blocks. In Cocos-BCX, stakeholders elect all scheduled witnesses by voting. The scheduled witnesses are collectively referred to as active witnesses with a number from 11 to 101. They share the same scheduled block probability in the witness-scheduling algorithm in the DPoS consensus algorithm, which ensures that their block probabilities and rewards are consistent. Graphene voting is usually updated every 24 hours. In the initial stage, for the sake of security, stability and fairness, voting to network of the project usually updated at a shorter interval, probably 12 hours or less. [Figure 4-3-3] Comparison of Existing Consensus Mechanisms Following the principles of DPoS, CocosChain delegates witnesses and time slots to predict block producers and production time. The Aws of the main chain is always more than that of the forked chains. As a result, the block height of the main chain must be higher than the forked chains. Universal voting is also used to prevent the centralization of witnesses and to enhance network security. Above [Figure 4-3-3] shows the comparison between different witness mechanisms. 4.3.4. Secur ity Pr ovided by Moder n Cr yptogr aphy Modern mathematics-based cryptography has been widely used to various industries of the Internet. Common symmetric cryptographic technology includes AES used in Wi-Fi, the asymmetric cryptography 30

Project Cocos-BCX algorithms involve RSA (public and private key cryptography) and ECC. We use elliptic-curve cryptography (ECC) on our platform. Those algorithms create an encryption and decryption system that rejects decryption computation. Attempts to breach the encryption without keys are impractical because of the massive time (nearly hundred years) required. ECC, fully named as elliptic curve cryptography, was proposed by Neal Koblitz and Victor Miller, respectively in 1985. 4.3.5. Low For king Risk Under the Proof-of-Work (“PoW”) mechanism of Bitcoin and Ethereum, forking occurs when miners simultaneously mine two blocks. The shorter blockchain will be abandoned by the “longest chain rule” after 6 blocks. However, there will be two kinds of fork (soft and hard) if the miners do not follow the same mechanism. A soft fork is triggered by system upgrades and continues to exit until the upgrade finished. In the case that a group of miners on the same block main chain start take different consensus mechanism, a hard fork takes place and two separate blockchains are formed. “The DAO” is a famous case of hard forking of Ethereum in July 2016. When Ethereum forks into Ethereum and Ethereum classics, the computing power corresponding to the original main chain will be reduced, which will have a profound influence on the security of the entire main chain network. To assure the safety and accuracy of game data, CocosChain uses DPoS consensus mechanism with no mining involved. Risk of forking is low compared with PoW. A fork may only take place when more than 1/3 of the witnesses disagree to the consensus. Forking can also be prevented upon the removal of AWs by voting. 4.3.6. Multi-Chain Inter oper ability The Platform will offer multi-chain interoperability in addition to cross-chain exchange gateway. For instance, Cocos-BCX will support the large storage of smart contracts and data on IPFS in the next phase of development. 4.3.7. Mer ges of Multi-Oper ations to Ensur e Atomicity Prop producing for blockchain games is atomic. The prop producers create props based on the demands, materials and assets submitted by the players. Upon completion, the props are transferred to the players. This process engages a series of operations (OP), including generation of digital assets, setting of prop properties, and transfer of asset ownership to users. To ensure the consistency in the operational results, we combine the operations into one transaction, that is, one atomic operation. In this case, all the operations inside the transaction will succeed or fail at the same time. 31

Project Cocos-BCX [Figure 4-3-4] Atomic Merges of Operations Another application of atomic combination is dis-intermediated assets exchange of Project BCX, aimed to help seller gain more and buyers consume less. The dis-intermediated circulation platform does not store data about users’ assets but act as a medium for marrying node-to-node requests. Game manufacturers can flexibly design their own data structures for game assets. When users make a request for sale on the circulation platform, the related game assets (currency or props) shall be locked and cannot be used until the request is canceled. The request contains the mainchain ID of the seller and the content of the assets to be sold. When the request is fulfilled, the system shall automatically change the assets ownership and transfer to the seller the assets that the buyer has paid. By then, the whole circulation request is completed. When asset exchange begins, the sale or purchase shall be submitted to the circulation platform in the form of a request. The transfer of assets and the change of ownership shall be deemed as a one-off indivisible operation. In other words, the behaviors of both sides shall be recognized by consensus. If the mainchain block doesn’t recognize one party’s change in assets, the whole transaction shall be rolled back. That is, the change of asset ownership or transfer of assets throughout the exchange shall be packed inside one transaction. The state of the two acts shall be consistent. When the transaction is completed normally, a unique transaction ID shall be available for checking on chain. [Figure 4-3-5] Determining State of Atomic Transaction 32

Project Cocos-BCX 4.4. BCX Testnet: High-Per for mance Blockchain and High-Speed Contr act Vir tual Machine Cocos-BCX is competent in concurrent task processing. For most of the current online games, when the user scale reaches a certain level, the server needs to process a large amount of data within a short time, which is impossible for the existing Ethereum network. Theoretically, the improved DPoS consensus of Cocos-BCX allows a throughput up to 100,000 TPS. Under a rational data management mode, the concurrent task processing is sufficient to support the development and normal running of existing games, meets the basic operation needs of large online games on the platform and secures game experience almost the same as that of the existing centralized games. Large online games mean significantly high frequency in data interaction, as evidenced by DNF’s record of 600,000 people online at the same time and Steam’s even more astonishing one of 14.2 million people. If every online user’s submission of data is regarded as an application for consensus, Cocos-BCX’s maximum throughput cannot support such a magnitude of request. Hence, the development team designs various delegation templates based on the speed of witness so that single delegates need not witness and process all the run-time games at the same time but focus on witnessing and counting multiple games of the same type. Besides, under the templates, the submission of data or witnesses of different games are asynchronous. Each game will select a suitable delegation template. Data under the asynchronous templates is validated through on-chain database service. That is, users validate, store and obtain data on chain. This process is efficient enough to support operation of player data for large games. [Figure 4-4-1] Cocos-BCX Contract Contract is a segment of program that is executed automatically as well as a system participant that fulfills scheduled tasks according to the basic algorithms of the environment (compiler algorithms). Contract can define input and output, receive and store value and send out information and value. Smart contract is designed with the “trustless principle”. All nodes believe that each other is not trustable. Each node of 33

Project Cocos-BCX blockchain, which features distributed storage, keeps the same contract execution code. The execution results are witnessed by the computing power of the whole network. Whether they are recognized is decided by voting by all. Cocos-BCX smart contract supports the definition of witness delegation. To ensure that the contract execution efficiency allows sound game experience for the users, Cocos- BCX comes up with a high-speed contract virtual machine scheme based on LUA for on-chain games. Different from existing rivals, the scheme features custom-made and optimized run-time environment and execution efficiency as well as language and API system that are the same as those of SDK, and interoperation interfaces for the chain and game execution environment. All these address the monotony in environment and poor flexibility and customization of blockchain contracts. The use of smart contract has gone beyond description of currency to content directly related to the games, probably including basic algorithms, setting, unit, scene and even map. The improved virtual machine not only supports more complex and flexible contract forms but greatly improve the execution efficiency of smart contracts. 4.5. Fur ther Enhancement of the Distr ibuted Ledger System for Blockchain Gaming It’s mentioned that the final form of on-chain games is the complete on-chain implementation of overall game logic. But as current blockchain technology cannot satisfy the threshold of loading whole games, several key issues are to be resolved before game algorithms can be migrated on blockchain:  The cost and volume for nodal data synchronization Smart contracts can only run on full nodes. And it is unpractical for the users to host nodes that require massive system resources, networking, and time to synchronize.  Algorithm codes exceeding the block size Whole backend logic is required for the contract to implement complete game logic on blockchain. The sizes of algorithm smart contracts may be larger than system block size, especially when game logics are complicated. But with current blockchain technology, the contract that cannot be held by the blocks will never work and produce any result.  Continuous execution of smart contract Whole game logic running on blockchain means continuous execution of smart contract before end of the game. That is cross-block execution, and game algorithms may run continually at time durations beyond block intervals, which is not yet available with current blockchain technology.  Latency of transaction executions Whole game running on blockchain also means that all possible executions of the game are processed on blockchain, including high-speed response. Transaction response of traditional blockchain depends on the behavior of block generation with a time interval, and the fastest confirmation is also limited by block generation cycle, making it difficult to meet the need for game contracts to instantly respond to transactions. 34

Project Cocos-BCX  Inaccessible to randomness consensus On-chain randomness is described by open smart contract, and different node noise needs to be added to contract operation to produce random results that cannot be calculated by the third party. However, the noises from different nodes may vary. That is, other nodes cannot execute the contract again to validate whether the randomness is correct, which ultimately leads to the failure in consensus.  Feasibility of critical features such as on-chain timer and heartbeat Timer and heartbeat, along with their sync security requirements, are necessary to execute scheduled or conditioned smart contracts. No solution is available for these building blocks today.  Digital assets authority Traditional blockchain digital assets are recorded in the contract data zone, and assets are inseparable from contracts. Therefore, contract owners may damage the interest of assets holders if they are authorized to modify digital assets data. Accordingly, CocosChain proposes these preliminary designs and features that substantially improve the existing blockchain:  Reduced data volume and sync time on nodes;  Syntax support to compartmentalized consensus processing;  Continual execution of smart contracts;  Minimum latency to event execution;  On-chain trustable randomness;  On-chain timer and heartbeat;  Authority added in non-homogeneous digital assets data structure. 4.5.1. Light Nodes In Cocos-BCX, light node is in nature an environment capable of interoperation with the chain. Different from full nodes, light nodes need not synchronize data to network but necessary contract information and environmental data. Such a design significantly reduces the amount of data and time for synchronization and allows actual capacity and feasible time cost for the on-chain game software. The games developed by Cocos-BCX are basically contracts operated locally in the light nodes. In the contract, the consensus and non-consensus parts are identified and compartmentalized separately into one or more sub-contracts that are distributed to related nodes for consensus (for details, see the Syntax Support to Compartmentalized Consensus Processing). Such a design allows enormous game contracts to be executed efficiently without latency. Separate processing of consensus and non-consensus parts secures data reliability similar to that of traditional blockchain while offering possible best user experience. Meanwhile, validation for light nodes falls on execution environment and input data (validation of trusted execution environment) rather than process and outcome as in traditional blockchain, further enhancing the overall execution efficiency. 35

Project Cocos-BCX 4.5.2. Continual Execution of Smar t Contr acts The light nodes make it possible for whole games as contracts on chain. Game contracts can be executed in the light nodes continually over time, independent of the block period and block size but only related to game sub-contract with consensus. Based on the syntax identifiers of priority of consensus, the game contracts and sub-contracts adopt asynchronous and synchronous consensus respectively to validate and synchronize key steps during continual execution. In this way, a mechanism is built for continual execution of game contracts and witness of consensus on results. 4.5.3. Session There is an on-chain interface for session. It creates a user session list with active restriction in the public data zone. The users in the session interval have the rights to push transactions to other uses in the same interval. When other users receive the notice on data changes, they shall obtain corresponding data in time. 4.5.4. Suppor t consensus tasks at the syntax level Cocos-BCX proposes the design of syntax support to compartmentalized consensus processing for contracts. The consensus priority of script may be adorned with specific key words so that the contract interpreter can recognize the identified contracts in need of consensus and, when scanning the whole text, compartmentalize them into sub-contracts for consensus from related nodes in the chain network. The consensus priority includes, in an ascending order, no need for consensus, normal consensus, immediate response and immediate validation. [Figure 4-5-1] Light Nodes and Asynchronous Smart Contract Execution 36

Project Cocos-BCX Whole contract is executed locally. To execute the parts in need of consensus, consensus methods are determined based on the syntax priority identifiers. Different priority calls for different steps of consensus. The execution of game contracts is smoother, with lower possibility of block waiting and, if any, shorter waiting. The execution and consensus of main contracts identified as immediate validation, the highest priority, are asynchronous. For those identified as immediate response, when the transaction is submitted, the nodes shall immediately return a receipt for submission, that is, the hash value (Tx ID). Transactions identified as normal consensus shall be executed following the normal procedure in blockchain. Those identified as no need of consensus shall be executed on light nodes. In addition, contracts in need of consensus are compartmentalized into sub-contracts that are then distributed for execution. These sub-contracts shall have complete context and a design without external dependence, so that other nodes can obtain the result correctly. 4.5.5. Pr ior ity of Contr act Consensus Cocos-BCX deals with all transactions that need consensus in the game, including those require high- speed response and immediate confirmation. Transaction response of traditional blockchain depends on block production, and the fastest confirmation is also limited by block production cycle, making it difficult to meet the need for game contracts to instantly acknowledge transactions.  Rapid asynchronous validation of transactions As illustrated in [Figure 4-5-2], the senior consensus tasks are marked up, extracted, and broadcasted to the nodes for execution. The block producers receive and pool the results from the nodes. When the number of results reaches a certain threshold, the block producers confirm these tasks and write them onto the block cache. [Figure 4-5-2] Concurrent Task Processing 37

Project Cocos-BCX Therefore, the nodes will submit, process, and broadcast transactions immediately, and block generation and transaction execution become asynchronous for rapid asynchronous validation.  Instant response In the Cocos-BCX design, for a contract identified as instant response, when users send a transaction request to the nodes, the nodes shall immediately broadcast it to the network and return the hash value to the users. With the design, the final record period does not differ too much from the traditional design but the response to transaction is hardly delayed. The nodes shall submit transactions immediately, which greatly increase the speed of response. Moreover, the hash value shall inform the users of the state of transaction. Meanwhile, the information about transaction shall be updated to the transaction history datasheet and pushed dynamically to the users, who need not wait for the transaction to be validated and used in order to receive the callback for response. With reference to hash tracking in Ethereum, we have added the mechanism for dynamic push of transaction to users. 4.5.6. Minimum Tr ansaction Latency Existing blockchain confirm task results after the nodes receive, execute, validate and record the data on the blocks. A task is pended upon submission and executed in the next block production cycle, resulting in system latency.  Prioritized consensus Cocos-BCX comes with a syntax priority identifier for transactions. When a transaction is identified as immediate validation, the nodes will submit, process and broadcast the transaction immediately. The block generation and transaction execution become asynchronous for rapid asynchronous validation. Immediate response is another consensus priority. With it, response to transaction is hardly delayed. The nodes will submit transactions immediately, which greatly increase the response speed.  Partitioned witness To improve the node utilization rate and processing efficiency, Cocos-BCX proposes the design of partitioned witness based on delegate witness. That is, some nodes focus on processing specific types of contract requests. The design works as shown in [Figure 4-5-3]. [Figure 4-5-3] Partitioned Consensus Design of CocosChain 38

Project Cocos-BCX In the game industry, compartmentalized witness allows optimization of the processing capability of related nodes based on the type of request. For instance, for centralized requests for floating-point operation, the core hashing power should be strengthened; for centralized requests for data structure processing, the storage IO capability should be enhanced. In this way, the overall efficiency and benefit are optimized. 4.5.7. Delegate-Type Tr ansaction Mechanism Delegate-type transactions mainly cover the transactions that are highly random and generate different results when executed by different nodes (like generating a set of random numbers). However, this type is restricted to the transaction request related to non-personal data. With the consensus identifiers, names of node clusters (node groups) that engage delegates in consensus can be defined, specifying which type of nodes shall process the transaction. When only one node is needed (N=1), the designated node cluster shall randomly choose one online node within the cluster to process the transaction, for example, processing the random event. When there is more than one delegated node (N>1) or one cluster, several nodes within the designated cluster shall be distributed to process the transaction. When the delegates that pass trusted execution environment validation received the delegated transaction, they shall validate the feasibility of the transaction, execute delegation, and, upon completion, encrypt and pack the transaction result, finally broadcast it to the chain. The design of defining the name of the delegated node cluster is adopted for two reasons. First, to ensure security, only the name of the delegated node is defined and nodes are chosen randomly from within the cluster to process transactions. The delegates do not know the specific delegated nodes, which prevents cheating. Second, to guarantee run-time reliability, the designated node cluster ensures that the transaction is distributed to the nodes that are online. [Figure 4-5-4] Delegate-type Compartmentalized Consensus 39

Project Cocos-BCX 4.5.8. Implementation of On-Chain Tr usted Random Pr ocess External randomness refers to that the uncertainty of the random process occurs outside the blockchain system, while internal randomness does the opposite. External randomness has no guarantee that the generation process of random factors can be trusted by the blockchain system. Therefore, to achieve rational randomness in the blockchain system is in fact to guarantee the credibility of the random process and results trustable.  The nodes practically finishing the execution of random process shouldn’t be accessible to the scenarios and objects of the random information, to avoid cheating with this part of the information.  The random process should not be publicized on blockchain before completion of its invocation business behaviors, hence to prevent the ongoing business from losing impartiality due to the publicity of randomness (Eg. The composition of each gamer’s card in a round of Landlords).  Internal randomness should be able to prevent BP/developers from cheating. At present, Cocos-BCX has successfully implemented trustable on-chain randomness, and it’s available for contract developers to call the randomness by interface. Simply call the random function of the contract in a general development method and you’ll obtain the internal-source random data. [Figure 4-5-5] On-Chain Trusted Random Process 4.5.9. On-Chain Tr usted Randomness Whether game algorithms on blockchain have practical value is related to on-chain randomness. Research reveals that one key problem should be solved for complete on-chain randomness. The algorithms of on-chain randomness are described by smart contracts and the contract process is public. If random results that cannot be figured out by third parties are to be generated, there should be noises from nodes in the input into the process during contract execution. However, the noises from different nodes may vary. That is, other nodes cannot execute the contract again to validate whether the randomness is correct, leading to failure in consensus. 40

Project Cocos-BCX We have proposed three feasible solutions to address this problem. Solution I  One or multiple random data pools are reserved in the dynamic data zone of blockchain. The block producers wrap the random results in the encrypted data segments of the block and release the closed-source codes of encryption. In this case, all the nodes shall have the same set of random data pools whose data is in pipe form with read and write sides and which are accessible to the read and write sides in line with the algorithms and features first-in-first-out.  Since transaction processing is consistent across all nodes in the blockchain, applications may read the random results from the random data pools during application. Under such a mechanism for generation and distribution, the security of process and result meets the requirement from the blockchain network:  Any access (read and write) shall cause irreversible changes to the random data pools.  Writing random data shall be completed by closed-source dynamic encryption library.  Random data generators shall not know where the random results are placed in the random data pools and who shall use the random process. This solution is applicable to scenes where the chain network shows consistency in the order of transaction processing. For instance, in RPG games, players open the map loot box for random props. Solution Ⅱ  A delegation mechanism allows some transactions to be delegated to some trustable node cluster for processing. The cluster allocates randomly online trustable nodes to execute the transactions. After execution, the trustable nodes shall record the random results. The client shall obtain the results via the informing or polling mechanism.  Since this solution is based on the chain transaction delegation mechanism, the changes to chain shall be smaller than those in Solution 1. However, to ensure the feasibility of solution, the following requirements shall be met:  The commissioned parties shall pass trusted execution environment validation to ensure their reliability.  When the delegates execute the randomness and release the results, the same safe encryption library shall be used.  For the transfer of encrypted data, zero-knowledge proof or other schemes shall be used to prove the identity of the delegates and shall be recognizable to the clients, so as to ensure that third parties do not forge the data obtained by the clients. This solution is applicable to transactions that engage multiple parties but need only one batch of results of randomness, like the order of shuffle in chess and card games. 41

Project Cocos-BCX Solution Ⅲ  The current block producers receive random transactions, generate a result via the random function, encrypt the randomness and results, write them to the block data, pack it and send it to the whole network. Other ordinary nodes accept and use the result, reaching a consensus on the random transaction. This solution is applicable to lottery draws in games, like throwing the dice for a random result. 4.5.10. Timer and Hear tbeat Nearly all games and applications need online detection. For Cocos-BCX blockchain games, two concepts, namely, timer and heartbeat are put forward in response to user state detection and continual session. Time synchronization mechanism is the premise of a timer in the blockchain network. The traditional mechanism is built with external time signal or trust center. Under the trustless logic of blockchain, the external time signal and trust center both have defects that cannot be self-validated. Hence, on-chain time synchronization can only be completed on blockchain. The time synchronization solution of Cocos-BCX works as: With block timestamp, the block nodes broadcast equivalent time synchronization while releasing blocks. Each node completes time synchronization operations upon receiving the block broadcast. In the end, time synchronization to the whole network is completed once in one block synchronization period. With such a design, two-form timer technical support is provided:  With block period as the minimal timing granularity, the timer works according to the scheduled timing goals. Without bias caused by factors like time zone, the block timestamp is deemed as the timing standard for the whole network. The timer can be executed normally in any network zone and time zone based on the same timing rules.  Use the messaging mechanism similar to internal-source random process to submit the parameters required by the timer to random node by delegating, and the implementation layer of the node will execute the behaviors including initialization and expiration notice for the timer. Heartbeat is similar to the timer. Its time pulse also comes from the block timestamp. In one heartbeat period, nodes/ends submit information about their updated connection. Absence of such information in a period indicates that the nodes/ends are offline. The timer and heartbeat provide application basis for user state detection and future sessions. 4.5.11. Standar dized Non-Homogeneous Assets Blockchain divides non-homogeneous digital assets data structure into fixed and extensible data zone, and the latter supports attribute extension of non-homogeneous digital assets, serving as a storage zone for specific game transaction data within the supported multiverse, including zone data and data with combination relationship. Flexibly structured extensible data zone of non-homogeneous allows the extension of games or other business scenarios. As the game increases, zone data will gradually be added when assets 42

Project Cocos-BCX transfer across different games, and thus affect the efficiency of chain operation. Meanwhile, asset authority has to be added to prevent malicious data from being written into the contract and causing redundant:  Assets owners have the right to delete but cannot modify certain zone data, which can reduce data redundancy while preventing cheating, such as custom enhanced props;  Contracts can only modify zone data in charge. The contract reads all information of the NH assets’ extensible data, but the modification permission is limited to the zone of current data. For example, in blockchain games, the contract reads the relevant assets data of the games “HEROES OF THE STORM” and “World of Warcraft”, while the weapon “Frostmourne” of “HEROES OF THE STORM” won’t be truly cut off in “World of Warcraft”, but presents the status of “cut-off”. 4.5.12. Design Tools for Established Rules It can be found in real game scenario that the user recognizes the open rules of some game, but loses assets after joining the game, because the developer changes the rules by temporarily rewriting the contract code before the game starts, or withdrawing the raised fund while no longer provide services to the users, which is beneficial to the developer himself but hurting the users. The established tools are just developed to prevent such phenomena. Game developers can use the “design tools for established rules” for blockchain- based games to design blockchain games to enhance user trust. This is realized by locking a certain amount of homogeneous assets using smart contract, and then set unlocking requirements, time and amount. Add to contract codes the utility functions that during the assets lockup, the codes of games are not allowed to be modified. The contract codes cannot be modified during the assets lockup, so the game will operate within the initial rules. 4.6. Cheat-pr oof Tr ansaction Ver ification Mechanism to Pr event BP/ Developer s fr om Cheating As the core node of transaction processing and communication across the network, BP has quicker access to the results than general nodes and thus higher priority in acquiring some timely or confidential information. This also indicates the possibility of cheating. For instance, the BP may be informed of the outcome of a random process in advance and utilize contract to predict the operation outcome, which is unfair to the games in the public chain and makes them unsafe. The developers herein refer to individuals and organizations that are capable of executing chain interaction or transformation, including low-level and contract developers in the chain network. They are able to analyze or control chain information in depth. There is some reason to believe that they can read codes to access the encrypted or concealed details of communication technologies that may be used in transmission and design codes accordingly to obtain the information of random process and sensitive data illegally. Therefore, BCX comes with mechanisms for transaction execution, information transmission and operation that can prevent BP and developers from cheating, which will be described in this paper. 43

Project Cocos-BCX 4.6.1. Dynamic Encr yption Tr ansmission To prevent sensitive information from being intercepted and deciphered during broadcasting, a safe mode of transmission with dynamic encryption is integrated into the BCX chain network, as demonstrated by [Figure 4-6-1]. [Figure 4-6-1] Transmission with Dynamic Encryption Taking random seed as an example, when a random seed is produced, the producer will encrypt the information with the dynamic data concerning time, block height and other noise input as AES key and broadcast the encrypted information. All the nodes share the same algorithm for dynamic key generation that allows them to correctly decipher the information. The eavesdropping third parties, however, will not be able to do that, which guarantees the security of sensitive data during transmission. 4.6.2. Pr event Custom Nodes fr om Accessing the Networ k Sound transmission security alone cannot prevent node developers from revising programs to output the information they have received and deciphered. Hence, a mechanism for authentication is incorporated to prevent the revised node program from connecting to the chain network, as shown by [Figure 4-6-2]. [Figure 4-6-2] Node Access Verification Mechanism 44

Project Cocos-BCX Before release, the BCK node program will be embedded with authentication information that is not included in the open source code yet related to the version number. When a node tries to connect to the chain network and other nodes, the latter will verify whether the information is consistent with that recorded in the chain network and refuse the connection of nodes that fail to pass authentication. In this way, malicious connection from revised node program to the chain network is stopped. Besides, secondary developers can also customize the authentication information in the source code to release their own chain network, which will also be able to prevent non-official code connection. 4.6.3. Concealed Pr ocess Var iables Since the contract itself is a Turing-complete state machine system, fixed input will derive fixed output and the results will be broadcast to the whole network for synchronization under the transaction mechanism. If the broadcast information is an intermediate process of a series of behaviors, some process variables that should not have been known may be revealed. To address this problem, a contract execution logic that conceals process variables is put forward, as shown by [Figure 4-6-3]. With a reasonable contract design, process variables that involve sensitive data are executed in the same OP, which is completed in the memory of the executing node. What is broadcast is then the OP outcome. In this way, the process variables are concealed throughout the period, with no risk of exposure. [Figure 4-6-3] Process Variable Concealing Mechanism 45

Project Cocos-BCX 4.6.4. Contr act Mechanism with Execution Authentication An execution authentication mechanism is added to prevent malicious developers from predicting the possible output of the contract via test use of contract interface. To be specific, only authorized accounts can execute specific contract interface, as shown by [Figure 4-6-4]. [Figure 4-6-4] Contract Mechanism with Execution Authentication When the contract receives execution request, the signature in the request shall be verified against the execution permission specified in the contract. Only when the request passes authentication shall the contract function be executed normally. Otherwise, the contract shall be directly terminated without returning the payment to the requestor. With this mechanism, even if the developers know the code of the chain and the contract and the process and principles of execution, they shall not be able to maliciously use specific interfaces. This guarantees that the contact shall not be used at will for prediction of execution outcome. 4.6.5. Inter nal Tr usted Envir onment for Execution of Sensitive Pr ocesses For information or operation that remains sensitive during a certain period of time (like a board game), this scheme allows execution logic within the period to work in a blackbox mode with protection from the Trusted Execution Environment (TEE) mechanism. Usually the chain network challenges or verifies the blackbox environments on a regular basis via the TEE mechanism to ensure their reliability. Besides, any of them shall be chosen randomly for the execution of the sensitive processes. When the execution is completed, traceable records and outcome shall be submitted online to ensure fair, open and transparent recording on the chain network. It works as [Figure 4-6-5] shows. 46

Project Cocos-BCX [Figure 4-6-5] Mechanism for Internal Execution of Sensitive Processes This mechanism prevents developers and BP from participating in the execution of the blackbox processes, thus avoiding their cheating. With the design specified above, COCOS-BCX shall offer a trusted, reliable and safe execution environment for all the businesses that it supports. 47

Project Cocos-BCX 5. Economic System of The Platfor m 5.1. Substantial Changes Blockchain Br ings to Gaming From a user-experience perspective, there is no difference between “blockchain games” and normal games to the players, while blockchain games may have fundamental impact on game market. Existing games are based on the business logic of “Pay for service”, that is, the users obtain game experience by individual costs of money, time and data. But based on the features of openness, irreversibility and permanent existence of on-chain data, the in-game items can be managed and transferred by the users, changing experiencing services to experiencing assets. We believe that “Pay for service” and “Buy and use assets” are totally different value propositions to the developers, publishers and players, which may form various of behaviors and business models. These potential changes can be divided into following two types: 1. Digital content as assets. Assets are resources that are formed by past economic activities and controlled by a certain party and that can generate economic benefits in the future. Games and in-game digital content can both be deemed as assets on blockchain because of (1) technologically validated scarcity of supply. The supply of content on blockchain can be limited, assuming economic value to the content, and (2) technologically validated transferable ownership. The titles of the content are irreversibly recorded, and can be transferred under the proof of their tokens. Digital content has the rights to be possessed and its flow mechanisms, truly becoming assets. 2. Models of business type and asset pricing. Taking a domestically ranked B-level mobile action role- playing game (Action RPG) as an example: The publisher heavily promotes the game for a few days after selection, testing And Online Launch. With a short window to make profit, the developer starts charging the users after several hours of game time as they expect the lifetime of most accounts to be up to 75 day. Most players are forced to make choices between playing and paying, as they are aware that the game will not be operated over 12 months. This dynamic causes the parties to speculate on short- term interest and therefore limits the potential lifetime value of the games, regarding the game as an asset, but unable to maximize its value. For many years, the publishers are usually blamed for impairing user experience and squeezing the profit of developers. Various technological and commercial efforts— such as HTML5 games and independent publishing—were tested to bypass the intermediary, but the industry landscape remains unchanged. We believe the problem stems from the fundamental contradiction between traditional business models and value maximization of game assets. From a long-term point of view, there is obvious interest misalignment among developers, publishers and users. Digital games are creative businesses with significant uncertainty, and developers hope to maximize the overall value of a proven game. Publishers monetize on web traffic, prioritize time-justified profitability, and care less on the total lifetime value of a game. Users demand game experience at reasonable costs of their money, time and behavioral data. It appears that developers and users share the common interest and de- intermediary improves the industry efficiency. However, it is practically unrealistic for the digital content to 48

Project Cocos-BCX reach the users without professional promotion. The radical conflict remains. And games, if treated as assets, are under a pricing framework with radical fallacies. [Figure 5-1-1] Pay-for-Service Asset Pricing Model In blockchain environments, the asset pricing model may shift based on token economics. By possession of the game tokens, developers, publishers and users share the common, long-term interest. Their action tends to serve the objective of maximizing the game value. Furthermore, the liquidity of token transfer allows intermediaries to promote games with flexibility. In theory, a game may be promoted by various publishers on a continual basis. Any individual or institutional intermediary may join or exit the promotion base on its own economics. The industry interest relatively aligns and the maximum value of games may be achieved. [Figure 5-1-2] Trade-of-Assets Asset Pricing Model 49

Project Cocos-BCX We believe that in the revolution of blockchain gaming, the goal is not the formal “disintermediation” but the “interest consistency and assets value maximization”. As the professional role for user operation, “intermediary” will always exist whether in form of institution or individual. In conclusion, “blockchain game” can be defined in a more accurate way as “A game that applies blockchain technology and possesses blockchain-based economic mechanism”. The development path of blockchain gaming described in section 1.3 may also be considered as four phases gradual interest uniformity with market participants’ participating in assets pricing, which is resulted by the changes of business models that drive developers and users. It is bound to fundamentally change the game industry. These trends also apply to general digital asset classes beyond games, which we will support in the next phases of our project. 5.2. Design Pr inciple of Cocos-BCX Economy The underlying value of our platform economy is the digital assets created by the developers using a complete set of components including Cocos-BCX infrastructures, digital rights management and assets circulation platform. Cocos-BCX economy keeps expanding, and the scale continues to grow as more assets are created, managed and exchanged. With the grapheme-based technology and governance design, Cocos-BCX has the economic attribute corresponding to DPoS consensus. The platform is featured with non-mining, delegate consensus, low risk of forking and definable assets circulation cost, etc., which enable the developers and users to invest their major resources into the creation and exchange of digital assets, with totally low costs. Our objective is to advance the gaming industry by solving the problems in the real world, where behavior and psychology are complex and imperfect. The economic rules on Cocos-BCX are designed to be the minimal viable tools to offer the users at maximal flexibility. Meanwhile, we aim to incorporate the existing values of the global developer community to be our governance principles:  Self-sustaining: The project is sustainable with a solid business model for sustainable existence.  Autonomy and co-governance: Gradually form a common decision-making mechanism between the community and a consensus-based sub-community(Eg. Ecosystems with shared multiverse) and eventually operate each other with consensus principles, and to build a framework where key decisions are made by votes to the maximum level of practicality.  Sharing: Part of the community values as common wealth for community sustainability and competitiveness improvement.  Self-evolving: Challenges to the community shall be encouraged and rewarded to ensure our long- term competitiveness. 50

Project Cocos-BCX Cocos Token: The Native Pricing Medium of Digital Assets To achieve the assumption, we create COCOS token as native circulation medium and governance proof for economic activities on Cocos-BCX platform. Besides being the carrier for value exchange and the proof of community participation, COCOS token has the potential to be the native pricing medium for general digital assets, a key part for the ecosystem of digital assets. Massive of decentralized digital assets will exist in multiple blockchain ecosystems with various standards in the future. Therefore, cross-chain ecosystem assets pricing medium is necessary. COCOS token has the potential to be native pricing medium for following reasons: 1. Cocos-BCX platform supports the general exchange of fungible and non-fungible tokens in terms of technical infrastructure, consensus mechanism, and application features, etc. COCOS token sets the technical foundation as basic pricing medium; 2. In the process of assets creation on Cocos-BCX platform, both the production behaviors (Eg. Delegate- consensus block generation) and production factors (Eg. Purchasing in-game design materials in app stores on the platform) use COCOS as a native pricing medium. For digital assets produced on Cocos- BCX, the price denomination by COCOS token measures the productivity and value chain. As a result of market dynamics, the asset pricing by COCOS represents the economic value-adding rather than a value-tagging. 3. The proposed economic system on Cocos-BCX platform supports and encourages circulation of assets under the same or associated multiverse. The exchange activities denominated by COCOS do not only serve as capital investments but also establish a system for the users to compare and trade by the actual value of use. COCOS token has the circulation foundation as the basic pricing medium. On the basis of COCOS, developers and users are enabled to appraise, compare, circulate and manage the assets based on different ecosystems, universe, and technical standards. At the same time, as the native and fundamental pricing medium, COCOS is the necessity for the development and circulation of digital financial products and the derivatives for future blockchain industry. 5.3. Basic Use Model of COCOS Digital Assets COCOS tokens are introduced and assumed with three objectives: (1) Medium of value exchange, (2) Proof of stake for delegated consensus mechanism of Cocos-BCX chain, and (3) Proof of participation in and governance on community activities such as bounty tasks. COCOS tokens are created in the process of consensus contribution rewards (Eg. Block generation), and developers’ assets creation, and will be transferred to the users through in-game currency/items and circulation platforms. Users and developers can also exchange COCOS to other tokens with the digital assets circulating facilities provided the platforms. As the medium of value exchange, COCOS can be used to pay for community resource consumption, exchange, consume and realize circulation of digital assets, as well as to pay for cross-ecosystem consumption and resource exchange (Eg. The GAS required for releasing Ethereum applications through the platform). 51

Project Cocos-BCX As the Proof of stake for delegated consensus mechanism of Cocos-BCX chain, COCOS holders are allowed to directly participate in consensus delegate voting. For the detailed voting mechanism, please refer to section “4.3.3 Improved DPoS Consensus Mechanism”. As the Proof of participation in and governance on community activities, COCOS can be used as incentives for voting delegates of community events and rewards for task completion in the community. For example, attract developers to develop or optimize specific features of the platform with COCOS as rewards. We initially propose the supply of 100,000,000,000 (one hundred billion) COCOS token, with the minimal unit of 10-18 COCOS, under ERC-20 standard on the Ethereum platform. The number of total supply remains constant. After the launch of CocosChain, the token holders can convert their ERC-20 COCOS to native COCOS under the ratio of 1:1. 5.3.1. Distr ibution and Acquisition of COCOS Token All participants on Cocos-BCX platform enjoy the same identity permission. Whether normal gamers or developers can create their own digital assets and generate earnings by taking advantages of the platform. COCOS tokens can be acquired in the cases including but unlimited to: 1) Value creation, based on (A) production value. Developers are rewarded for the games and in- game items they produce. The incentives are positively correlated with the effective aggregate value of their assets, and negatively correlated with the life duration and total asset value of the Platform. The amount of value-production based incentives are capped, and (B) exchange value. Developers are rewarded if the assets they produce are traded frequently. The incentives are positively correlated to the total trading value of specific assets (including games, apps, in- game/app items). The amount of value- exchange based incentives is unlimited. 2) Contribution to the Platform community. On the early stage, we reward the participants who contribute to our community tasks (code submission, community interaction,etc.) by offering tokens. Later, we will adopt various forms such as bounty tasks and free assets (e.g. game characters giveaways) to encourage community behaviors like new function developing, upgrading, bug reporting, and platform testing. These rewards are allocated from Cocos Foundation with no limit in amount. 3) Asset circulation. Users may sell the in-game items for COCOS tokens. The supply and value of in-game items are determined by the game developers and the market. The platform does not impose rules and quantity restrictions in principle. 4) User incentives. COCOS tokens are distributed to the users who conduct effective behaviors such as account generation, trial use of new games, etc. The platform confirm the effectiveness of the incentive by analyzing users’ access effectiveness, information integrity and behavior rationality. The incentives are positively correlated to user activities (such as posting, liking and replying), and negatively correlated with the size of Cocos-BCX user base and life duration of the Platform. The amount of user- interaction based incentives is capped. 5) Rewards to consensus work and block generation on CocosChain. 52

Project Cocos-BCX 5.3.2. Use and Consumption of COCOS Token COCOS tokens can be used in the cases including but unlimited to: 1) Payment to the suppliers for the exchange of game development tools, features, and materials (such as the design of characters, user acquisition, etc.); 2) Payment to platform for value-added services such as functional components; 3) Purchasing game currencies or props within games or on certain circulation platforms. Based on the authority management mechanism of the platform, the developers will receive payment during every complete circulation of the game items; 4) Rewards for bounty & voting tasks in the community. Cocos-BCX charges certain COCOS tokens on every circulation event and uses them for the development of the Platform. 5.4. Allocation of COCOS Token 83% of the COCOS tokens are allocated for the development of our Platform initially, including but not limited to block generation reward to witness, ecosystem developer incentives, global community building, project promotion and marketing, alliance establishment, ecosystem investment, R&D, financial affairs and legal & compliance. Claiming of these COCOS includes contribution through consensus achievement, free donation, giving-away for services, and giving-away for other digital assets, etc. 17% of the COCOS are reserved for team incentives. We expect the market for blockchain gaming and Cocos-BCX to be proven in three years. Accordingly, the token held by the team will be granted and unlocked evenly at the end of the three years, with the first vesting starts at the end of the 12th month after the token generation. 53

Project Cocos-BCX [Figure 5-5-1] Initial Token Allocation 54

Project Cocos-BCX 6. Str ategic Investor s Following institutional investors are involved in investment of Cocos-BCX, including: NGC, Binance Lab, INBlockchain, Dfund, 500Startups, BlockVC, OK Blockchain Capital, Yisu Capital 、Grand Shores Fund, ONTology, FreeS FUND, NODE Capital, Consensus Capital, Hash Capital, NEO Capital, Ticker Capital, Contract Capital, Junwu Capital, Candy Capital, Hofan Adventure Capital, BMETA Capital, BYTE Capital, Minjie Capital, InsurFun, BA Capital, Consensus Lab, TOKENMANIA and BYZANTIUM Capital, etc. Most of those investors are tier-one institutions with powerful strength. 55

Project Cocos-BCX 7. Summar y We believe that digital assets are the asset class that best fits the economic nature of blockchain and have broad prospects for development. With its huge market, the gaming industry is the first step to tackle in the development of blockchain-based large-scale applications. In order to provide developers with the conditions for large-scale generation of assets in blockchain environment, we are launching a platform for developing applications and managing/circulating digital assets. The platform supports content creation of large-scale digital assets, the integration of blockchain mechanisms, and essential components for assetization, management and circulation of digital contents. As of August 2018, we have implemented the development of the main modules in our alpha version and launched our non-homogeneous digital assets standard BCX-NHAS-180. 56

Project Cocos-BCX 57