1

Mar 2019

BBMultiVAC

Analyst | Wayne Zhao, Qi Yang

TokenInsight provides customized services such as commercial due diligence, project analysis, industry research, and more. For more information, please contact bd@tokeninsight.com or visit tokeninsight.com

Stable Outlook

AAA AA A BBB BB B CCC CC C D

Low Risk Moderate Risk Large Risk High Risk

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

Token MTV

Tags General platform - Sharding

Crowdfunding time 2019.04.03 22:00（Singapore time）

Crowdfunding price(USD) 1MTV=0.006USD

Investment range Min:180 USD, Max 3,600 USD

Token type ERC-20

Total number of tokens 10 billion

Initial liquidity 0.98 billon

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

2

V IEWPOINT① MultiVAC is a public chain that uses sharding to achieve capacity

expansion. Currently the architectural design of the project has achieved network, transaction, computational, and state sharding; on the mining and calculation layers, VRF is used for dynamic re-sharding, organically splitting shards, innovating through PoS and other mechanisms, while ensuring security and self-expansion capabilities. The project's technological architecture is complete, and the plan is far-reaching, yet at the same time it faces relatively great development difficulties.

② The architecture of MultiVAC's All-Dimension Sharding technique is quite innovative, especially around the design of its full network ledger data storage and control separation systems. These systems plan to use process less data while performing more efficient and securer verification functions that will add to modification and cross-shard communication, lightening miner storage loads and internally transferring burdens. This plans to lower ledger scaling and network transmission volumes, thus in its design accomplishing All-Dimension Sharding.

③ The UTXO model makes it difficult for smart contracts that need state preservation and have relatively low space usage rates. MultiVAC plans to use a PoIE consensus mechanism to let a smaller number of nodes execute its computational task verifications, ensuring the reliability of the computation process and its results. Related work is currently in the development process, and smart contract design results still need to be delivered and verified by the public.

④ The MVM virtual machine and the LLVM architecture it relies on will allow MultiVAC to support more commonly used programming languages; this functionality makes it significantly more convenient for external application development. However, as more detailed development becomes innovated, documents and a series of additional development tools, modules, testing tools, environments and so on must also be provided. Respectively, this creates a huge need for more guided input and support.

⑤ The operating effects of MultiVAC's virtual machine in an actual environment is still unknown and to be determined.

⑥ The token economic model details with respect to node incentives and punishment have yet to be revealed.

⑦ In terms of the core team, MultiVAC is relatively strong compared with similar projects at the same industry, especially around technical expertise and background experience.

⑧ Currently MultiVAC is in the 2nd development stage of its testnet, which is planned to be release in Q2 2019, with the mainnet to hoping to go online in Q3 2019.

CONTENTS

Viewpoint 2

Industry Analysis 4

MultiVAC 7

Token Economy 14

Team and Investment Organizations

16

Competitors 18

Social Activity 20

LIMITATIONS AND DISCLAIMERS

1. TokenInsight Inc. hereby makes the following statement in connection with the issuance of the rating report:

2. There is no relationship between TokenInsight Inc. (including TokenInsight Rating Project Team Members, and Review Committee Members) and the subject of this rating would affect the objectivity, independence, and impartiality of the rating.

3. The project team members of TokenInsight Inc. take their due diligence obligations seriously and have a good reason to ensure that rating reports followed the principles of objectivity, truthfulness, and impartiality.

4. This report is an independent judgment made by TokenInsight Inc. in compliance with applicable laws, regulations and reasonable internal credit rating processes and standards, and there are no changes in rating opinion due to improper influence of the rating target or any other organization or individual.

5. All information contained herein is obtained by TokenInsight Inc. from sources believed by it to be accurate and reliable. Because of the possibility of human or mechanical errors as well as other factors, however all information contained herein is provided “AS IS” without warranty of any kind. TokenInsight Inc. checks verifies, as necessary, the authenticity, accuracy, completeness, and timeliness of the information relied upon in the rating report, without making any representations or warranties, express or implied, as to authenticity, accuracy, completeness, timeliness and feasibility and appropriateness for any commercial purpose.

6. The inclusion of a credit rating or secondary market price analysis in this rating report should and can only be interpreted as an opinion and not as a statement of fact or a recommendation to buy, sell or hold any token.

7. The risk ratings indicated in this rating report are valid from the date of issuance of this report until the date of the next adjustment; at the same time, TokenInsight Inc. will periodically or irregularly track the ratings of the rating recipient to determine whether to adjust the credit ratings and will publish them in a timely manner.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

3

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

4

01 . INDUSTRY ANALYSIS

