Interest in ICO continues to grow. Hundreds of startup projects worldwide are trying to raise funds using this technology. The market has already established its own ICO guidelines and one of them insists upon the creation of a special document, “a white paper”. Every team needs to provide a project description in the course of ICO using this document. Today we will talk about the correct way to do this.
What is a White Paper?
The white paper is a document determining the technology of a blockchain project. This file usually contains a detailed description of the system architecture and its interaction with users, as well as current market data and growth anticipations and requirements for the issue and the use of tokens. In addition, it provides a list of project team members, investors and advisors.
Without a proper modelling of a white paper it would be difficult for a project team to perform a successful ICO procedure : few people would be willing to invest in a project lacking proper information on the technology and on the previous business experience of team members. You may find some tips on creating a high-quality white paper, and several real successful examples below.
What Should this Document Look Like?
Andrew Chapin (Chapin Andrew), blockchain expert and the founder of projects Benja.co and Ship Ninja, described the perfect white paper in a Hacker Noon column. This article is a good guide to the white paper. So, let’s sum it up here.
A good white paper should have the following sections:
- a problem;
- a proposed solution and the product description;
- a description of the token commercialization (product interaction with economy and technical provisions of commercialization);
- team members;
- tokens issue and perspectives.
One of the most important elements of the white paper is usually the information on the project team, despite the fact that it is frequently placed at the end of the document.
According to Chapin, any investor-angel can tell stories about investing in a strong team with a bad idea, because he believed in their abilities of creating a valuable product in the course of their activity. For example, before its pivot, Android used to be a camera operating system. Nokia dealt with woodworking and paper production before and Pinterest, at the very start of its career, used to be a shopping app and it wasn’t a social network (although recently it has returned to its e-Commerce origins).
Therefore, it is crucial that the team should be multi-professional, and should already have had some success. In a perfect world, they should also have at least some experience in the blockchain domain. Quite often, teams try to launch fundraising when they don't have competent engineers dealing with the blockchain. The founders consider money-raising to be the most important task and they are pretty sure they can employ an engineer later on. But you should look before you leap, because until investors become eager to donate money to the project, they need to be convinced that the team is able to create what they had planned.
The second section of the white paper should contain the product description: prototype data, first users and development strategy. Frequently, in the course of ICO the project team only have a perfectly designed pdf and a few mock-ups. Yet, they have no actual product, its potential users and development strategy. If the project already has an ecosystem and users, this increases the chances of token survival on the market. These elements must therefore be present in the documentation.
A detailed plan of the use of funds is also essential. Today, in the world of ICO, there are a lot of organizations which mention "industrial consortias", non-profit units or events related to "industry development". This may raise suspicions that a member of the team intends to spend money not only on product development but also on something else (maybe on his or her personal needs).
The information on tokens is detailed during its offer at the stock exchange. If it is not introduced - or if the plan states that this will follow in 30-60 days - there is reason to believe that something is not going as expected. According to Chapin, in this case, it’s highly probable that the project team will manipulate the price of a token at the moment of a free trade opening. In general, the public is interested in the future cooperation of the company with issued tokens. In this situation some questions will need to be answered: Will the issue be limited before the pre-sale? When will sales start on the market? Will redemption (or buy-backs) be operated?
It’s vital that the white paper also includes a detailed technical description of the project and its future development plans (development roadmap). In theory, the team should present a detailed working plan for the next 12-18 months, which should include the beta-launch. If some tasks of the roadmap have already been performed, that may be considered as an advantage for the project team.
A Perfect White Paper: 3 Examples of Successful Projects
Looking at best practice: the easiest way to understand the requirement for an ideal ICO document is to see real examples of successful projects. We have selected three very successful projects and analyzed their white papers (find more examples here).
Monetha is a project of a payment system for the blockchain. It collected $37 million (95 000 ETH) in just 18 minutes. Its white paper of their system contains all the abovementioned sections. It has a detailed description of the project’s working plan, token economy, fund-using plans, and also team members’ service record (even the previous business experience that raised investments). These details are crucial for all white papers.
Besides the technical description of the product architecture, there are also some easy-to-read diagrams
Another example is the project “Aeternity”, which collected nearly $34 million. Its white paper may give the impression that documentation does not need to be as comprehensive as we suggest. The file (see below) is not beautifully designed and is created in a research article pattern (a simple two-column document).
A research article pattern is really trustworthy. Besides, the document doesn’t have to be long (around 10 pages)
Finally, the winner, which collected $257 million during its ICO, is Filecoin. Its founders also decided to use a research article pattern without any design refinements of their white paper.
The presentation style corresponds to the pattern: a lot of formulae and different schemas
Final thoughts
We’ve been actively studying the ICO market recently. In particular, we are interested in the content design, which blockchain startups should choose. In conclusion we will give you some tips based on our surveys :
- A perfect white paper won’t help a bad project: if the project team proposes a solution to a non-existent problem or to a non-essential problem or if its members lack development experience and are not familiar with the blockchain, it’s highly probable that the project won’t be successful - even if its documentation is brilliant. Startup founders need to be aware of that.
- The pattern should suit the team: Filecoin and Aeternity, for instance, chose a research article pattern for their project description in contrast to a more "popular" pattern selected by Monetha. It is interesting to note that the "research article" doesn’t contain information on the project team. This information may be found on their website in a special section. To create a high-quality "research article", its author must have some experience in writing such documents. If experience is lacking, it is better to go Monetha’s way and make a project presentation.
- It is essential to take the public into account : the style and the pattern of the white paper depends on its readers. If your goal is to attract technically literate public and scientists, it is quite logical to present the information using a research article pattern. But if your goal is to interest a wider audience, you shouldn’t overcharge your document with scientific terms. But you can also create two versions of the document: the one for a wider audience and the other for those who want some more technical details.