Hoe lees je een cryptoproject-whitepaper en wat vertelt het je over het financiele risico?

Je krijgt een link doorgestuurd in een groepsapp: een whitepaper van een cryptoproject dat “de infrastructuur van Web3 gaat herdefiniëren”. De persoon die hem stuurt heeft er zelf ook maar een kwart van gelezen, maar is al overtuigd. Jij opent het document, ziet vijftig pagina’s vol jargon en diagrammen, en sluit het weer. Een week later staat het token op een grote exchange en is de koers verdubbeld. Drie weken daarna is hij negentig procent gezakt en hoor je er nooit meer iets over.

Dit is hoe de meeste mensen kennismaken met whitepapers: te laat, te vluchtig, of helemaal niet. Terwijl een whitepaper eigenlijk het enige document is waarin een project verplicht is uit te leggen wat het doet, hoe het werkt en waarom het bestaansrecht heeft. Je hoeft geen ontwikkelaar te zijn om er iets zinnigs uit te halen. Je moet alleen weten waar je op let.

Wat een whitepaper eigenlijk is en bevat

Een whitepaper is een technisch-economisch document waarin een cryptoproject uitlegt wat het bouwt, waarom, hoe en voor wie. Zie het als een combinatie van een ondernemingsplan, een technisch ontwerp en een economisch model. De meeste whitepapers bevatten een probleemstelling, een beschrijving van de technologie, tokenomics (hoe het muntsysteem werkt), informatie over het team en een roadmap.

Sommige zijn tien pagina’s lang, andere tellen meer dan honderd. Dat maakt ze niet automatisch beter of slechter. Wat telt, is wat erin staat en wat er juist ontbreekt.

Stap 1: Begin bij de probleemstelling

Het eerste wat je leest, is de beschrijving van het probleem dat het project oplost. Stel jezelf meteen de vraag: bestaat dit probleem echt, of is het bedacht om een token te rechtvaardigen?

Een eerlijk project beschrijft een concreet knelpunt met aantoonbare data. Denk aan hoge transactiekosten bij bestaande blockchains, gebrek aan privacy bij bepaalde betalingen, of inefficiëntie in een specifieke sector zoals logistiek of gezondheidszorg. Een verdacht project beschrijft het probleem vaag, gebruikt veel superlatieven en noemt geen bestaande oplossingen of concurrenten. Alsof het probleem nieuw is en alleen zij het kunnen oplossen.

Vraag jezelf ook af: waarom heeft dit probleem een blockchain nodig? Veel projecten zouden het probleem makkelijker kunnen oplossen zonder gedecentraliseerde technologie. Als dat antwoord ontbreekt in de whitepaper, is dat al een eerste waarschuwingssignaal.

Stap 2: Ontleed de tokenomics

Tokenomics beschrijft hoe de tokens verdeeld zijn en hoe de totale hoeveelheid tokens in de tijd verandert. Dit is een van de meest onderschatte risicofactoren bij crypto. Let op drie zaken.

Ten eerste de verdeling. Wie krijgt welk percentage van alle tokens? Een project waarbij het team en vroege investeerders samen meer dan 40 procent bezitten, is risicovol. Zodra hun tokens vrijkomen, kunnen zij massaal verkopen en de prijs doen instorten.

Ten tweede het vestingschema. Tokens worden vaak niet in één keer vrijgegeven. Er is een zogeheten cliff-periode waarna tokens geleidelijk vrijkomen. Hoe korter die periode, hoe groter het risico op een snelle uitverkoop. Een cliff van zes maanden met een lineaire vrijgave over twee jaar is beter dan een cliff van drie maanden met onmiddellijke volledige vrijgave.

Ten derde het inflatiemodel. Komen er steeds nieuwe tokens bij? Zo ja, hoeveel en hoe snel? Een hoge inflatie drukt de waarde van jouw tokens, tenzij de vraag even hard groeit. Zoek naar een grafiek van de supply-curve en vraag jezelf af wat er met de prijs gebeurt als het aanbod verdubbelt terwijl de vraag gelijk blijft.

Stap 3: Doorzoek het team en de adviseurs

Anonieme teams zijn niet per definitie onbetrouwbaar, maar ze maken het veel moeilijker om verantwoordelijkheid te eisen. Zoek de namen op LinkedIn, bekijk hun GitHub-profielen en kijk naar eerdere projecten. Hebben ze al eerder iets gebouwd en afgemaakt? Of hebben ze een patroon van mislukte of verlaten projecten?

Let ook op de adviseurs. Lange lijsten met bekende namen klinken indrukwekkend, maar controleer of die personen ook daadwerkelijk betrokken zijn. Sommige projecten noemen adviseurs die niet eens weten dat ze op de website staan.