1.1 the Scalability Bottleneck of Public Blockchains

Currently, the underlying design of blockchains' are unable to fulfill the needs of large-scaling applications."

Decentralization, security, and scalability requirements and bottlenecks can't all be fulfilled and solved at the same time; this is what is known as blockchain's "impossible triangle". Currently, existing public chains, such as Bitcoin and Ethereum, are already relatively mature in terms of decentralization and security, but in terms of scalability, they have continually experienced difficulties in making technological breakthroughs.

Bitcoin's block time is 10 minutes; its peak TPS is about 6; transfer confirmations take about an hour (needing 6 blocks to confirm). Ethereum's block time is 15 seconds, and its peak TPS is about 20. Currently, centralised platforms have achieved peak TPS around the hundreds of thousands. The December 2017 Cryptokitties and the July 2018 Fomo 3D fiascos are examples of the Ethereum network being clogged due to problems in scaling.

By partially lowering the degree of decentralisation through the use of DPoS and BFT consensus mechanisms, projects such as EOS and Tron have reached TPS values above 2,000, which basically satisfy current throughput requirements. However, their operating processes have revealed problems with insufficient CPU usage, or the price of RAM being too high. These problems have revealed that the current underlying functions of blockchains' are unable to fulfill the needs of large-scaling applications.

1.2 Sharding

Sharding is most hopeful to realise a high-performance expansion plan that does not lower the degree of decentralisation."

Sharding technology can enhance scalability in a context where the degree of decentralization is not sacrificed and has good application prospects. Sharding uses a "divide and rule" concept. As shown in Figure 1-1, sharding is the process of taking existing transactions or state information in a blockchain and dividing them into 'n' shards according to certain rules, with each shard forming its own chain to separately process transactions or calculations from the original blockchain. Originally, all nodes within the entire network were needed to confirm all transactions or changes around state information throughout the entire network; after sharding, nodes within a given shard only need to verify a portion of the entire network. This shrinks the radius of consensus distribution and raises the performance of low-level chains.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

5

INDUSTRY ANALYSIS

‣ Figure 1-1: Sharding Principles Source: TokenInsight

1.3 Types of Sharding

Network sharding is the foundation of transactions and state sharding."

Sharding is generally divided into categories such as networks, transactions, and state sharding. Network sharding is the foundation of transaction and state sharding. Only being able to achieve network sharding and transaction sharding won't result in a qualitative leap within a blockchain; logically, the state sharding technique is a possible scalability solution designed to solve this problem.

Before Sharding

After Sharding

‣ Figure 1-2: Sharding Types

Type Description

Network ShardingAt the network layer, nodes are divided into different shards; network sharding is the foundation of transactions and state sharding.

Transaction Sharding

The entire network's transactions are divided into different shards to be verified and packaged; different shards within the network can simultaneously package and verify different transactions, processing in parallel, thus raising the performance of the entire network.

State Sharding

Storing complete ledgers in different shards, each node no longer needs to save the entire blockchain's state information; each shard's own portion of state information is stored internally. State shards include smart contract shards and storage shards.

Source: TokenInsight

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

6

INDUSTRY ANALYSIS

1.4 Technical Challenges for Sharding

Currently, sharding technology has yet to enter a state of maturity; there are still many challenges that exist within shards, between shards, and at the system layer."

Sharding projects that exist within the current market number in the teens, with a group of them set to have their mainnet to launch online in 2019; MultiVAC being one of them. Looking at the progress of each project overall, currently, sharding technology is still in a stage where the functionality and concepts are being tested; whether or not these projects can achieve improvements in public chains via sharding remains yet to be seen. These projects face many challenges within sharding as well as at the system layers around it.

WRAP-UP Currently, the underlying facilities within blockchain systems are unable to fulfill the needs of larger-scaling applications, and sharding is most current cohesive concept to realize a high-performance expansion plan that does not restrict the degree of decentralization. Currently sharding technology has yet to become mature; there are many challenges surrounding this technology, between shards, and at the system layer level.

‣ Figure 1-3: Challeneges Faced by Sharding Projects

Area Challenges

Within Shards

Double-spending attacks within shards

Node number limitations and Sybil attacks

Between Shards

Double-spending attacks between shards

Overloading problems with cross-shard transactions

System Level

Single point overheating problems

Dynamic adjustment problems

Source:�TokenInsight

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

7

02 . PROJECT ANALYSIS2.1 Basic Information on MultiVAC

