hashload.io white paper v0.3 subject to change

WHITE PAPER hashload.io white paper v0.3 subject to change March, 2018

TABLE OF CONTENTS 1. PROBLEM DEFINITION... 4 1.1 INDEXING OF DATA... 4 1.2 INSECURE THIRD PARTIES... 4 1.3 AVAILABILITY OF DATA... 5 1.4 TRUST IN UPLOADERS... 5 1.5 REMUNERATION OF UPLOADERS... 5 1.6 ENCRYPTION AND SECURITY... 5 1.7 COMMITMENT TO PROVIDERS... 5 2. HASHLOADS SOLUTION... 5 2.1 INDEXING DESPITE ENCRYPTED DATA... 5 2.2 NO POSSIBILITY TO DELETE DATA... 6 2.3 MAXIMUM FILE SECURITY... 6 2.4 TRUSTED UPLOADS AND REPUTATION... 6 2.5 FLEXIBLE PRICES, UNLIMITED ACCESS, ANONYMITY... 6 2.6 INCENTIVES FOR UPLOADERS... 7 2.7 FAIR REMUNERATION FOR PROVIDERS... 7 2.8 CLOSED SYSTEM, NO THIRD PARTIES... 8 3. ARCHITECTURE AND DEVELOPMENT... 8 3.1 STRUCTURE... 8 3.2 HASHLOAD CLIENT... 11 3.3 SMART CONTRACTS... 12 3.4 IPFS... 12 3.5 USENET SERVER... 12 3.6 HSH TOKEN... 13 3.7 ROADMAP... 13 4. MARKET ANALYSIS... 14 4.1 GLOBAL, GROWING MARKET... 14 4.2 INCENTIVES FOR USERS... 15 4.3 INCENTIVES FOR PROVIDERS... 15 4.4 INCENTIVES FOR FUNDERS... 15 4.5 BUSINESS MODEL... 16 5. MARKETING AND STRATEGY... 17 5.1 INVISIBLE HAND... 17 5.2 TRUST... 17 5.3 LOYALTY PROGRAM... 17

6. CROWDSALE... 17 6.1 TOKEN STRUCTURE... 18 6.2 DISTRIBUTION OF TOKENS... 19 7. LEGAL DISCLAIMER... 20 7.1 GENERAL INFORMATION... 20 7.2 KNOWLEDGE REQUIRED... 20 7.3 RISKS... 20 7.4 IMPORTANT DISCLAIMER... 21 7.5 REPRSENTATION AND WARRANTIES... 22 7.6 ARBITRATION... 22 8. REFERENCES... 23

Executive Summary HASHLOAD combines the technology of the blockchain with the established and powerful server network of Usenet and creates a marketplace where users and providers come together anonymously, decentralized, and securely. The Usenet is a decentralized network consisting of thousands of constantly synchronizing news servers. It is the oldest, still existing network for the exchange of messages and files and can act independently of the Internet. All news servers are decentralized and permanently replicate their data so that they are available worldwide and can be downloaded at maximum speed. In contrast to a web server, the Usenet cannot be switched off due to its decentralized structure. Even if the news server on which the original file was uploaded is disconnected from the network, all files are still fully available via the remaining news servers. The binary news servers allow files to be uploaded without any restrictions in format, size or subject matter, resulting in a very large amount of data. On average, 37.35 TiB of data was uploaded to Usenet daily in January 2018 [1]. Tendency continues to rise. In comparison to peer-to-peer networks or direct downloads in which all participants are known, downloads from the Usenet are generally completely anonymous and cannot be traced. 1. PROBLEM DEFINITION Despite this impressive technology, the following problems currently exist. 1.1 INDEXING OF DATA Since all news servers are in exchange with each other, it is possible for each participant to index the file names (headers) of the uploads. This is generally to be supported, as it simplifies the search for files considerably. However, this also allows censorship by removing certain uploads from the Usenet. To counteract this, uploaders encrypt their files in such a way that the file name does not allow any inference to the underlying file. Therefore, most of the existing indexing is useless. 1.2 INSECURE THIRD PARTIES To work around this problem, communities and forums have formed in which the actual content of these files is posted. However, access to these communities is complicated, partially restricted and poses a security risk, as one must trust an unknown third party and their security standards. These communities are also centralized and do not allow any exchange among themselves, meaning that information is only available to users in fragmented form and that Usenet, which is actually decentralized, is increasingly less connected. 1 https://www.altopia.com 4