Stap 4: Lees de technische sectie als niet-technicus

Je hoeft geen programmeur te zijn om de technische sectie nuttig te vinden. Let op drie concrete dingen. Worden er verwijzingen gegeven naar auditrapportages van onafhankelijke beveiligingsbedrijven? Zijn de links naar open-source code echt en actief? En is de roadmap realistisch, met concrete mijlpalen en data in plaats van vage termen als “Q3: ecosystem expansion”?

Een solide project verwijst naar audits van bedrijven als Trail of Bits, CertiK of Consensys Diligence. Een project zonder enige verwijzing naar een audit is een risico, zeker als het gaat om smart contracts waar geld in zit.

Stap 5: Analyseer het governance- en consensusmodel

Governance gaat over de vraag: wie beslist straks over veranderingen aan het protocol? Als één entiteit of een kleine groep tokenhouders alle stemrechten heeft, is het project in feite gecentraliseerd. Dat maakt het kwetsbaar voor manipulatie of slechte beslissingen die jou als kleine houder schaden.

Kijk ook naar upgradeprocedures. Kunnen ontwikkelaars het protocol aanpassen zonder toestemming van de community? Als dat zo is, heb je als belegger weinig zeggensschap over wat er met je investering gebeurt.

Stap 6: Check de juridische disclaimers

Bijna elke whitepaper eindigt met een juridische disclaimer. Lees hem echt. Let op zinnen als “dit token geeft geen recht op winst of eigendom” en “aankoop in bepaalde jurisdicties is verboden”. Dat vertelt je veel over hoe het project zichzelf juridisch positioneert.

Check ook in welk land het project geregistreerd is. Projecten die gevestigd zijn in landen met minimale regulering, of die helemaal geen juridische entiteit noemen, geven je als belegger weinig bescherming als er iets misgaat.

Stap 7: Vergelijk de whitepaper met de werkelijkheid

Dit is de ultieme test. Pak de roadmap uit de whitepaper en vergelijk die met wat er daadwerkelijk gebouwd is. Zoek het GitHub-profiel op en kijk wanneer er voor het laatst iets gecommit is. Is het mainnet al live of draaien ze nog op testnet? Zijn beloofde mijlpalen gehaald?

Een whitepaper die drie jaar oud is en waarvan de helft van de beloften niet gerealiseerd is, vertelt je meer over het project dan welke marketingtekst ook.

Rode vlaggen op een rij

• Geen duidelijk reëel probleem
• Team volledig anoniem zonder enige verificeerbare achtergrond
• Team- en investeerdersallocatie boven de 40 procent
• Korte of ontbrekende vestingschema’s
• Geen verwijzing naar een onafhankelijke security-audit
• Closed-source code zonder uitleg
• Vage roadmap zonder concrete data of meetbare doelen
• Gecentraliseerde governance met upgrades zonder community-stemming
• Overdreven beloften van rendementen of garanties
• Geen juridische entiteit of registratieland
• GitHub zonder recente activiteit terwijl het project nog in ontwikkeling zou zijn
• Whitepaper vol kopieerwerk uit andere projecten zonder bronvermelding

Van analyse naar een persoonlijke risicoscore

Na het doorlopen van de zeven stappen ken je het project een score toe per onderdeel: sterk, neutraal of zwak. Dat geeft je een overzicht zoals dit:

Heb je meer dan drie “zwak” scores, dan is het risico hoog. Dat betekent niet dat je nooit investeert, maar wel dat je dat met open ogen doet en nooit meer inlegt dan je bereid bent volledig te verliezen.

Tools die je naast de whitepaper gebruikt

Een whitepaper lees je nooit in isolatie. Gebruik Messari voor financiële data en tokenverdelingen. DeFiLlama geeft je zicht op het werkelijke gebruik van DeFi-protocollen. Auditrapporten vind je vaak op de websites van auditbedrijven zelf. Community-forums zoals Reddit of het Discord-kanaal van het project geven je een beeld van hoe actief en kritisch de achterban is. En GitHub is onmisbaar om te zien of er echt gebouwd wordt.

Een whitepaper lezen hoeft niet meer dan een uur te kosten als je weet wat je zoekt. Controleer het probleem en de oplossing, kijk kritisch naar het tokenmodel, zoek de namen van de mensen achter het project op en check of de techniek en planning realistisch zijn. Ontbreekt er iets wezenlijks of kloppen de beloftes niet met de feiten, dan is dat informatie. Niet ieder project dat een slechte whitepaper heeft is oplichterij, maar ieder project zonder controleerbare basis verdient meer scepsis dan enthousiasme.