At the current stage, a large number of projects are unable to attain significant improvements in performance whilst at the same time guaranteeing the security and decentralisation of the blockchain. Sharding projects, through their special characteristic of parallel processing, it has become a viable solution with great potential for solving the problem of blockchain scalability. MultiVAC is only one of a number of projects that works mainly with sharding technology. Compared with other projects based upon sharding technology, MultiVAC's biggest advantage is that it's sharding technological solution plan is fast, effective, and comprehensive.

According to the description provided by MultiVAC's sharding yellowpaper, the project has achieved sharding within areas of computation, storage, and transmission. Differences in each project's technological architecture and linguistic descriptions lead to different projects having names for different dimensions or extents of sharding that are discordant. For this reason, TokenInsight will use its own research framework for sharding technology to discuss the achievement of different sharding dimensions and their extent published in this report. Although the concrete dimensions and shard names within MultiVAC's sharding yellowpaper have their own names, the actual content of these categories are consistent.

Sharding can be divided into three dimensions: network sharding, transaction sharding, and state sharding.

For network sharding, MultiVAC uses a verifiable random function (VRF) to guarantee the randomness of its sharding process and the random allocation of mining nodes within each shard to solve the problem of security associated with each shard after each sharding process. At the same time, the MultiVAC network uses a dynamic sharding mechanism; after a certain amount of time passes mining nodes are reassigned automatically to other shards. If a certain shard is "overloaded", it can conduct a split, becoming two shards.

For transaction sharding, MultiVAC has adopted the UTXO model. When a transaction is confirmed, it only needs to confirm that the UTXO input is the output of another UTXO; remaining UTXO outputs are directly recorded to the receiving address within its shard ledger. This allows for avoiding a problem seen within the traditional ledger model, where there is a need to lock the state of accounts that initiate transactions and wait for those transactions to be confirmed before unlocking them; in theory this can greatly add to the speed of cross-shard transaction processing.

For state sharding, MultiVAC maintains the flexibly provided by the Merkle Tree style storage for transactional data and blocks to reduce storage pressures upon mining nodes. Mining nodes only store block header data; the completed ledger is stored by storage nodes. In order to guarantee the security of data, the storage of ledger data (storage nodes) and "control rights" (mining nodes) are separate. Aside from this, in an ordinary situation, each shard's storage nodes are only responsible for storing information related to specific sharding addresses and do not need to store the entire ledger.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

8

PROJECT ANALYSIS

2.2 Network Nodes In the MultiVAC blockchain network, there exists three network node types: light nodes, storage nodes, and miner nodes. Light nodes can be understood as normal participants throughout the network, in the transaction phase as initiators of transactions. Mining nodes are miners in the network, the transaction phase providing transaction confirmation and block packaging services. Storage nodes are responsible for storing transaction data produced by users and providing a guarantee of security for data.

2.3 Sharding Dimensions

2.3.1 Network Sharding

VRF guarantees the randomness of sharding and dynamic sharding further guarantees sharding security."

Network sharding refers to randomly dividing portions of the blockchain network into subgroups, with each subgroup being a "shard". In theory, it should be an unbiased sample of all total nodes. Random division means that the security of each shard will be ensured.

In a PoS network, guaranteeing the randomness of each shard can effectively protect the network's security. If when dividing, the network's nodes are randomly assigned to shards, then two situations can arise: first, if the node's future shards can be predicted, this means that attackers can make preparations, such as bribing nodes that create important blocks, and then conducting an attack upon the network; second, if the division of shards on the network is uneven, this will lead to collateralised tokens on some shards being more in number than on other shards. For the shards which have fewer collateralised tokens, the cost to attackers is lower, which influences security in a negative way.

In a PoS network, guaranteeing the randomness of each shard can effectively protect the network's security. If when dividing, the network's nodes are randomly assigned to shards, then two situations can arise: first, if node's future shards can be predicted, this means that attackers can make preparations, such as bribing nodes that create important blocks, and then conducting an attack upon the network; second, if the division of shards on the network is uneven, this will lead to collateralised tokens on some shards being more in number than on other shards. For the shards which have fewer collateralied tokens, the cost to attackers is lower, which influences their security negatively.

For the problem of sharding randomness, MultiVAC has adopted a VRF and dynamic sharding approach.

VRF solves the problem of the distribution of mining nodes; through VRF all nodes have no way of knowing in advance which mining nodes will be assigned to which shards, and also have no way of bribing mining nodes in advance. For mining nodes themselves, they also have no way of knowing to which shards they themselves will be assigned. As MultiVAC uses a PoS consensus mechanism in order to resist Sybil attacks, at the same time for miners, deposit tokens for collateral are necessary for them to have rights to create blocks and receive rewards.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

9

PROJECT ANALYSIS