1.3 AVAILABILITY OF DATA As a result of the above-mentioned points, it is not possible to upload files to Usenet and simultaneously make them available to a large community without running the risk of the file being deleted due to legal claims or censorship. 1.4 TRUST IN UPLOADERS The Usenet in its current form does not offer any option of a position of trust for uploaders or an evaluation function for the files offered. Wrongly named uploads, spam or even malicious code such as viruses or Trojans can only be uncovered as such after downloading. 1.5 REMUNERATION OF UPLOADERS There is no transparent system that gives uploaders an incentive for high-quality uploads. Therefore, current content is often first offered on alternative platforms with a remuneration model. 1.6 ENCRYPTION AND SECURITY Even if most of the files offered are encrypted, this encryption was not performed by the system itself, but by the respective uploader. It must be performed manually and is, therefore, susceptible to errors and cannot be read in the event of a lost or unknown password. Therefore, passwords must be made public, which is absurd. 1.7 COMMITMENT TO PROVIDERS Access to binary news servers is only possible through commercial providers offering different pricing models. Often the most economically viable option is an inflexible and long-term commitment. While access to the server via SSL and VPN access is secured to the highest current level, the traditional payment method makes it possible to draw conclusions about the identity of the user. 2. HASHLOADS SOLUTION The decentralized server structure of the Usenet is extended by means of the blockchain with a decentralized reputation and payment model and thus establishes a completely transparent but at the same time autonomous, convenient and secure marketplace for the exchange of files. 2.1 INDEXING DESPITE ENCRYPTED DATA For the uploader, it is no longer necessary to manually encrypt the file name (header). The file can be provided with a clear name and is encrypted completely autonomously. Nobody but the network itself knows the name with which the file is transmitted to the servers. Not even the 5

uploader himself. This makes it possible to perform indexing without running the risk of the file being identified on the servers. Targeted access to the file is only possible via the HASHLOAD network, which then decodes it autonomously and transfers the file as submitted by the uploader. 2.2 NO POSSIBILITY TO DELETE DATA Since the header with which the file was stored on the servers is known only to the HASHLOAD network, the file on the servers can only be identified by the network itself. Targeted deletion is therefore impossible for both the uploader and a third party. The data remains available on the servers at least as long as the retention time has allowed. 2.3 MAXIMUM FILE SECURITY Even if a file cannot be identified from the header information, it can still be accessed by all Usenet servers through the redundant system. To ensure that packets are not automatically read to gain knowledge of the content and to ensure the security of the data, not only the file names are ciphered, but also the content is encrypted. The cryptography also takes place autonomously during the upload/download process, so that the files cannot be decrypted outside the system. If it is necessary to share files privately within the system and protect them from unauthorized access, it is also possible to set a private password, which is only known to the uploader. 2.4 TRUSTED UPLOADS AND REPUTATION The decentralized structure of the blockchain in combination with the autonomous functionality of the HASHLOAD network offers the possibility to evaluate the offered files and the corresponding uploaders without compromising security and anonymity. Thus, the community has the possibility to warn others about dubious offers via a negative rating or leave a positive rating. This helps to improve quality and enables the community to build a reputation. 2.5 FLEXIBLE PRICES, UNLIMITED ACCESS, ANONYMITY Before a file can be downloaded, the user can choose from a list of available partner providers. They offer different prices and services. For example, it may make sense to choose a provider that holds files for a particularly long time for a download, while the maximum speed plays a particularly important role for another download. All this can be selected flexibly and intuitively in the app. Either preset for all downloads or with an individual selection. The market regulates itself by supply and demand, and instead of choosing a provider long-term, the user has access to the best offer on the market at any time. The connection between user and server is encrypted end-to-end via TLS (E2EE) so that the transferred files cannot be read by third parties. 6

