LiquidApps Whitepaper

Thursday, February 13, 2020
Download document
Save for later
Add to list

DAPP Network and DAPP Token Whitepaper Latest update: Feb 18th, 2019. Table of Contents Overview: Introducing LiquidApps & the DAPP Token 2 I. The vRAM System 4 II. vRAM System Components 6 III. vRAM Operation 7 Setup 7 Ongoing 7 Processing TXs with vRAM 7 IV. DAPP Service Providers (DSPs) 10 DSP Functionality 10 V. vRAM System Model 11 VI. DAPP Token Distribution Mechanism 12 Parameters 12 Distribution 12 VII. ​Founding Team 14 VIII. ​Roadmap 17 Summary 17 Risks 18 Disclaimer 22 This whitepaper is being provided by the LiquidApps Foundations ( L​ iquidApps​ or the T​ oken Generator​ ), for informational purposes only and is not a binding legal agreement. The purchase and supply of DAPP tokens ("​DAPP​" o​ r​ "​ D ​ APP Tokens​") shall be governed by written terms and conditions, which is a separate document that will be provided to purchasers who qualify to participate in the token generation event. This whitepaper may be amended from time-to-time. LiquidApps Whitepaper 1

Overview: Introducing LiquidApps & the DAPP Network LiquidApps’ mission is to promote mass scale adoption of decentralized applications (dApps), by introducing a set of technical solutions that make developing on blockchains substantially easier & affordable: the ​DAPP Network​ . While blockchain technology increases in both sophistication and awareness, it still remains difficult for people to utilize its potential. One reason for this disconnect is the lack of Decentralized Apps, or dApps which provide critical utility and engaging experiences for mainstream users. Killer apps are those which organically grow in usage to the point where a substantial segment of the population uses them on a regular basis - without necessarily having a deep understanding of the underlying technologies (such as the TCP/IP protocols behind the internet). While consumer applications like CryptoKitties demonstrate the current scaling challenges on platforms like Ethereum, a vibrant ecosystem of developers and dApps continues to evolve. Today, the most popular dApps are in the gaming, online-gambling and exchange categories - but tomorrow, their functionality and reach may be as vast as that of the Internet. As rivals to Ethereum’s blockchain platform dominance emerge, so do new technical challenges and opportunities. While the EOS blockchain introduces potentially unlimited scale and speed, the RAM and CPU resources needed to operate on the EOS blockchain are not cheap, are limited, and are expected to become even more so as a result of successful adoption - creating a chicken and egg constrained ecosystem. A technical solution is required to allow dApp developers to easily externalize CPU and RAM from the EOS blockchain and to utilize commonly required functionality in an accessible and affordable manner. LiquidApps is proud to introduce the DAPP Network native token known as D ​ APP​ , a multi-purpose utility token designed to power an ecosystem of utilities, resources, & services specifically serving the needs of dApp developers building user-centric dApps. LiquidApps Whitepaper 2

The DAPP Network paves the way for an entirely new class of decentralized applications to emerge -- those previously unimaginable due to the systemic limitations of the existing technology stack. By introducing a new ecosystem of collaboration and incentives, a long-tail of truly diverse, creative and useful dApps will likely emerge. In this whitepaper, LiquidApps introduces the first utility of the DAPP Token - the vRAM System. vRAM is an alternative storage solution for developers building EOS dApps that is compatible with the existing RAM system, decentralized, and enables storing & retrieving of potentially unlimited amounts of data affordably and efficiently. LiquidApps released the first key products powered by the DAPP Token to the community, seeding the tools for developers to build and create the DAPP Network. With this vision in mind, LiquidApps set a roadmap suggesting successive tools and services for developers which have the potential to contribute to dApp scalability. The growth of the DAPP Network aims to increase the ease, speed, and affordability of building scalable dApps on blockchains today. LiquidApps Whitepaper 3

