Research process
A crypto due diligence checklist for checking project claims
A due diligence checklist makes a project claim easier to examine and discuss. Its output is a dated research record with evidence and open questions. This guide offers a repeatable educational process for reviewing a crypto project; it cannot establish that a project is safe or suitable for a financial decision.
Educational research methods, without recommendations to buy, sell or hold an asset. Crypto assets can lose all their value. Read the risk disclosure.
By AlfaDAOPublished Updated
1. Define the question and the project identity
Write one question at the top of the note. For example: does the deployed product match the documentation, or who can change a token's permissions? Set a review date and state which network, product version and contracts are in scope. This keeps a broad narrative from drifting into unrelated claims.
Collect the official domain, documentation, repository and published deployment addresses. Cross-check addresses between official sources and the relevant explorer. Save disagreements for investigation. A ticker, search result or verified social badge alone leaves the underlying contract identity unresolved.
2. Map the product and its dependencies
Describe what a user can do today and the contracts or external services that make it possible. Separate deployed functionality from announced work. Follow the path of an action through the application: which contract receives it, what assets it touches, and which other systems supply information or custody?
Ethereum's smart-contract documentation explains the relationship between an on-chain program and its stored state. Use that foundation to form concrete questions about a deployment. If a dependency or address is missing, mark it unknown rather than completing the picture with an assumption.
Source references
3. Inspect code visibility and administrative powers
Check the explorer's source-verification status and the type of match it reports. Etherscan distinguishes several verification types, including matches with different treatment of deployment details. Record the status precisely. Published source makes inspection possible; it does not by itself demonstrate that the design is secure.
Identify upgrade, mint, pause and permission-management powers where applicable. Record the controlling accounts and any documented delay or approval process. OpenZeppelin's access-control and proxy documentation explains common patterns, but the actual deployment determines which powers exist. Follow a proxy to its implementation and examine both addresses in context.
4. Match security evidence to the deployment
For any published audit, record its author, publication date, repository commit, reviewed contracts and stated scope. Compare those references with the current deployment. Summarize unresolved findings in their original context, and distinguish a report's recommendation from evidence that a fix was deployed.
Ask what changed after the review and which dependencies were excluded. A report about one component cannot establish the behavior of the whole system. If the material is unavailable or the versions cannot be reconciled, leave that limitation visible in the note.
5. Reconcile token and activity claims
For a token, collect the published allocation and release schedule, then identify the contracts or other evidence supporting it. Keep total supply, a provider's circulating-supply estimate and future emissions as separate fields. A supply figure without its definition and observation time is difficult to compare.
For usage claims, record the metric, time window, network and data source. Ask how automated activity, internal transfers or changes in methodology affect the number. Save a query or a reproducible set of steps whenever possible. Missing information remains missing even when a dashboard displays a confident total.
6. Publish a reviewable research record
End with the strongest supported observations, the competing explanations and the unanswered questions. State what evidence would change the interpretation and what event should trigger a fresh review. Share only material you are authorized to share; an internal discussion or account record is not automatically a public source.
- Identity: network, deployment addresses and the official sources used to check them.
- Evidence: document dates, relevant blocks or transactions, and review scope.
- Uncertainty: missing information, conflicting claims and assumptions.
- Follow-up: the responsible question and the next event to check.