Como ler um whitepaper de criptoativos

Um whitepaper é o documento que um projeto publica para explicar o que está a construir. Não existe norma sobre o que deve conter, ninguém o revê antes da publicação e nenhuma regra exige que se mantenha rigoroso depois. É um documento de marketing que por vezes contém engenharia. Lido assim é genuinamente útil; lido como um prospeto, induz em erro.

Comece pelo fim

Leia primeiro a secção do token, seja qual for o nome que tenha. Costuma ficar perto do fim e é a parte que descreve o que estaria de facto a comprar: o que o token faz dentro do sistema, como surgem as unidades, quem as recebeu antes de si e segundo que calendário essas posições se tornam transferíveis. Se o documento explica longamente uma tecnologia e descreve o token em dois parágrafos vagos, esse desequilíbrio é a informação mais útil que lá está.

Pergunte que problema é resolvido, e para quem

Um bom documento enuncia um problema que existe independentemente da solução proposta e que quem o tem reconheceria. A vaguidade aqui não é um defeito de estilo. Se a formulação do problema só faz sentido depois de aceitar o sistema que está a ser vendido, pode não haver problema nenhum fora do documento.

Separe o que está construído do que está planeado

Os documentos descrevem rotineiramente componentes acabados, parciais e hipotéticos no mesmo presente do indicativo. Marque o que é o quê à medida que lê e confirme depois cada alegação contra algo exterior ao documento — um repositório público, um contrato implantado, uma rede de teste a funcionar. Um roteiro é uma declaração de intenções, não o registo de coisa alguma.

Encontre os pressupostos de confiança, que raramente têm secção própria

Todo o desenho depende de algo: de os validadores se comportarem, de uma fonte de preços ser honesta, de uma ponte, de uma empresa que detém reservas, de uma chave de administração capaz de alterar o código. Um documento sério nomeia-os e diz o que acontece quando cada um falha. Se nada no documento pode falhar, não está a descrever um sistema.

Trate a equipa e os avais como alegações a confirmar

Pessoas identificadas com percursos verificáveis significam que o projeto tem algo a perder. O anonimato não desqualifica automaticamente, mas retira essa garantia, e o documento tem de compensar noutro lado. Logótipos de parceiros, exchanges, auditores e investidores são alegações, não provas: confirme cada uma na fonte que supostamente a fez, porque reproduzir um logótipo não custa nada.

As partes que pode saltar

Secções introdutórias que explicam blockchains em geral, longas comparações com redes estabelecidas e tudo o que seja apresentado como oportunidade de mercado dizem-lhe algo sobre a escrita, não sobre o projeto. O mesmo vale para matemática decorativa: se as equações não fazem trabalho de que o argumento à volta dependa, são composição gráfica.