There are two payment models: Subscription The user is bound to a provider for a definable period of time and pays a fixed price regardless of the volume used. There is no need to select a provider for the specified period. This corresponds to the classic payment model, but in addition to the extra HASHLOAD features, it also has the advantage that the identity of the user is unknown to the provider. Pay per download Instead of a fixed time defined offer, the providers bid for each upload and download. The user selects a provider before downloading. There is no time commitment to a provider, which encourages providers always to keep the best offer. The user does not need to pay in advance. With both payment models, neither the provider nor anyone else has knowledge of the identity of the user. The payments cannot be associated with a download due to the Payment Hub and allow complete anonymity about the network activities of the user. 2.6 INCENTIVES FOR UPLOADERS Just as the users make a provider selection before downloading, the uploaders also make a provider selection before a file is transferred to the servers. Here the providers quote the costs for the upload. In contrast to the status quo, however, the uploaders are rewarded for highquality uploads. Each time one of their files is downloaded, they automatically receive a portion of the price paid autonomously credited from the payment hub. Revenues can be used within the network or paid out in an anonymous currency. In combination with the reputation system that allows the evaluation of uploads and the data protection strategy, this is a strong incentive for uploaders to use the platform. 2.7 FAIR REMUNERATION FOR PROVIDERS Providers are encouraged to offer the best price/performance ratio to get the user excited about their own offer, just as it is the case in the current market. The price graduation is at the discretion of the provider and is regulated by supply and demand. The difference lies in the type of remuneration. Subscription The user is bound to a provider for a definable period of time and pays a fixed price. There is no need to select a provider for the specified period. Pay per download Instead of a fixed time defined offer, the providers bid for each upload and download. The user selects a provider before downloading. For providers, profitability increases because there are no bank and payment fees for traditional payment methods. The payment is made via the Payment Hub when the specified payment amount is reached. 7

2.8 CLOSED SYSTEM, NO THIRD PARTIES All these measures lead to the creation of a self-contained direct system, which does not require trust in a third party and works completely autonomously. Neither a News provider (NSP), a website (indexer, forum) nor the Internet provider (ISP) has knowledge about the activity of the user. All transactions and interactions take place within the network and are completely decentralized and anonymous. Users can find, pay, download and rate files without leaving the app and without having to worry about security or additional costs. Files that were previously shared in different communities now have a common basis, which will result in a significantly increased international offering. 3. ARCHITECTURE AND DEVELOPMENT 3.1 STRUCTURE The HASHLOAD network is based on the Ethereum Blockchain, which combines several important points and currently offers the most stable and practical solution. a. Strong community and ecosystem b. Various scaling roadmaps c. Compatibility with smart contracts and apps d. Simple integration through ERC20 standards The current average confirmation time is approximately 15 seconds [2] and an average of 20 transactions per second (TPS) is performed. In addition, each transaction in the Ethereum network requires a fee, which has to be paid in gas and varies according to volume and utilization. Since HASHLOAD wants to cover millions of users and simultaneous microtransactions, we have decided to implement a hybrid system that carries out the majority of transactions off-chain and only transmits hashes of these transactions to the blockchain. This not only ensures immediate transactions and current processes but also solves another problem. While we benefit from the transparency and possibilities of the blockchain in valuations and autonomous processes, the complete traceability of transactions is an undesirable side effect. In a conventional blockchain environment, everyone can see which transactions took place from which address. Seamless and permanent. We use a payment hub in order to guarantee the anonymity of the users and not to allow any traceability of persons, payments made or downloaded files. A payment hub is an N-party smart contract that can manage transactions from hundreds of thousands of accounts. Instead of passing the payment to the blockchain, the Payment Hub generates a hash that is used to authenticate the incoming payment and thus guarantees not 2 https://etherscan.io/chart/blocktime 8

only complete anonymity but also enables extreme scalability and growth of the network. It is therefore not visible to outside persons who made or received payment. The user benefits from maximum anonymity, fast performance, and low transaction costs. To ensure that files cannot be found outside the hash load network, we add an additional IPFS layer [3] containing a secured container (permissioned block) with another unique hash that can only be read by the hash load system and uniquely identifies a file. It is neither possible to identify a file by its header nor to find out the header of a file. Schematic structure App Authentification / Payment Hash Payment Hub Provider User Authentification Hash Usenet IPFS Container The central elements of the HASHLOAD network and their schematic structure. The communication within the network takes place via hash values so that the individual modules have no knowledge of the contents of the previous one but are nevertheless able to authenticate the requests. For a better understanding, the following is a process visualization based on upload and download. 3 https://github.com/autocontracts/permissioned-blocks/ 9

