Evaluate a crypto project in layers: define the user job, identify who controls critical functions, inspect the maintained software, trace the token’s economic role, test liquidity and exit routes, review security evidence, and separate verifiable facts from promotional claims.
The goal is not to predict a token price. It is to understand what must remain true for the project to keep operating and who bears the loss when an assumption fails. A useful review can end with “insufficient evidence” rather than a forced score.
1. Define the user job
Write one sentence describing what the user accomplishes. Examples include transferring value, borrowing against collateral, coordinating a network, proving ownership, playing a game, or accessing a service. Avoid vague language such as “revolutionising finance” or “building the future of Web3.”
Then ask whether a blockchain and token are necessary. A project may use blockchain infrastructure legitimately while its own token adds little. Compare the proposed system with simpler databases, payment rails, loyalty points, or conventional contracts. Technical novelty is not automatically user value.
2. Map control
“Decentralised” is not a complete control description. Identify the keys and organisations that can upgrade contracts, pause transfers, change fees, freeze assets, control a bridge, list a token, or move treasury funds. Review multisignature thresholds and whether signers are independent.
Control is not always bad. Emergency controls can reduce damage. The risk comes from hidden or misunderstood power. A user should know whether a governance vote is binding, whether administrators can override it, and whether the front end, oracle, sequencer, bridge, or issuer creates a central dependency.
3. Inspect software and maintenance
Look for public repositories, release history, documentation, issue handling, dependency updates, and security fixes. A copied repository with many commits may create a false impression of activity. Experienced maintainers, reproducible releases, code review, test coverage, and clear upgrade processes are more meaningful than a single activity number.
Electric Capital’s developer report archive demonstrates both the value and limits of repository analysis. Its methodology examines large volumes of open-source activity, but it cannot prove product demand or code security for a specific project.
4. Trace the token economics
Determine why the token exists. Does it pay for block space, secure the network, represent a claim, coordinate governance, reward participation, or simply fund the team? Identify total and circulating supply, issuance, unlocks, burns, treasury concentration, insider allocations, and the conditions under which demand appears.
Follow the money. If yields are paid, identify the payer and the economic activity producing the return. If rewards are newly issued tokens, users may be receiving dilution rather than external revenue. If fees are generated, ask whether they flow to token holders, validators, a company, liquidity providers, or nobody.
5. Test liquidity and exits
A displayed price is not the same as an executable exit. Inspect market depth, venue concentration, trading-pair quality, withdrawal support, bridge dependencies, and whether liquidity is provided by related parties. Thin markets can move dramatically on small orders.
For a game or application, also review withdrawal minimums, conversion steps, lockups, and the number of users who can cash out without collapsing the reward asset. An economy that works only while most participants reinvest is fragile.
6. Review security evidence
An audit is a dated review with a defined scope, not a permanent safety certificate. Read the report, confirm the code version, note exclusions, and check whether high-severity findings were fixed. Search for bug bounties, incident disclosures, contract verification, key management, and upgrade timelocks.
Ethereum’s security and scam-prevention guidance illustrates practical user risks such as recovery-phrase theft, malicious approvals, irreversible transfers, fake support, and phishing. A project evaluation should cover user operations as well as contract code.
7. Verify people and claims
Confirm that named founders, advisers, partners, investors, and auditors acknowledge the relationship through their own official channels. A logo wall is not evidence. Check whether biographies are consistent, whether previous projects exist, and whether legal entities and jurisdictions are identifiable.
Separate statements by the project from independent evidence. “We have millions of users” requires a definition of user and a method. “Audited” requires a report. “Backed by assets” requires a claim structure, custodian, scope, date, and verification method. “Community governed” requires evidence of actual control.
8. Challenge the failure case
Write down what happens if price falls 80%, token rewards end, the largest market maker leaves, an administrator disappears, a bridge pauses, a jurisdiction restricts access, or a major dependency is exploited. The project may survive some failures and not others.
Good teams discuss limitations and recovery procedures. Weak projects treat every risk question as hostility or answer with future partnerships. Uncertainty is unavoidable; hidden uncertainty is optional.
Evaluation worksheet
| Question | Evidence | Unresolved risk |
|---|---|---|
| What job does it solve? | Working product, user flow, repeat usage | Demand may be subsidy-driven |
| Who controls it? | Keys, multisig, governance, legal entity | Hidden emergency or upgrade power |
| Is it maintained? | Releases, issues, contributors, documentation | Activity does not prove quality |
| Why does the token matter? | Protocol rules, fees, security, rights | Token may be optional or dilutive |
| Can users exit? | Depth, withdrawals, bridges, redemption | Liquidity can vanish during stress |
| What was reviewed? | Audit scope, code version, remediation | New code and integrations remain unreviewed |
Red flags that should stop the review
- Guaranteed returns or pressure to act immediately.
- Requests for recovery phrases, private keys, remote access, or extra payments to unlock withdrawals.
- Unverifiable team members, copied documents, or false partnerships.
- Opaque token supply, unexplained treasury movements, or hidden unlocks.
- No credible answer to who controls contracts, bridges, or customer assets.
- A refusal to discuss failure cases, audit scope, or conflicts of interest.
The CFTC advisory on digital coins and tokens recommends extensive research into rights, value drivers, liquidity, technological change, and fraud risk. Use regulator guidance as a baseline, not as an endorsement of any project.
Return to the crypto health diagnostic, browse all field guides, or continue with crypto risk signals.