I. The vRAM System The EOS blockchain​ represents a significant milestone in the advancement of public blockchains. With a market value of over $2,200,000,000 and approx. 10,000 new accounts added each week (as of Jan 14th, 2019), its sheer processing capability distinguishes it as well positioned to support the next wave of paradigm shifting dApps. The first use of the DAPP Token is built to enhance one of the core functional features of the EOS blockchain, RAM - a resource that is used to store data. In order to develop on EOS, dApp developers must own and use RAM. Currently, RAM usage is limited for two main reasons: it costs more than 58 EOS/1MB (as of Jan 14th, 2019) & it has a capped supply, which is currently ~90GB (anticipated to increase by Dec 31st, 2019 to 128GB), both severely limiting the capabilities of dApp developers and their applications. The vRAM system ( vRAM ) introduces three innovations for blockchain developers: 1. Affordable access to storage. 2. Potentially unlimited amounts of storage. 3. Off-chain processing with on-chain integrity. vRAM is an alternative storage solution for developers building EOS dApps that is RAM-compatible, decentralized, and aims to enable storing & retrieving of potentially unlimited amounts of data affordably and efficiently. Additionally, vRAM intends to remove the current correlation between the cost of memory (RAM) and the size of smart contracts (which need to be stored), by using RAM as cache memory. dApp developers today are restricted in their efforts to build on EOS because they struggle to pay RAM costs and/or their dApps require RAM that far exceeds the current ​total ​supply. With the introduction of LiquidApps Whitepaper 4

vRAM ​as a complement​ to RAM, dApp developers will be able to envision new types of decentralized applications and user interactions that today’s technical constraints prohibit. LiquidApps Whitepaper 5

II. vRAM System Components The vRAM system is comprised of the following main components: ● The DAPP Token​: The first utilization of the DAPP Token allows you to interact with RAM as cache memory. An EOS contract can only read and write data from actual RAM. In order to allow additional capacity, vRAM introduces a mechanism to load the data from vRAM to the RAM in a decentralized and trustless manner, using a DAPP Token. The DAPP Token will serve as the application access token to the vRAM system, enabling access and use of the system’s read and write functionality. The DAPP Token does not grant additional rights. The DAPP Token may be enabled on other blockchains as well and needs to be staked by the dApp developer in order to enable it to use vRAM. ● DAPP Token Smart Contract​: Manages the DAPP Tokens’ stakes which are required in order to access the vRAM System and enable its functionality. ● The vRAM Library​: Any smart contract which uses vRAM instead of RAM includes the vRAM Library which enables the User Contract to read and write in the same programmatic interface as RAM tables (multi-index tables). ● dApp Service Providers ( DSP )​: Anyone that operates a server running the DSP node (as defined below). DSPs may offer customized service packages that include: The amount of storage space offered for use, servers’ specifications, and the corresponding amount of DAPP Tokens one must stake in order to use each package ( DSP Service Package ). ● DSP Nodes​: The vRAM network consists of nodes which are operated by dApp Service Providers. DSP Nodes function as redundant and trustless stores of data in the network. Each node provides an EOSIO API service, to which dApps submit their transactions ( TXs ), in order to make the relevant data accessible to the contract before executing an action. ● User Contracts​: Smart contracts deployed by EOS dApp developers that include the standard code provided by LiquidApps (The vRAM Library) enabling compatibility and operation using vRAM. User Contracts interact with the vRAM System as long as the User Contract is equipped with sufficient amount of DAPP Tokens to support the dApp’s read/write demands. LiquidApps Whitepaper 6