Process: Upload 1. Files / Provider 6. IPFS Container 7. App Feedback 2. Payment Hub 5. File Hash 8. File upload 3. Payment Hash 4. Encryption 9. Feedback (1) The user selects the files he would like to share, names them and chooses a provider to handle the process. Additional options are available, such as assigning a private password, excluding the file from the search and other individual adjustments. (2) Once all settings have been made, the payment / query is made to the Payment Hub. (3) The Payment Hub generates an individual hash for the transaction and authenticates the further process. The upload process is now initiated. (4) Independent of an individually assigned password, the file to be uploaded is now encrypted. This protects the content of the files outside the hash load network from unauthorized access. (5) The encrypted file now receives an individual hash that uniquely identifies the upload. This hash is not known to anyone, not even the uploader. (6) The hash is stored in a secured IPFS container. Access to this IPFS container requires authorization by the HASHLOAD app and is not publicly available. If the hash were stored in a smart contract, the state change would be visible to all participants in the network. Storage in IPFS object provides an additional level of security. (7) The HASHLOAD app now knows the IPFS container and creates an internal link (route) with the name assigned in step 1. (8) The file is now transferred to the provider selected in step 1 and loaded onto the Usenet servers. The hash generated in point 5 is transmitted as the header (file name). It is not possible to draw conclusions about the underlying file or the uploader. (9) The user receives feedback about the status of the process, and the file is available via the internal search of the hash load app, if not otherwise defined. 10

Process: Download 1. Files / Provider 6. App Feedback 7. Download 2. Payment Hub 5. File Hash 8. Decryption 3. Payment Hash 4. IPFS Container 9. Feedback (1) The user finds the file to be downloaded via the search / index of the hash load app and selects a provider. (2) Payment is made to the Payment Hub. A conclusion on the requested file is not possible because the Payment Hub manages all incoming payments off-chain and does not anchor them individually in the blockchain. (3) The Payment Hub generates an individual hash for the transaction and authenticates the further process. The download is initiated. (4) The hashload app contacts the IPFS container linked to the file and authenticates itself to view the content. (5) The stored file hash is read so that the file is now uniquely identifiable. (6) The hashload app now knows the name under which the file is stored on the Usenet servers and starts the download. (7) The file is downloaded with a temporary file name and checked for completeness. (8) When the download is complete, the file is decrypted and stored in the user's download directory. (9) The user receives a confirmation of the status of the operation and now has the option of rating the file. 3.2 HASHLOAD CLIENT The frontend consists of the graphically appealing and intuitively designed HASHLOAD app, which functions as an interface between user and backend. The app allows the user to anonymously upload and download files, search for files, filter and evaluate these results and perform secure transactions (inbound and outbound). The app is available across platforms for different devices. 11

In a later step, it is conceivable to provide an interface (API) that allows developers to develop their own filters and functions. 3.3 SMART CONTRACTS Smart contracts are a series of instructions that are completely decentralized and autonomous on the Ethereum blockchain and are written in solidity. In this way, commands can be executed that follow the "if this than that" logic. This makes it possible to start interlinked processes. A simple example would be: If payment is received, initiate download, otherwise cancel. The smart tokens are the link and coordinate all the functions covered in section 2. To ensure security and not infer to a) the underlying files and b) the users accessing them, we rely on a construct of N- party smart contracts that communicate with each other off-chain via encrypted values (hashes) and disguise the input-output addresses. Payments are managed by a payment hub [4] which can process and manage hundreds of thousands of parallel transactions off-chain, verify them using a hash and make payments to provider and user autonomously on-chain as soon as the defined payout amount is reached. 3.4 IPFS IPFS is a peer-to-peer network protocol that has been developed as an alternative to the serverdependent HTTP. Instead of referring to a file by addressing an exact path, the file is requested by a unique value (hash). The request is processed by a group of independent but communicating nodes and transmitted by the first IPFS node that holds the file. IPFS objects consist of a data structure of two fields. o Data unstructured binary data of < 256 kb o Links a link structure that refers to other IPFS objects We use this IPFS structure, but embed a container, a so-called permissioned block, within the IPFS object data store, which can only be read after successful authentication. The hash that uniquely identifies the file to be stored is stored in this block. Access to this container is only possible through successful payment and authentication. 3.5 USENET SERVER The files are transported to the news servers via an SSL secured connection using the NNTP protocol and stored there anonymously. All news servers replicate among themselves so that the data is available redundantly and decentralized. The great advantage of Usenet is that the servers are directly connected to the backbone of the Internet (Tier 1), allowing extremely fast data transfer. The limit is the download speed of the user ISP. 4 https://liquidity.network 12