However, in order to avoid nodes in any given shard from gaining too much power, in the MultiVAC, the more tokens that are put up as collateral by a node, the higher the probability that it will be assigned to more nodes. The right given to create blocks within any shard will be the same as that of other nodes.

Dynamic sharding is based on VRF, which further prevents nodes from being bribed or "colluding". In the MultiVAC network, all mining nodes are rearranged into different shards after a certain period of time has passed (a few minutes) and mixes up their order and positioning. In this way, although there may be a situation where an attacker within a short period of time is able to overtake a shard, the entire network can, via resharding, can quickly break up the attacker's hold on the shard.

A point that must be considered in regards to sharding is that if a miner enters into a new node, in order to confirm transactions and package blocks, the miner needs to (in a very short timeframe) understand the newest state of the shard, that is, the newest UTXO ledger; at the same time the miner does not need to process a large amount of data in order to initiate the "mining" process.

MultiVAC allows miners to quickly switch between nodes in this way via splitting the rights of custodianship and control.

2.3.2 Transaction Sharding

Using the UTXO model, mining nodes are only responsible for processing relevant address transactions rather than all transactions, which in theory accomplishes parallel processing."

In a sharding blockchain system, the verification and recording for transactions between addresses is within a shard; the true difficulty is how to confirm and record transactions that are from different shards.

When resolving transactions between shards, in the account model, some projects use the method of locking accounts that are related into transactions in a new block, waiting for the new transactions to all be finished processing before updating the account's state. This kind of method can solve the problem of account transactions, but as each time the account must be locked, it makes for relatively large delays, especially for cross-shard transactions. There are also some projects that have chosen to add centralized processing nodes to solve the problem of information synchronization between shards, but this kind of solution is actually considered "pseudo-sharding"; the transfer volume of data between shards may be very large, but the performance of the network is again limited by the performance of the centralized processing node.

Understanding this in another way, the most important aspect of transaction sharding is how to guarantee that the additional data transfer cost of cross-shard transactions is much lower than the performance improvement brought about by parallel processing

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

10

PROJECT ANALYSIS

‣ Figure 2-1: Communication Cost and Efficiency Boost after Sharding Source: TokenInsight

MultiVAC uses a UTXO model like Bitcoin, rather than an account model. UTXO is relatively simple when compared to that of an account model. In the MultiVAC network, the mining nodes in each shard all have the newest state information about the addresses in the node, and for transactions between addresses within the node. There is only a need to verify the addresses' signatures unspent amount in order to confirm the transaction's veracity and reliability; there is no need to communicate with other shards.

When a transaction between addresses in different shards occur, in order to reduce system loads that cross-shard communication imposes as much as possible, each transaction's initiator is only permitted to have inputs to a single address within the shard, but output addresses are not limited in any way. The benefit of this is that as the miners in a given node have the node's date, and when they don't have to communicate with other nodes, they can quickly confirm a transaction's validity. Via limiting the input address sources, MultiVAC to a large extent has reduced the data to be transmitted between shards, and inturn raises the overall transaction processing power.

For this reason, in the MultiVAC blockchain network, there are only two parts of cross-sharding communication data. The first is that a small number of block headers' data must be synchronised between shards, and the second is that storage nodes, after a shard's internal state is updated. When communicating with other shards, it chooses to preserve the data transmitted relevant to their own shard. The volume of cross-shard communication data, therefore, is efficient, which means that although the number of shards may increase, the overall network can still smoothly expand.

As there is no perfect solution plan at the technological level, MultiVAC has chosen to sacrifice transaction flexibility in order to achieve performance enhancements for the entire network.

1. In fact, as for inputs that come from different addresses' transactions, in theory, they only need to be divided into two transactions; the first aggregates inputs from different shards into a single shard and then processes them normally; this can be done in MultiVAC design architecture.

Shard 1 Shard 2 Shard 3 Shard 4

Additional Cost of Communication between Shards

Efficiency Boost Yielded by Parallel Processing

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

11

PROJECT ANALYSIS

2.3.3 State Sharding

This section of the report contains MultiVAC's state sharding, mainly referring to storage sharding. Storage sharding is an extremely key element in MultiVAC's systematic design. First, the network ledgers detailed information is the responsibility of storage nodes; other light nodes and mining nodes don't store detailed account information. Mining nodes only need to store the necessary information abstracted for accounts within its shard, and other shards' information abstracts as well as other essential information1. Further, there is clear division of labour between storage nodes, with each storage node being only responsible for storing the information in its own shard instead of storing all the data for the entire network (mining nodes can choose to store data for the entire network, but they can also elect to discard data from other nodes, and only hold on to data from their own shard).