III. vRAM System Operation A. Setup In order to use the vRAM System, a dApp developer needs to complete the following: 1) Integrate the vRAM Library into the User Contracts from which data will be written/read from the vRAM database. 2) Select the DSP Service Package/s that satisfies the initial dApp data storage and access requirements. 3) Acquire DAPP Tokens in the applicable amount to accommodate for the required data storage and access needs. 4) Stake the DAPP Tokens in the User Contracts through the vRAM Library, assigning the staked tokens to the specific DSP data storage and access package/s selected by the dApp developer. 5) You may utilize unused DAPP Tokens to vote for DSP/s that you believe support and strengthen the community. B. Maintenance Similarly to RAM, dApp developers are required to monitor their vRAM usage (and amount of DAPP Tokens staked) and change their chosen DSP Service Packages when needed in order to avoid service interruptions due to insufficient resources (e.g. too small of a Service Plan or insufficient DAPP Tokens staked). LiquidApps Whitepaper 7

C. Processing TXs with the vRAM System The process for executing a TX on a User Contracts is as follows: 1) A client sends a standard TX to a User Contract that uses vRAM. The TX is sent through a DSP node’s EOSIO API. 2) The DSP node detects all the data required by the TX, which is not found on RAM (since it is yet to be written there) but exists on vRAM (see above section 1): a) The DSP executes the action on a local synchronized EOS node b) The User Contract runs the transaction locally and when trying to access the required data, it throws an exception (assertion failure). If the data is missing from the RAM - this exception can be considered as a way to signal the DSP to request its services. c) The DSP catches the exception and parses the service request. 3) The DSP verifies that the dApp developer stakes the sufficient DAPP Tokens required. 4) The DSP node relays the data along with a cryptographic validity proof of the data to the User Contract. This is called a Warm-Up Request . 5) The User Contract verifies the cryptographic proof and loads the data to RAM. 6) The DSP sends the actual TX from the client to the User Contract. At this point, all the required data is in the RAM. 7) If the User Contract requires modification of data stored in vRAM, it dispatches an event with the new data which is caught by the DSP, that caches it locally. The new data is now present in the chain history. 8) The User Contract calculates and stores the signature needed for the cryptographic proof for the next read, and it also saves the data on RAM. 9) The User Contract signal the DSPs to evict the data from RAM (signaling is performed using the transaction output. (e.g. the console output field). 10) The DSP sends an action to the User Contract (cleanup), the User Contract deletes the data from RAM while leaving the signature to allow for verifying the integrity of the next Warm-Up Request. As stated above, no data is lost as it is part of the chain history. LiquidApps Whitepaper 8

D. Cross-Chain functionality of the vRAM System The vRAM System can also serve as shared memory in between chains. By passing vRAM data pointers (e.g. IPFS pointers) between chains they will be available to DSPs in more than one chain. This way, once IBC (Inter-Blockchain Communication) is available, the vRAM System will allow infinite "IBC bandwidth" in addition to its core functionalities. LiquidApps Whitepaper 9

IV. DAPP Service Providers (DSPs) Any individual or entity can become a DSP. DSPs maintain complete autonomy over all aspects of their operation. Each DSP can offer customized data packages accompanied by predefined terms determined by the DSP. The DSPs are incentivized by the DAPP Token inflation as defined below in the section DAPP Token Distribution Mechanism . A. DSP Functionality ○ Standard API endpoint of the EOS blockchain. ○ Warm-Ups: The User Contract holds a temporary cache (which is stored in the standard RAM). Whenever an action is called, the DSP simulates the action and gathers all the required data points needed by the action. Then, the DSP sends a Warm-Up Request - a request containing both the data points and a cryptographic signature for those data points. This request, after being verified by the User Contract, is loaded temporarily into the temporary RAM cache table. ○ Proof/data indexing for selected datasets: The actual vRAM data and proofs are effectively being stored on the chain history. In order to provide fast access for those elements when performing the Warm-Up Requests, the DSPs listen to the block history in real time and store the latest versions of different data points and proof in an accessible location (e.g. IPFS, S3, Disk, SQL). ○ DSPs allow for many additional custom external services, many of which will be created by the community, several are outlined in the roadmap section below. LiquidApps Whitepaper 10