The Usenet is unassailable. Even if a Usenet server were unavailable or if a state decided to take all servers in the state off the network, the Usenet would continue to function because the data is still stored and accessible on all other Usenet servers. 3.6 HSH TOKEN The HSH token is a utility token based on the Ethereum ERC20 standard which is limited to a quantity of 784,313,725 HSH and is issued at a unit price of 0.10 (~USD 0.12). The HSH token is a digital asset that determines its value itself and will not be used as a primary payment token in the HASHLOAD network. Instead, transactions are carried out using ETH tokens. This has several advantages, including: a. Broad acceptance and high availability b. Diverse wallets c. Safety features d. Steady global development e. Benefits outside the network After the productive launch of the HASHLOAD App and at the end of each calendar year, vouchers will be distributed to token holders on a pro rata basis of the number of tokens withheld from the generated fee fund, with which alternative payment in the HASHLOAD network will be possible. 3.7 ROADMAP This product development timeline roughly demonstrates HASHLOAD's intention to expand the network and make it accessible to a broad audience. An exact time window cannot be defined due to the mobile market and the development in the area of the blockchain. The steps are therefore not binding and may be subject to change. Step 1: Expansion of the team The success of the network depends decisively on whether the data exchange functions securely and reliably. It is therefore very important to expand the team in the areas of technology, marketing, and law. Timeframe: Middle - End of 2018 Step 2: Beta version The development of a working beta version that covers the most important function and allows the user to use the network securely and anonymously. Timeframe: Beginning of 2019 Step 3: Final version The completion of v1.0 in which all functions are implemented, and which guarantees a fast and smooth process. 13

Timeframe: Middle - End 2019 Step 4: Expansion of the market, optimization of the network Further development and optimization of the network and scaling of participants. 4. MARKET ANALYSIS Streaming of media plays an important role in our everyday life, and one could, therefore, conclude that the file-sharing market is declining as a result. Quite the opposite, in fact. The users' need to keep data personal is greater than ever. A crucial factor here is the constant decline in anonymity. Every provider (ISP) knows when and which data is consumed and therefore often only suggests suitable content. Data that the operator does not want (or cannot) make available to the user cannot be accessed. HASHLOAD revolutionizes the file-sharing industry by offering maximum efficiency with absolute transparency and anonymity. 4.1 GLOBAL, GROWING MARKET According to paloalto [5], file sharing takes up more than 6% of all data traffic worldwide every day, and this enormous amount of data only reflects the unsecured exchange (via, e.g., p2p). In this way, non-protocollable accesses, such as that of the Usenet, cannot be recorded at all, which is why the actual market size is significantly larger. In the Usenet primary market alone, 24 TB of new data are added every day, which can be processed via the HASHLOAD network in the future. According to Cisco, additional markets such as the Peer2Peer or OCH file sharing providers offer additional growth potential with a 6,717 PB market [6]. An increasing number of users are looking for alternatives such as HASHLOAD. 6 5 4 3 2 1 Consumer File Sharing (in PB per Month) 0 2016 2017 2018 2019 2020 2021 P2P file transfer Other file transfer Source: Cisco VNI, 2017 5 http://researchcenter.paloaltonetworks.com/app-usage-risk-report-visualization/#sthash.vdfvsor3.dpbs 6 https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/completewhite-paper-c11-481360.html 14

Entering this market early and thus having a decisive competitive advantage enables the market to be rapidly scaled and dominated. 4.2 INCENTIVES FOR USERS The HASHLOAD network offers its users a closed, anonymized system that does not require direct contact with a third party and yet can exploit the potential of the existing infrastructure. a. Maximum upload and download speed limited only by the user's ISP b. Permanent availability c. Flexible and transparent marketplace d. Loyalty program to reward network usage e. A network-customized client with an implemented convenience function that cannot currently be provided by any file sharing network, such as reputation and integrated indexing. f. A one-stop shop for all data available on the network (no fragmentation of the market) 4.3 INCENTIVES FOR PROVIDERS The HASHLOAD network offers partner providers a. access to new customers and a growing market b. an innovative form of sales and customer loyalty c. an additional source of income that is not regulated and influenced by banks and payment service providers d. absolute transparency of the services and payments used 4.4 INCENTIVES FOR FUNDERS The HASHLOAD network offers its funders a. to be part of a global and growing market that accounts for a significant share of global data traffic b. to purchase 70% of all ever existing HSH tokens, 51% of which are available during ICO crowd sales c. the ability to be involved in every transaction executed on the network d. pro-rata vouchers for token holders at the end of a calendar year that can be redeemed in the network 15