When a mining node needs historical account information, it must initiate a request to a storage node. Then, via its own stored partial information, it can verify the validity to the information provided by the storage node, with unverified information not being able to be used. This kind of structure makes storage nodes more similar to data service providers; they only store data, and do not have the rights to add, delete or modify it. The rights to investigate and delete data are reserved for mining nodes, but they do not have access to all the data. This kind of data storage is separated from "control rights" which protects the security of data and at the same time can also lighten the load on storage nodes.

2.3.4 Block Creation Process

In MultiVAC, transactions are initiated by light nodes, which after miner processing are saved by storage nodes. The following figure shows this process.

‣ Figure 2-2: Process of Transaction Processing and Block Creation Source: TokenInsight

1. Specifically speaking, mining storage nodes' information include all block headers which are used for mining calculation; miners in the next step of the Main Merkle Tree of all shards can flit to the newest block (the rightmost Merkle Path).

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

12

PROJECT ANALYSIS

When a light node initiates a transaction, and it is digitally signed, the transaction will be transmitted to each storage node in the shard, which after receiving it will use a special Gossip protocol to broadcast it to all other mining nodes in the shard.

Within the shard, different nodes through Byzantine methods will arrive at information consensus; the corresponding block header will be broadcasted to all miners on the network, to help the entire network's miners confirm possible later cross-shard transactions. As the miners only need to save block header information, this greatly enhances the speed of data transmission and elevates the rate of data synchronisation between different shards. At the same time, in the long term, the barrier to becoming a miner is lowered, and more normal users will be able to join network miners, participate in the consensus process, and add to the degrees of decentralisation and security of the network.

2.3.5 Other Technological Characteristics

2.3.5.1 Flexible Sharding

In a normal situation (default allocation), when sharding is occurring within MultiVAC, the division of miners is equal; such as when there are 1,000 miners in the network, if the network is divided into 10 shards, every shard will have 100 (expected) miners. As the security within the shard is decided by miners, in theory, all shards should have the same level of security.

If for some computational tasks or special applications, there are higher security needs or if there is a need for faster processing but lower security, MultiVAC can flexibly allocate shards. That is to say, MultiVAC provides a flexible computation model that can be selected by different DApp designers to decide their own tradeoff between decentralization, scalability, and security.

If granted some computational tasks or special applications, there are higher security needs for if there is a need for faster processing, but lower security, MultiVAC can flexibly allocate shards. That is to say, MultiVAC provides a flexible computation model that can be selected by different DApp designers to decide their own tradeoffs between decentralization, scalability, and security.

Next, if one adopts a flexible sharding design, then due to different security levels between shards, some shards due to focus on security will forfeit processing speed, and some shards may seek to achieve higher processing speeds and not have such high-security requirements. As for the ordinary users in these shards, this may impact their user experience.

Last, through VRF-based random sharding and elastic sharding, a priority problem arises. In the actual execution process, completely random sharding and elastic sharding are a bit opposite; there is the problem at the execution layer of how to determine priority level and maintain the efficacious operation of the system -- this is currently still awaiting approval.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

13

PROJECT ANALYSIS

2.3.5.2 Smart contract and virtual machine

MultiVAC uses a virtual machine called the MVM (MultiVAC Virtual Machine) which is similar to the virtual machine in Ethereum. MultiVAC also supports Turing-complete programming languages, and also uses GAS to solve the problem of malicious users wasting computational resources in the execution of smart contracts (such as malicious code running loop attacks).

What is different from Ethereum is that MultiVAC uses an open-source RISC-V instruction set upon which it has built a custom-made and flexible instruction set BISC (Blockchain Instruction Set Computer). Currently, the MultiVAC plans to support C/C++ for writing smart contracts; in the future, it may support more higher-level programming languages.

Smart contracts and virtual machines need to run on top of the foundation of the above-described flexible calculation; only a portion of the nodes will perform operations such as compiling and running smart contracts. This is different from Ethereum in which all nodes execute smart contracts, which consumes a lot of network resources. However, this also gives rise to a problem, regarding how to ensure the accuracy of the portion of nodes that execute the contract, as well as of how other nodes in the network can arrive at a consensus for the results. For this reason, MultiVAC developed the PoIE (Proof of Execution Instruction) consensus mechanism, which is also called the command set execution consensus. It can be simply understood as a zero-knowledge proof that lets other nodes that don't perform the actual execution of the smart contract's code be able through PoIE to verify the result of other nodes' execution, confirming accuracy.