V. DAPP Network System Model ● In order to gain access to the vRAM System and services facilitated by the DSPs, dApp developers must stake DAPP Tokens in the User Contracts. The amount of DAPP Tokens required in each User Contract should be the applicable amount of DAPP Tokens needed to accommodate the dApp’s read/write needs and should match the selected DSP package requirements. Note that the dApp developer may stake more than the minimum amount needed in order to vote for a specific DSP. ● A dApp developer may maintain multiple stakes of DAPP Tokens assigned to enable services from different DSPs. This is to ensure, among other things, service redundancy for potential cases of DSP unavailability. ● The DAPP Token Smart Contract generates new DAPP Tokens on an ongoing basis, at an annualized inflation rate that can range between 1-5% ( ​Inflation​ ) which will apply to the total supply of DAPP tokens. The DAPP Token Smart Contract allocates the Inflation to the DSPs pro-rata to the amount of DAPP Tokens staked and assigned to the DSPs. The said staked amounts are calculated on an accumulated block-to-block basis, and distribution is executed on a cycle basis. The inflation rate will be set initially at 2.71%, afterwhich, the Inflation may be updated from time to time by the community to an annualized inflation rate between 1% to 5%. ● In order to receive the Inflation DAPP Tokens, DSPs must claim the Tokens from the DAPP Generator Smart Contact. The first time a DSP can claim DAPP tokens is possible only a block after DAPP tokens were first staked to one of his Service Packages. Once the DSP claims the DAPP tokens, he will not be able to claim again until at least 24 hours have passed since his last claim and so forth. LiquidApps Whitepaper 11

VI. DAPP Token Distribution Mechanism A. Parameters ● SYMBOL: DAPP ● Total Supply: 1,000,000,000 (1 Billion), will be issued on the starting day, and distributed among the participants of the Vendor Smart Contracts in each cycle as detailed in section B. ● Transferable as soon as distribution begins. ● All DAPP Tokens are to be generated by the Token Generator and distributed through the Vendor Smart Contract. B. Distribution ● 50% of the total supply of DAPP Tokens will be sold in 444 sale cycles, over 333 days by two separate ​Vendor Smart Contracts​ hosted by or on behalf of the Token Generator. ○ There two Vendor Smart Contracts, offer a total amount of 1,126,126 DAPP Tokens per Cycle (an 18-hour cycle) (the C ​ ycle Quota​ ). Each Cycle Quota will be split evenly between the two Vendor Smart Contracts. ○ Participants may choose which Vendor Smart Contract they wish to purchase DAPP Tokens from, the Vendor Smart Contracts are on the EOS Blockchain. ○ Both Vendor Smart Contracts are similar in that both accept EOS and allocate DAPP Tokens to contributors. However, the difference is that one Vendor Smart Contract supports an instant purchase, while the other requires an on boarding procedure. ○ By the end of each cycle: ■ The Cycle Quota of DAPP Tokens is distributed to the cycle participants - pro-rata to the amounts sent in each of the two Vendor Smart Contracts. ■ Each individual Vendor Smart Contract sends the EOS tokens it received to the Token Generator. LiquidApps Whitepaper 12