4.5 BUSINESS MODEL HASHLOAD develops and administers the application and the HASHLOAD infrastructure and makes this marketplace available to users and providers. In return, a fee of 2.5% is charged on the transactions distributed by the Payment Hub. About 1% - 1.5% is required to execute the smart contracts since the computing power must be paid for with gas. 0.5% go to the Token Fund. The remaining 0.5% 1% will be transferred to HASHLOAD as revenue. Simplified calculation example: The amount to be distributed corresponds to 0.20 ETH. After deducting the 2.5% commission that is subtracted, the remaining 0.195 ETH are transferred to the provider and the uploader. This results in the following figures Amount: 0.20 Of which commission 2.5%: 0,005 a. 1.25%: 0.0025 gas costs b. 0.5%: 0.001 token fund c. 0.75%: 0.0015 revenue Of which Usenet providers 95%: 0.19 Of which uploaders: 2.5%: 0.005 revenue distribution Provider Token Fund Revenue Uploader Gas 16

5. MARKETING AND STRATEGY 5.1 INVISIBLE HAND The HASHLOAD network sees itself as a marketplace where providers and users can come together. We strongly believe that a self-regulating market is always more stable and efficient than an externally controlled market. Free competition will ensure a market balance, and thus all participants in the network will benefit from it. This works best if as many providers as possible participate in the network. HASHLOAD's main priority is, therefore, to integrate the leading Usenet providers at the launch of the beta phase and thus offer the user a wide variety. Since the advantages for the providers (see point 4.3) pay off if they contribute early, we are confident of achieving rapid growth. We are already in positive talks with some providers. Depending on the crowd sale result achieved and the involvement of the providers, another option is that HASHLOAD itself becomes effective as a provider. 5.2 TRUST Anonymity and trust are two essential characteristics that play an important role in the filesharing market. Our rating function helps users to recognize only high-quality files that are trusted by the community. This value cannot be manipulated since the valuation function is only available for transactions that actually took place. The ability to move around the network completely anonymously is another elementary function that is very important to us and offers users a strong added value compared to other competitors. 5.3 LOYALTY PROGRAM HASHLOAD rewards active participation in the network and thereby promotes user loyalty. Users who share files benefit from their downloads and users who download the files collect loyalty points which they can use for transactions. 6. CROWDSALE The HASHLOAD Crowdsale takes place on the Ethereum platform and is executed via smart contracts. Participants wishing to support the development and publication of the HASHLOAD network can purchase HASHLOAD Tokens (HSH). After payment in Ether (ETH), the tokens are transferred to the buyer at a rate of 3,700 HSH to 1 ETH. This amount is subject to change before the token creation event. 17

Project Description The HASHLOAD network is a file sharing marketplace where users and providers can find each other anonymously and comfortably in a self-regulating market. Crowdsale start date To be announced Crowdsale end date To be announced Token symbol HSH Token architecture ERC20 Accepted currencies for the ICO ETH Token price 0.10 (~USD 0.12) HSH qualification Utility Token Maximum number of HSH 784,313,725 Soft cap 25,000,000 HSH (~ 2.5M) Hard cap 400,000,000 HSH (~ 40M) Total % of public tokens 70% Of which % of tokens for ICO crowdsale 51% Of which % of tokens for bounty / 10% promotion Of which % of community fund tokens 9% % tokens reserved for business interests 30% Accepted currency during the ICO Ether (ETH) 6.1 TOKEN STRUCTURE The HSH Token is an ERC20 Utility Token based on Ethereum, which can increase its value by its underlying assets, properties and / or associated rights. The Ethereum infrastructure ensures a. security and planning of the blockchain b. access to a large number of wallets (ERC20 token) A maximum of 784,313,725 HSH tokens will be available. Tokens that are not sold during the Crowdsale will be burned automatically by the smart contract. During the sale purchase bonus may be applied which will announced before the start of the event. 18