The largest potential problem that MultiVAC smart contracts face with virtual machines is that in the steps of actual execution whether or not they can actually achieve theoretical levels. As with the Ethereum plan at the start, it wasn't envisioned by many that there would be an Ethereum development bottleneck; MultiVAC a large number of unknowns; how the VM actually runs in practice, and the actual state of PoIE have yet to be put to the test.

Also, if MultiVAC wants to support a large number of applications, then it also very much needs to provide a series of supports for the authoring of smart contracts, such as detailed developer documents, making it convenient for developers to raise their development efficiency with a series of development modules, testing tools and environments, and so on. As TokenInsight understands it, this portion of content is in the MultiVAC team plan, but it's yet to be seen what will actually come forth.

WRAP-UP Overall, MultiVAC has in fact come forward with an actionable plan for sharding technology. Combining the state of code completion with testnet performance, a picture of the projects potential comes together. However, one must known that sharding technology is a method for solving bottleneck problems in public chain systems, but its implementation is quite difficult; according to TokenInsight's research, other projects that have planned to use sharding have found it too difficult and given up. MultiVAC's biggest problem is whether or not it can implement, and run in a real environment, as well as whether or not it can bring its theoretical or test performance to life.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

14

03 . TOKEN ECONOMY

3.1 Token Distribution The official token of the MultiVAC ecosystem is MTV, which is currently issued on the ERC-20 standard. The total supply is 100bn, of which the team and the foundation hold 42%. The first round of crowdfunding sold 700,000,000 tokens, 7% of total supply. Distribution of other specific amounts is shown in in Figure 3-1.

‣ Figure 3-1 MTV Token distribution Source: MultiVAC, TokenInsight

Advisor1.84%

Public�Sale7.00%

Seed8.96%

Private10.21%

Team15.00% Foundation

27.00%

Ecosystem30.00%

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

15

TOKEN ECONOMY

3.2 Vesting Plan Aside from the 7% of total token supply that has already been crowdfunded and immediately entered into the market, other portions of tokens have a clear vesting plan. Specific vesting plans are linear. Among them, the tokens assigned to the foundation and those for its ecosystem construction are on the immediate vestment track; primarily constituting 1.8% and 1% respectively. Thus, with the 7% crowdfunding portion, the initial circulating MTV, marketwise, is 9.8%. The remaining portion, that is seed round investment and private funding shall start from the fourth month and begin to unlock; the team and investor portions shall be unlocked from a year after the zero day. A concrete plan is shown in Figure 3-2, and 3-3.

‣ Figure 3-3: MTV Token Vesting Plan Chart Sources: MultiVAC, TokenInsight

‣ Figure 3-2: MTC Token Holder Vesting

Holder Vesting Plan

Team After 12 Months, Linear

Consultants After 12 Months, Linear

Seed Round Investors After 3 Months, Linear

Private Round After 3 Months, Linear

Fund Immediate, Linear

Ecosystem Immediate, Linear

Crowdfunding No Limitations Whatsoever

Sources: MultiVAC, TokenInsight

0%

33%

67%

100%

Initial 6th Month 11th Month 16th Month 21th Month 26th Month 30th Month

Seed Private Public Sale Foundation TeamEcosystem Advisor

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

16

04 . TEAM AND INVESTMENT ORGANIZATIONS

The team is mainly technical, and has consultants with strong experience."

According to official MultiVAC information, the MultiVAC team currently consists of 32 members, including three leaders, fifteen technical staff, six in operations, and eight consultants. The teams experience is mainly technical, and has consultants with replete experience.

‣ Figure 4-1 MultiVAC core team members

Member introduce

Frank LyuTechnical director and data engineering expert at Meituan-Dianping. Co-founder and CTO of Xinrenxinshi.com, the leading HR SaaS start-up in China with investment from Sequoia Capital.

Claire Wang

Marketing director of Xinrenxinshi.com. Co-founder of Julive.com. She created the best new-media and community brand in the Chinese vertical field of human resources, covering more than one million HR professionals.

Dr. Shawn Ying

Doctor of MultiVAC Algorithm Research. In 2013, he received a Ph.D. in computer science from Nanyang Technological University. He was a software engineer at Baidu from 2008 to 2009 and an associate professor at Tianjin University in 2014. He is currently the co-founder and CTO of MultiVAC.

Dr. Xiao Tong

Ph.D. in Statistics from Harvard University. A researcher in the field of probability, machine learning and big data. He is engaged in the development of quantitative trading strategies in top hedge funds.

Dr. Ge LiPh.D. in mathematics from the University of Sydney. An expert in group theory and cryptography.

Dr. Hong Sun