For example: Cycle Quota: 1,126,126 DAPP Tokens Total EOS tokens received in that cycle: 10,000 EOS tokens Participant A sent an amount of 1,000 EOS tokens, meaning at the end of the cycle he received 1,000/10,000*1,126,126 = 112,612.6 DAPP Tokens. ● 10% of the DAPP Tokens will be Air-HODL (a vested airdrop) to the EOS community. Every EOS token holder on block number 36,568,000 will be distributed DAPP Tokens on a pro-rata basis (up to a maximum of 3 million EOS tokens) ( ​Pioneer Holders​ ). The amount of DAPP Tokens received by Pioneer Holders will continuously vest (on a block-by-block basis) over a period of 2 years starting from the day of the AIR-HODL, so that complete withdrawal of Tokens will be possible after 2 years. Any Pioneer Holder choosing to withdraw the Air-HODL-ed tokens before the end of said 2 years will only receive the vested portion (e.g. 25% of the distributed DAPP Tokens will be vested after 6 months). Any Pioneer Holder choosing to release (and\or sell) the Air-HODL-ed tokens before they are fully vested contributes the remaining unvested DAPP Tokens to those who are still holding their Air-HODL tokens, increasing the distribution for those remaining Pioneer Holders. However, Pioneer Holders can stake their vested DAPP Tokens to DAPP Service Providers, and by doing so, those Air-HODLed tokens will not be considered withdrawn. T​ he date of the Air-HODL will be published in a later stage. ● 10% of the DAPP tokens will be distributed to our launch partners, design partners, other partners, and advisors, with 1% (of the DAPP tokens) unlocked and the rest continuously vested (on a block-by-block basis) over a period of 2 years. However, unvested tokens may be staked. ● 10% of the DAPP tokens will be designated towards our grants and bounties programs, vested (on a block-by-block basis) over a period of 2 years. However, unvested tokens may be staked. ● 20% of the DAPP tokens will be distributed to LiquidApps and founders, with 6.5% (of the DAPP tokens) unlocked and the rest continuously vested (on a block-by-block basis) over a period of 2 years. However, unvested tokens may be staked. LiquidApps Whitepaper 13

VII. Founding Team Beni Hakak Co-Founder and CEO Beni is the CEO and Co-Founder of LiquidApps and LiquidEOS. He was formerly Director of Operations at Bancor and a strategic consultant manager at Ernst & Young. Prior to that Beni served in an elite technology unit of the Israeli Defense Forces and graduated from Israel's top technology institute, Technion, in Industrial Engineering and Management. Beni discovered blockchain three years ago & has been creating, advising, and working for companies in the space ever since. Tal Muskal Co-Founder and CTO Tal is the CTO of LiquidApps and is a senior technical advisor at Bancor, focusing on blockchain interoperability. He has co-founded numerous start-ups and brings over 30 years of experience in software development. Tal is an entrepreneur and advisor at the forefront of bleeding edge technologies from hardware and embedded systems to deep learning and cryptography. Eyal Hertzog Co-Founder Eyal is Product Architect at Bancor. He has been a leader in the cryptocurrency and consumer Internet spaces for the last two decades. Prior to his role at Bancor, Eyal founded a user-generated video site called MetaCafe and one of the first social networks in the world, Eyal has been active in blockchain since 2011 and gained a deep understanding of the scaling challenges faced by developers focused on building mass market dApps. LiquidApps Whitepaper 14

Galia Benartzi Co-Founder Galia is the Head of Business Development at Bancor. She has founded a number of startups and initiatives in both Silicon Valley and Israel, and was a Venture Partner at Peter Thiel’s Founders Fund. Galia is a leading figure in the crypto world having spoken at the United Nations, TedX & the Oslo Freedom Forum, amongst others, and is a passionate proponent of Israeli technology & diversity in the workplace. Guy Benartzi Co-Founder Guy is a Co-founder of Bancor, where he leads strategy and operational excellence. Prior to his role at Bancor, Guy co-founded four consumer Internet application companies and also served as their CEO through their acquisitions, including Mytopia and ParticleCode. Guy has been actively involved in blockchain and cryptocurrency for a number of years as an early adopter, entrepreneur and investor. Yudi Levi Co-Founder Yudi is the CTO at Bancor. He spearheads the technology creation team at Bancor, including development of smart contracts and overall architecture of Bancor’s and products. Prior to that, Yudi served as CTO of numerous venture-backed startups, including Mytopia, a social games business acquired by LSE: 888. Yudi served in an elite computing unit of the Israeli Defense Forces called Mamram. Miri Bikel Co-Founder Miri is an experienced legal authority on blockchain regulations and smart contracts, with proven expertise in assisting high profile cryptocurrency clients and token offerings across multiple jurisdictions. As a dual-qualified accountant and lawyer, Miri previously helped establish the tax practice of one of Israel’s largest law firms, Shibolet. LiquidApps Whitepaper 15