6.2 DISTRIBUTION OF TOKENS Tokens 9% 10% 30% 51% Business Interests ICO Crowdfund Bounty Program Community Fund a. 70% of all generated tokens are made available to the public A growth of the HASHLOAD network is only possible if all parties have full confidence in the project. More than 2/3 of all tokens are publicly distributed and managed by the community. b. 51% of public tokens are issued during the initial token sale More than half of all tokens are offered at the ICO crowd sale. This ensures that the community and the initial investors already have the majority of the tokens at the start of the project. The earnings generated help to finance the network in the coming years. c. 10% of public tokens are used for bounty and ICO promotion Strong public relations work is indispensable for the economic success of the Crowdfund and is in the interest of all participants. Users who are already involved before and during the ICO will be rewarded with these tokens. d. 9% of public tokens are used for the community fund Long-term commitment and active participation in the HASHLOAD network will be rewarded. The community fund is used to motivate the active members of the community. e. 30% of tokens are reserved for business interests These include the points mentioned in point 3.6 regarding the development and especially the maintenance of the HASHLOAD network, as well as the long-term expansion and the development of further markets. These tokens are held for the long-term and are the foundation of the network. 19

7. LEGAL DISCLAIMER 7.1 GENERAL INFORMATION Please read the following notice carefully before proceeding to read this Whitepaper document issued by HASHLOAD. The publication, distribution or dissemination of this Whitepaper does not imply that the applicable laws, regulatory requirements, or rules have been complied. The HASHLOAD token does not have the legal qualification of a security, since it does not give any rights to dividends or interests. The sale of HASHLOAD tokens is final and non-refundable. HASHLOAD tokens are not shares and do not give any right to participate to the general meeting of HASHLOAD. HASHLOAD tokens cannot have a performance or a particular value outside the HASHLOAD Network. HASHLOAD tokens shall therefore not be used or purchased for speculative or investment purposes. The purchaser of HASHLOAD tokens is aware that national securities laws, which ensure that investors are sold investments that include all the proper disclosures and are subject to regulatory scrutiny for the investors' protection, are not applicable. Anyone purchasing HASHLOAD tokens expressly acknowledges and represents that she/he has carefully reviewed this white paper and fully understands the risks, costs and benefits associated with the purchase of HASHLOAD. Acquiring of the HASHLOAD tokens (also called HSH Tokens or HSH ) is available only after accepting the Terms of token sale (hereinafter T&C ). If you have any doubts as to which action you should take, please consult with your technology, financial, legal or other professional advisors. This notice applies to all persons who read this document. Please note this notice may be altered or updated. 7.2 KNOWLEDGE REQUIRED The purchaser of HASHLOAD tokens undertakes that she/he understands and has significant experience of cryptocurrencies, blockchain systems and services, and that she/he fully understands the risks associated with the crowdsale as well as the mechanism related to the use of cryptocurrencies (incl. storage). HASHLOAD shall not be responsible for any loss of HASHLOAD tokens or situations making it impossible to access HASHLOAD tokens, which may result from any actions or omissions of the user or any person undertaking to acquire HASHLOAD tokens, as well as in case of hacker attacks. 7.3 RISKS Acquiring HASHLOAD tokens and storing them involves various risks, in particular the risk that HASHLOAD may not be able to launch its operations and develop its network and provide the services promised. Therefore, and prior to acquiring HASHLOAD Tokens, any user should carefully 20