Ph.D. from the Microsoft Research Asia and Tianjin University (MSRA-TJU) joint program. A postdoctoral researcher at the Microsoft Asia Institute and an expert in AI. She is an application scientist at Microsoft Research (USA).

Dr. Minqi Zhang

Ph.D. in Computer Science at Nanyang Technological University. An expert on the applications of modern topology and applied mathematics in CS.

Koupin Lu Vice president of Goldman Sachs Co. in the Structured Finance and Investment Division.

Liang HeArchitect of Pinterest and Facebook. Senior engineer of Tencent. An expert in the field of large-scale distributed systems.

Shuzhi Huang

Google Senior Software Engineer, Tech lead/Manager of Android Google Search App (AGSA, the biggest Google app, over 1 billion downloads).

Source: MultiVAC，Linkedin

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

17

TEAM AND INVESTMENT ORGANIZATIONS

Large scale investors are participating with relatively large amounts of capital being invested."

According to official information from MultiVAC project, the group has gained investment from IDG, NCC, #HASHED and other large-scale investors; these investment organizations have real support and a large number of success projects. MultiVAC's investors mostly come from mainland China, the USA, and Korea, whilst there are also players from other countries. In terms of investors, MultiVAC has the support of many, a fact which obliquely refers to the project's development prospects and reliability.

‣ Figure 4-2: Investors and Partners of MultiVAC Source: MultiVAC

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

18

05 . COMPETITORS

MultiVAC is a front-running latecomer with definite strengths. The project currently is in a testing stage, and actual operation results await observation after officially coming online."

Each project has its own sharding solution and emphasis, as well as its own degree of difficulty. Figure 5-1 collects the contents of each project to represent its specific solution situation, but doesn't evaluate each project; for this reason the information is only for reference.

‣ Figure 5-1: Sharding Project Overview

Project Ethereum 2.0 Zilliqa QuarkChain MultiVAC

Sharding Types

Network, Transaction, Smart Contract, Storage

Network, Transaction, Smart Contract

Network, Transaction, Storage

Network, Transaction, Smart Contract, Storage

Consensus Method Casper FFG pBFT + PoW Multiple BFT Family

Smart Contract VM eWASMScilla interpreter

EVM etc. MVM

Smart Contract Language

Multiple ScillaDifferent VMs have different languages

LLVM Supports C/C++ etc

Project Stage Startup Mainnet Online Mainnet Imminent Testnet Online

Tested TPS Unknown 2,828 15,000 + 30,784

Time Online Undefined Jan 2019Estimated Apr. 2019

Estimated Q3 2019

Source: TokenInsight

Although sharding is currently one of the most hopeful solutions to expand on-chain capacity and scalability, its realisation is still quite difficult, especially for state sharding. Each project faces many challenges in the process of making it happen.

Ethereum 2.0's sharding architecture uses a Beacon Chain at its core, which is responsible for connecting the main chain and administering each shard. When the number of of cross-shard transactions in the system is too high, the Beacon Chain itself may become a performance bottleneck for cross-chain transactions. Ethereum 2.0 itself is in its first stages, and as it does not want to influence the current main chain's state when achieving expandability enhancement, and historical overloading has occurred, the community has yet to get on the same page.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

19

COMPETITORS

Zilliqa's sharding is single-layered, in its space it has a special DS Committee as well as other sharding structures. the DS Committee is responsible for confirming the results of the POW calculations submitted by each node allocated in different shards and achieving dynamic adjustment of nodes on the network. Currently Zilliqa has yet to achieve state sharding, and for this reason it faces the problem of insufficient storage. In order to solve the storage problem to a certain extent, Zilliqa has split nodes into two types, normal and storage nodes. Normal nodes only store user state information and not transaction information, with only seed nodes storing all ledger information; for this there is a corresponding incentive mechanism.

Zilliqa's sharding is single-layered, in its space, it has a special DS Committee as well as other sharding structures. The DS Committee is responsible for confirming the results of POW calculations submitted by each node allocated in different shards and achieves dynamic adjustments from nodes on the network. Currently Zilliqa has yet to achieve state sharding, and for this reason, faces the problem of insufficient storage. In order to solve the storage problem to a certain extent, Zilliqa has split nodes into two types, normal and storage nodes. Normal nodes only store user state information and not transaction information, with only seed nodes storing all ledger information; for this, there is a corresponding incentive mechanism.