Shimon Erlichman Co-Founder Shimon has extensive experience in top management, strategy and technology in both the public and private sectors. He served for 25 years in Israel’s key government organizations. Since entering the private sector in 2007, Shimon has been an active tech entrepreneur. Until 2017, he was the Chief Executive Officer of FTK Technologies, a big data advertising company focused on the Indian market and is former director and investment committee member of The Trendlines Group. LiquidApps Whitepaper 16

VIII. Roadmap The DAPP Token is the access token to the DAPP Network’s services & for LiquidApps’ first product - vRAM, which solves a critical bottleneck for decentralized application development. The DAPP Network is built to support numerous use cases that continue to simplify the ability of both developers and users to interact with decentralized technologies. As usage grows and the DAPP Network evolves, additional functionalities could emerge, such as: ● DAPP Lending​: Enabling DAPP holders to lend their tokens to others, with a built-in expiration mechanism that removes the risk of default. ● vCPU​: A simple solution for the offloading of CPU intensive processes from the main chain to child chains. ● RAM-less Accounts​: A way to create RAM-free accounts on the EOS Blockchain, allowing for a free user on-boarding for the end-user. ● Variable Inflation​: Enabling DAPP Token holders to collectively reset the DAPP Inflation rates. ● IBC​: Inter-Blockchain Communication solutions. ● And more to come... Summary LiquidApps is proud to announce a patent pending innovation, the DAPP Token, which will power an ecosystem of developer products and services. vRAM, the DAPP Token’s first use case, will enable blockchain developers to affordably develop unprecedented dApps with potential for mass user appeal. By aiming to remove the financial barriers to entry & giving developers near unlimited access to data repositories, w ​ e believe vRAM will inspire a new wave of blockchain development​. LiquidApps’ intention is to inspire the community to build tools & services that empowers dApp developers communities and help blockchain based apps become critical parts of everyday life world-wide. LiquidApps Whitepaper 17

Risks The following is a list of highlighted risks, which may be relevant for you in making an informed judgment to participate in the DAPP Tokens sale, however such list is not and should not be deemed to be an exhaustive or a complete list – other material risk factors may well exist. If any of the following considerations, uncertainties or material risks develops into actual events the DAPP Tokens, User Contracts, DAPP Vendor Smart Contracts, DAPP Token Smart Contracts, vRAM System and the vRAM Library could be materially and adversely affected, and you may lose all or part of your DAPP Tokens or the usability thereof. Regulatory Risk The blockchain technology allows new forms of interaction. There is a possibility that certain jurisdictions will apply existing regulations, or introduce new regulations addressing blockchain technology based applications, which may be contrary to the current setup of the DAPP Tokens and the Users Contracts and DAPP Token Smart Contracts, and which may, inter alia, result in substantial modifications of their use and the envisioned DAPP Token ecosystem, including its termination and the loss of the DAPP Tokens for you. Risk of Software Weaknesses The software underlying the DAPP Tokens, the mechanism controlling the purchase procedure, the vRAM System and related Users Contracts and DAPP Token Smart Contracts, and other involved software, technology and technical concepts and theories are still extremely novel, which is why there is no warranty that the process for receiving, use and ownership of DAPP Tokens and/or use of any products will be uninterrupted or error-free, and which is why there is an inherent risk that the software and related technologies and theories could contain weaknesses, vulnerabilities or bugs causing, ​inter alia​, the complete (or partial) loss of the DAPP Tokens, and loss of all (or part of) EOS tokens used for their purchase. Risk of Abandonment / Lack of Success Even if the standard code provided by LiquidApps and the vRAM System are adopted, the creation of DAPP Token Smart Contracts and Users Contracts and their continuing development, if at all, by any LiquidApps Whitepaper 18

