Researching a cryptocurrency project is an exercise in falsification: try to disprove the important claims before risking capital. A polished website, active social account, or rising token price is not evidence that software works, users are genuine, or token holders benefit from adoption. Useful due diligence moves from claims to primary documents, deployed code, on-chain behavior, and independent confirmation.
No checklist can remove market, fraud, or technical risk. The goal is to identify what the token represents, who controls it, how supply changes, and which assumptions must remain true. Missing information is itself a finding.
Start with the problem and the product
Write the project’s central claim in one sentence. What problem does it solve, for whom, and why does a blockchain improve the solution? Then locate the product. A live network, contract, application, or public test environment provides more evidence than a roadmap. Verify contract addresses and network identifiers through official documentation and an independent block explorer.
Read the technical documentation, but distinguish explanation from marketing. Look for architecture, dependencies, threat assumptions, fees, and failure handling. If performance claims cite transactions per second, ask whether they describe a laboratory benchmark, testnet, theoretical maximum, or sustained production load. Compare like with like.
Competitor analysis is also necessary. A project may solve a real problem without needing a new token, or it may duplicate an established open-source protocol with minor branding changes. Identify the actual differentiator and whether users face switching, bridging, custody, or liquidity costs.
Determine what the token does
Find the deployed token contract or native protocol specification. Does the token pay fees, secure consensus, provide collateral, grant governance, redeem for something, or merely reward activity? Trace where fees go. A protocol can generate revenue while token holders receive no claim on it.
Check whether administrators can mint, pause, blacklist, seize, or upgrade. Proxy contracts may let a privileged account replace logic without changing the public address. Multisignature control is preferable to one key in some contexts, but researchers should still identify signers, approval thresholds, time locks, and emergency powers.
Legal characterization cannot be inferred from a label such as “utility.” Review terms of service, issuer entities, jurisdiction, and disclosures. Token ownership may not represent equity, a debt claim, intellectual property, or an enforceable right to treasury assets.
Analyze supply, allocations, and unlocks
Reconcile circulating, total, and maximum supply. Then map allocations to founders, employees, investors, a foundation, treasury, market makers, validators, users, and incentive programs. Ask how each allocation is custodied and who authorizes transfers.
Build a dated vesting and emissions schedule from official documents and, where possible, smart contracts. A long vesting period can align participants, but only if restrictions are enforceable and cannot be bypassed through derivatives, loans, or related wallets. Note cliffs that release large blocks and governance powers that can alter issuance.
Inspect holder concentration with caution. Exchange, bridge, burn, treasury, and staking addresses should be labeled where evidence supports it. One entity can control many addresses, while one custodian can represent many customers. State these limitations rather than presenting an address chart as a complete ownership register.
Evaluate the team, governance, and conflicts
Verify named founders and organizations through their professional history, corporate records where available, conference appearances, or earlier open-source work. Anonymous contributors are not automatically dishonest, but anonymity reduces the avenues for accountability and makes code and governance controls more important.
Governance research should identify who can propose changes, vote, delegate, execute outcomes, spend treasury funds, and trigger emergency actions. Calculate whether insiders or coordinated delegates can meet thresholds. Review past proposals to see whether formal voting matches actual decision-making.
Look for conflicts in token promotion, exchange listings, market-making agreements, paid research, influencer compensation, and venture allocations. A disclosure does not remove a conflict, but no disclosure makes independent verification more important. Treat testimonials and follower counts as promotional evidence, not product evidence.
Review code and developer activity
Public repositories allow researchers to examine releases, commit history, contributors, tests, open issues, and software licenses. Commit counts are weak in isolation: copied code, automated formatting, or many trivial commits can inflate activity. Focus on whether the deployed version corresponds to the published code and whether maintainers respond to security issues.
Read audit reports, including scope, commit hash, date, findings, and whether fixes were retested. An audit is not a warranty. It can miss bugs, exclude economic design, or become outdated after an upgrade. Check bug-bounty terms and disclosure history, but do not assume that a large headline reward proves it can or will be paid.
For a blockchain, review validator requirements, client diversity, stake or mining concentration, upgrade process, and incident history. For an application, map oracle, bridge, stablecoin, Layer 2, and administrative dependencies. Each dependency can fail while the project’s own code behaves as designed.
Test adoption claims
Use several measures: active addresses, fee-paying users, transaction value, retained application usage, developer integrations, and revenue where transparently defined. Every metric has limitations. Addresses are not people; bots can generate transactions; total value locked can be recursive; incentives can attract capital that leaves when rewards end.
Compare usage before, during, and after incentive campaigns. Determine whether fees are paid by users or subsidized. For business partnerships, find confirmation from both parties and identify whether the announcement describes a pilot, integration, investment, or commercial contract. A logo page is not enough.
Assess liquidity, custody, and market structure
Check where the token actually trades, whether deposits and withdrawals work, and which legal entities operate the venues. Review bid-ask spreads, order-book depth, AMM liquidity, and price consistency. Reported volume is not interchangeable with executable liquidity.
Consider custody before purchase. Confirm wallet and network support, hardware-wallet compatibility if relevant, recovery procedures, and token approval risks. Bridged versions may have different contracts and backing. A familiar ticker does not guarantee that an asset is authentic or redeemable.
A repeatable pre-purchase checklist
- State the project’s testable claim and verify that the product exists.
- Confirm official contracts, repositories, documentation, and legal entities.
- Explain why the token is necessary and where economic value flows.
- Map supply, allocations, vesting, emissions, concentration, and minting authority.
- Identify governance, upgrade, pause, treasury, and emergency controls.
- Review audits and code while documenting their limits and dates.
- Test adoption claims against multiple metrics and independent confirmation.
- Measure realistic liquidity and model an exit during stressed conditions.
- Record unresolved questions and conditions that would invalidate the thesis.
Good crypto project research produces a documented chain of evidence, not a confidence score. Save source links and dates, separate facts from assumptions, and update the work when contracts or governance change. If a core claim cannot be verified, the disciplined response is not to fill the gap with optimism; it is to recognize the additional risk or decline the exposure.