QuarkChain has adopted a child chain + root chain style to achieve scalability improvement. The child chains process transactions, and the root chain is responsible for confirmation. QuarkChain runs its root chain with a priority PoW consensus mechanism; if one wants to conduct a 51% attack upon a shard, one needs to first attack the root chain, as the child chains obtain security protection from the root chain. QuarkChain currently has only achieved storage sharding within state sharding, and has not achieved smart contract sharding; every smart contract can only run in a single chain. The performance limits of smart contracts depend upon the performance of the shard.

QuarkChain has adopted a child chain + root chain style to achieve scalability improvement. The child chains process transactions and the root chain is responsible for confirmation. QuarkChain runs its root chain with a priority PoW consensus mechanism; if one wants to conduct a 51% attack upon a shard, one needs to first attack the root chain, as the child chains obtain security protection from the root chain. QuarkChain currently has only achieved storage sharding within state sharding, and has not achieved smart contract sharding; every smart contract can only run in a single chain. The performance limits of smart contracts depends upon the performance of the shard.

MultiVAC is a front-running latecomer with definite strengths. MultiVAC has designed a storage and transmission plan based upon Merkle Root distribution and has achieved ledger "custodianship" and "control" rights separation. Using simple and light data it can conduct high-efficiency and secure verification, improve the volume of modification and cross-shard communication, lighten the storage and transmission loads placed upon miners, and to a great extent lower the ledge scale and network transmission volume; through all of this it has achieved all-dimension sharding. It is currently in the testnet stage conducting testing; as for smart contract functions it is currently in development; the actual results achieved when the network formally goes online have yet to be observed.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

20

06 . SOCIAL ACTIVITY

MultiVAC's social community has the potential to rise."

According to TokenInsight's overview of various social axes, as of March 27, 2019 MultiVAC maintains 6,494 followers, with the largest bump of discussion having occurred between January 8th and 9th. On telegram, according to TokenInsight, as of March 27, the MultiVAC telegram group had 16,005 members; on the 26th MultiVAC's telegram had an explosion of activity, with 885 messages, making for a new high over the past three months. TokenInsight estimates that in the near term MultiVAC may have some technological or operational breakthroughs, and there may be a further heating up of social activity related to the project.

‣ Figure 6-1: MultiVAC Social Performance Source: TokenInsight Dashboard

‣ Figure 6-2: MultiVAC Social Wordcloud Source: TokenInsight Dashboard

New Telegram Chatters and Twitter Forwards

APPENDIX‣ Appendix 1 Symbols and Definition of Risk Ratings

AAAThe technical foundation is extremely solid, the status of operations is extremely stable, the extent of influence on the project by unfavorable changes in the environment or un- certain factors is extremely small, and risk is extremely low.

AAThe technical foundation is very solid, the status of operations is very stable, the extent of influence on the project by unfavourable changes in the environment or uncertain factors is very small, and risk is very low.

AThe technical foundation is solid, the status of operations is stable, the extent of influence on the project by unfavourable changes in the environment or uncertain factors is relatively small, and risk is relatively low.

BBBTechnical feasibility is very good, the status of operations is stable, influence on the project by unfavourable changes in the environment or uncertain factors exists to a certain extent, and risk is controllable.

BBTechnical feasibility is good, the status of operations is relatively stable, the possibility of influence on the project by unfavourable changes in the environment or uncertain factors exists to a relatively large extent, and risk is basically controllable.

BTechnical feasibility is moderate, the status of operations is relatively stable, the possibil- ity of influence on the project by unfavourable changes in the environment or uncertain factors exists to a very large extent, and risk is to a definitely limited extent controllable.

CCCThe technical foundation or idea has certain problems, the application scenarios are lim- ited, the project is susceptible to influence by uncertain factors, both internal and external, and has relatively large risk.

CCThe technical foundation or idea has considerable problems, and application scenarios are highly limited, which makes for a project that has few internal or external factors to consider in the context of sound development, and carries a very large risk.

CThe technical foundation or idea has substantial problems, and lacks deliberation upon possible application scenarios. The token has almost no usage value, and the project suffers from extremely large risk.

D The project is riddled with problems and carries an extremely high risk of failure.

TO

KE

NIN

SIG

HT

R

ES

EA

RC

H

21

TO

KE

N

INS

IGH

T

TokenInsight Inc.

Global Token Data & Rating Agency

Official Twitter Account WeChat Mini APP

TO OBTAIN THE LATEST DATA AND RATING REPORTS IN

BLOCKCHAIN INDUSTRY:

Website | www.tokeninsight.com

Cooperation | bd@tokeninsight.com

OTHER CONTACTS

WeChat Official Account | Tokenin

Official Twitter | TokenInsight

Official Weibo | TokenInsight

Official Telegram | https://t.me/TokenInsightOfficial