relevant party who may contribute to such development from time to time, may be abandoned for a number of reasons, including, but not limited to, lack of interest from the public, lack of funding, or lack of commercial success or prospects (e.g. caused by competing projects). Therefore there are no assurances, even though the DAPP Tokens are fully developed and launched, that you will receive any benefits through the DAPP Tokens held by you. Third Party Risk The DAPP Token Distribution and the feasibility of Users Contracts, DAPP Token Smart Contracts and the DAPP Token ecosystem as a whole depend on the actions of third parties. Therefore, there is no assurance that such third parties will ever adopt the use of DAPP Tokens or develop or adopt any Users Contract or DAPP Token Smart Contracts, including the vRAM System, DSPs or that the development, deployment and use of Users Contracts or DAPP Token Smart Contract will ever take place as foreseen, or be successfully executed, and that the DAPP Tokens might never have use. LiquidApps may use third parties to manage and operate the DAPP Token distribution and KYC/AML processes, in whole or in parts. LiquidApps has no control over the process employed and the requirement from you made by such third parties. Risk Associated with DSPs Any individual or entity can become a DSP. DSPs maintain complete autonomy over all aspects of their operation. Each DSP can offer customized data packages accompanied by predefined terms, all as determined by the DSP. LiquidApps has no control and no monitoring capabilities with respect to the DSPs whatsoever, including, without limitation with respect to their identity, reliability, content or quality of services, etc. Therefore, there are no assurances with respect to the DSPs and their services. Risk Associated with other Applications The standard code provided by LiquidApps to create Users Contract and DAPP Token Smart Contracts, including the vRAM System and vRAM Library, may give rise to other, alternative projects and applications, promoted by unaffiliated third parties, under which DAPP Tokens will have no intrinsic value, while they may be more widely used. Existing market participants may oppose the development LiquidApps Whitepaper 19

of distributed ledger or blockchain-based systems like the Users Contracts and the DAPP Token Smart Contracts. Risk Associated with Theft, Digital Wallets and Loss of Private Key Cryptographic tokens, including DAPP Tokens, can only be accessed by using an appropriate Wallet Address with a matching private key. If your private key file was lost or stolen, the allocated DAPP Tokens associated with your Wallet Address would be unrecoverable and would be permanently lost. Cryptographic tokens based on distributed blockchains, including DAPP Tokens, cannot be controlled by a single entity. Therefore, LiquidApps has no control over the ​DAPP Tokens, and you will have no recourse to seek any refunds, recovery or replacements from LiquidApps in the event that ​DAPP Tokens are lost or stolen. As a result you should take great care that the website used to purchase DAPP Tokens has the following universal resource locator (URL): h ​ ttps://​. Failure to use the official Website and follow such procedures may result you do not receive any DAPP Tokens, and loss any EOS tokens used for the purchase attempt. Risk of Protocol Attacks The software underlying the DAPP Tokens, the mechanism controlling the purchase procedure, as well as any Users Contracts, including the vRAM System, and other involved software and technology may be exposed to attacks or exploited by hackers or other individuals that could result in theft or loss of DAPP Tokens or the EOS tokens used for their purchase, impacting i​ nter alia t​ he ability to distribute the DAPP Tokens and the incentives to develop and launch the Users Contracts and the DAPP Token Smart Contracts. As with various other cryptographic tokens, the blockchain used for the DAPP Tokens is susceptible to attacks pertaining to its protocol. Any successful attack presents a risk to the DAPP Tokens, any Users Contract any DAPP Token Smart Contracts, and their expected proper execution and sequencing. Risk of Depreciation Concerning the D ​ APP Tokens, no market liquidity may be guaranteed and the value (if any) of the D ​ APP Tokens over time may experience extreme volatility or depreciate resulting in loss that will be borne LiquidApps Whitepaper 20