consider the risks, costs and benefits of acquiring HASHLOAD Token in the context of the crowd sale and, if necessary, obtain any independent advice in this regard. Any interested person who is not in the position to accept or to understand the risks associated with the activity (incl. the risks related to the non-development of the HASHLOAD network or any other risks as indicated in the Terms & Conditions of the crowd sale should not acquire HASHLOAD tokens. 7.4 IMPORTANT DISCLAIMER This white paper shall not and cannot be considered as an invitation to enter into an investment. It does not constitute or relate in any way nor should it be considered as an offering of securities in any jurisdiction. This white paper does not include or contain any information or indication that might be considered as a recommendation or that might be used as a basis for any investment decision. HASHLOAD tokens are just utility tokens which can be used only on the HASHLOAD network and are not intended to be used as an investment. The offering of HASHLOAD tokens on a trading platform is done in order to allow the use of the HASHLOAD platform and not for speculative purposes. The offering of HASHLOAD tokens on a trading platform does not change the legal qualification of the tokens, which remain a simple means for the use of the HASHLOAD network and are not a security. HASHLOAD is not to be considered as advisor in any legal, tax or financial matters. Any information in the white paper is given for general information purpose only and HASHLOAD does not provide with any warranty as to the accuracy and completeness of this information. Given the lack of crypto-token qualifications in most countries, each buyer is strongly advised to carry out a legal and tax analysis concerning the purchase and ownership of HASHLOAD tokens according to their nationality and place of residence. HASHLOAD is not a financial intermediary according to law and is not required to obtain any authorization for Anti Money Laundering purposes. HASHLOAD tokens confer no direct or indirect right to HASHLOAD s capital or income, nor does it confer any governance right within HASHLOAD; a HASHLOAD token is not proof of ownership or a right of control over HASHLOAD and does not grant the controlling individual any asset or share in HASHLOAD, or in the HASHLOAD network. A HASHLOAD token does not grant any right to participate in control over HASHLOAD s management or decision-making set-up, or over the HASHLOAD network and governance to the Purchasers Regulatory authorities are carefully scrutinizing businesses and operations associated to cryptocurrencies in the world. In that respect, regulatory measures, investigations or actions may impact HASHLOAD s business and even limit or prevent it from developing its operations in the future. Any person undertaking to acquire HASHLOAD tokens must be aware of the HASHLOAD business model, the white paper or terms and conditions may change or need to be modified because of new regulatory and compliance requirements from any applicable laws in any jurisdictions. In such a case, purchasers and anyone undertaking to acquire HASHLOAD tokens acknowledge and understand that neither HASHLOAD nor any of its affiliates shall be held liable for any direct or indirect loss or damage caused by such changes. 21

HASHLOAD will do its utmost to launch its operations and develop the HASHLOAD network. Anyone undertaking to acquire HASHLOAD tokens acknowledges and understands that HASHLOAD does not provide any guarantee that it will manage to achieve it. They acknowledge and understand therefore that HASHLOAD (incl. its bodies and employees) assumes no liability or responsibility for any loss or damage that would result from or relate to the incapacity to use HASHLOAD tokens, except in case of intentional misconduct or gross negligence. 7.5 REPRSENTATION AND WARRANTIES By participating in the crowdsale, the purchaser agrees to the above and in particular, they represent and warrant that they: have read carefully the terms and conditions attached to the white paper; agree to their full contents and accept to be legally bound by them; are authorized and have full power to purchase HASHLOAD tokens according to the laws that apply in their jurisdiction of domicile; are neither a US citizen or resident; live in a jurisdiction which allows HASHLOAD to sell HASHLOAD tokens through a crowdsale without requiring any local authorization; are familiar with all related regulations in the specific jurisdiction in which they are based and that purchasing cryptographic tokens in that jurisdiction is not prohibited, restricted or subject to additional conditions of any kind; will not use the crowdsale for any illegal activity, including but not limited to money laundering and the financing of terrorism; have sufficient knowledge about the nature of the cryptographic tokens and have significant experience with, and functional understanding of, the usage and intricacies of dealing with cryptographic tokens and currencies and blockchain-based systems and services; purchase HASHLOAD tokens because they wish to have access to the HASHLOAD network; are not purchasing HASHLOAD tokens for the purpose of speculative investment or usage. 7.6 ARBITRATION The Client acknowledges and accepts that the HASHLOAD ICO operation is taking place within a legal environment that is still under development. The Parties agree to seek an amicable settlement prior to bringing any legal action. All disputes arising with the with papers provided, shall be resolved by arbitration. The arbitration panel shall consist of one arbitrator only. The arbitral proceedings shall be conducted in English. 22

8. REFERENCES [1] https://www.altopia.com [2] https://etherscan.io/chart/blocktime [3] https://github.com/autocontracts/permissioned-blocks [4] https://liquidity.network [5] http://researchcenter.paloaltonetworks.com/app-usage-risk-reportvisualization/#sthash.vdfvsor3.dpbs [6] https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networkingindex-vni/complete-white-paper-c11-481360.html 23