exclusively by you. Risk Associate to KYC\AML You acknowledge, understand and accept that certain transactions may require KYC/AML to be conducted by a third party. Accordingly, your transaction could be delayed and/or may not be approved. This process may cause your transaction not to be included in a specific Cycle and/or at the time you expected, meaning the transaction may be included in a different Cycle with a different price. Risk Associate to Distribution and Quote Cycle The distribution of DAPP Tokens will occur at the end of each Cycle (as described above) and only after claiming the DAPP Tokens. The actual amount of DAPP Tokens purchased by you depends upon the actions of all other users sending EOS tokens to the DAPP Token Smart Contracts during the same Cycle. All users sending EOS tokens during the same Quote Cycle will receive a relative amount of the Quota, on a pro rata basis, calculated in accordance with the amount of EOS tokens paid by each buyer in proportion to the total amount of EOS tokens paid to the DAPP Token Smart Contracts during the same Cycle. It is possible for other people to send in a large amount of EOS tokens after you have sent EOS tokens, and dramatically decrease the number of DAPP Tokens to be distributed to you. Therefore the price displayed on the sale segment in the website at a given time, is not the closing price of the Cycle, and reflects only the price calculated at that time out of the transactions then approved, which price will definitely change after you (and or others) transfer additional EOS tokens to the Vendor Smart Contracts and be final only following the calculations made based on all approved transactions at the end of the applicable Cycle.The EOS blockchain may be subject to delays and latencies. Accordingly, EOS tokens contributed to the DAPP Token Smart Contracts in the final moments of a Cycle may not get included for that period. You acknowledge, understand and accept that the EOS blockchain may not include your transaction at the time you expect and you may not be able to enter a specific Cycle and or receive the DAPP Tokens you have purchased at the same Cycle or same day you send EOS tokens. LiquidApps Whitepaper 21

Disclaimer The DAPP Tokens are utility tokens and are not intended to be offered as securities, units in a business trust, units in a collective investment scheme, or other financial instrument each as defined under applicable securities laws. This whitepaper is not intended to constitute an offering of securities, a solicitation of investment, a prospectus or offering document in any jurisdiction. This whitepaper does not constitute or form part of any opinion on any advice to buy, or any solicitation of any offer by LiquidApps to purchase any DAPP Tokens, nor shall it or any part of it nor the fact of its presentation form the basis of, or be relied upon in connection with, any contract or investment or transaction decision and shall not substitute consulting with professional advisors including tax advisors who shall take into account each person’s specific information and needs. No person is bound to enter into any contract or binding legal commitment in relation to the sale and purchase of the DAPP Tokens or any other cryptocurrency on the basis of this whitepaper. Any agreement between L​ iquidApps ​and the purchaser of DAPP Tokens shall be governed by a separate contract setting out the specific terms and conditions applicable to said transaction. The information contained in this whitepaper has not been reviewed, examined or approved by any regulatory authority. LiquidApps has not, and will not, seek review, examination or approval of any of the information contained in this whitepaper under the laws or regulations of any jurisdiction. The publication or distribution of this whitepaper does not imply that applicable laws, regulations, or rules have been complied with. Unless it is indicated that the statement is a statement of fact, all statements in this whitepaper, LiquidApps’ website, and in any communication channels (including but not limited to Telegram, Medium, Email etc.) or otherwise made by LiquidApps or its authorized representatives in any media including but not limited to statements about LiquidApps, DAPP Tokens, vRam, and any strategies, plans, prospects and industry trends - are forward-looking statements . LiquidApps Whitepaper 22

Such forward-looking statements are provided to allow the opportunity to understand LiquidApps’ beliefs and intentions in respect of the future without assuming any responsibility or liability in that regard and without guaranteeing, in any way, that such forward​-looking statements are complete or will end up being accurate. These statements are not guarantees, undertakings or obligations of any kind with regard to future performance and undue reliance should not be placed on them. These statements are only predictions and may change as time passes. Furthermore, actual events or results may differ materially from those projected, inter-alia, as a result of the external environment, (including but not limited to changes in political, social, economic, regulatory, and stock or cryptocurrency market conditions). We do not assume any obligation to update such information. Ⓒ LiquidApps 2019 LiquidApps Whitepaper 23