Altcoin research often begins in the wrong place. A price chart, influencer thread, or trending token list creates urgency, and the researcher starts gathering reasons to act. That sequence encourages confirmation bias. A stronger process begins with a neutral question, records evidence before conclusions, and makes room for a decision not to participate. Due diligence is not a prediction machine; it is a method for reducing avoidable surprises.
The twelve steps below are designed for a written research file. They work whether you are studying a network token, DeFi governance asset, gaming token, infrastructure project, or community coin. Missing information is itself information, especially when the project asks the market to assign it a large value or trust it with user funds.
1. Write the thesis before opening the chart
Describe the project in one sentence without marketing language. Then write the token thesis separately. For example: “This protocol coordinates decentralized storage providers” is a product statement. “The token is required for payment and collateral, so sustained storage demand could increase token demand” is a token statement. Keeping them separate prevents product admiration from becoming an automatic price thesis.
Add a time horizon and three disconfirming facts. A six-month catalyst thesis should not quietly become a five-year conviction after the catalyst fails. Disconfirming facts might include usage declining after rewards end, a major customer segment failing to appear, governance remaining concentrated, or supply growth exceeding demand. This turns the thesis into something you can test rather than defend emotionally.
2. Verify the asset and its contract
Confirm the chain, contract or mint address, token symbol, decimal settings, and official project channels. Symbols are not unique, copied websites are common, and scam tokens can appear beside legitimate assets. Cross-check the address through more than one first-party source and a reputable block explorer. Never rely on a direct message, search advertisement, or social-media reply for a contract address.
Use the explorer to inspect supply, top holders, creation date, transfer activity, and privileged roles where available. Look for mint, freeze, pause, upgrade, blacklist, or ownership controls. Those controls may have legitimate operational purposes, but you should understand who holds them, whether they are protected by multiple signers, and whether there is a public process for using them.
3. Read the documentation as a set of claims
Project documents should explain the problem, users, architecture, roadmap, token role, governance, and risks. Convert each major statement into a claim that could be verified. “Fast and scalable” is vague. “The network targets this type of workload under these assumptions” is testable. “Community governed” should lead to questions about proposal rights, voter concentration, delegation, quorum, and emergency powers.
The general research principle is the same one emphasized in Investor.gov’s guidance on researching investments: do not depend solely on information from the seller or promoter. For crypto projects, compare official documents with code repositories, explorers, independent audits, governance forums, and observable product behavior.
4. Map the people and decision structure
Identify founders, core contributors, foundations, development companies, investors, market makers, and major delegates. The goal is understanding accountability and control. Look for relevant technical or operating history, consistent identities, disclosed conflicts, and evidence that important functions can continue if one person leaves.
Then map decision rights. Who can upgrade contracts? Who controls treasury funds? Who chooses oracle providers or risk parameters? Is governance onchain, offchain, foundation-led, or a mixture? A project may be reasonably centralized during early development, but the market should not confuse a decentralization roadmap with a decentralization fact.
5. Reconstruct the supply story
Record circulating supply, total supply, maximum supply if one exists, and the rules for future issuance. Build a table of allocations to founders, employees, investors, community programs, foundations, treasuries, validators, and public participants. Add vesting schedules, cliffs, emissions, burns, and any governance ability to change them.
Do not stop at a headline unlock calendar. Ask who receives the tokens, what their cost basis may be, whether they need liquidity, and how deep the market is relative to the release. A small percentage unlock can matter in a thin market. A large unlock may be absorbed if recipients are long-term operators and demand is strong. The point is to model potential behavior, not assume that every unlock has the same effect.
6. Test whether the product has real users
Define the user action that demonstrates value. Wallet connections, transactions, or social followers may be easy to inflate. Stronger measures depend on the product: recurring paying users, retained developers, active borrowers, organic trading volume, storage consumed, fees paid without rebates, or applications that choose the network for reasons beyond incentives.
Separate gross activity from subsidized activity. If the protocol distributes ten dollars of incentives to create one dollar of fees, the activity may be useful for bootstrapping but does not yet demonstrate durable economics. Track what happens when rewards change. Retention after incentives decline often tells you more than peak activity during a campaign.
7. Review code, audits, and operational security
You may not be able to audit code personally, but you can examine the security process. Are contracts verified? Are repositories active? Were audits performed by identifiable firms, and were findings addressed? Is there a bug bounty? Are upgrades delayed so users can react? Does a multisignature wallet protect critical permissions, and are signers independent?
An audit is not a warranty. It covers a particular code version and scope at a particular time. New features, integrations, economic assumptions, or governance decisions can introduce new risks. Review incident history and the team’s response. Transparent postmortems and concrete remediation can be more informative than a claim of perfect security.
8. Understand liquidity and market structure
Identify where the token trades, how concentrated volume is, how much liquidity sits near the current price, and whether major venues depend on a small number of market makers. Reported volume can overstate executable liquidity. Observe spreads, order-book depth, decentralized pool composition, and slippage at realistic trade sizes.
Also ask how insiders, treasuries, and protocols obtain liquidity. Market-making loans, token incentives, or treasury-owned pools can support trading but may change quickly. If the token is used as collateral, a liquidity shock can cascade through liquidations. A research file should include an exit assumption, not just an entry idea.
9. Analyze competition and switching costs
List direct competitors, substitutes, and the option of doing nothing. Compare the product on security, cost, performance, distribution, developer experience, liquidity, regulatory exposure, and user trust. Avoid choosing only weak competitors. The most important alternative may be an established centralized service, a different blockchain, or a protocol that does not require a token.
Then examine switching costs. Developers can sometimes move code, liquidity, and users quickly; in other cases, deep integrations and network effects create durability. A token thesis is stronger when the project has a defendable reason to retain activity and the token participates in that advantage.
10. Build valuation scenarios, not one target
Crypto valuation is uncertain, so use ranges. Create a downside case, base case, and optimistic case. Connect each to measurable assumptions: users, fees, margins, token supply, staking demand, collateral use, or comparable network value. Avoid using a high market capitalization as proof that another token deserves the same one.
Fully diluted value can help reveal how the market values future supply, but it is not a forecast by itself. Revenue multiples can be informative for some protocols and meaningless for others. The purpose of scenarios is to expose which assumptions drive the conclusion and how sensitive the result is to supply or adoption changes.
11. Record red flags and unanswered questions
Maintain a section that argues against the thesis. Include anonymous control, unverifiable partnerships, inconsistent supply figures, copied code presented as innovation, hidden admin keys, concentrated voting, paid promotion without disclosure, unrealistic return promises, dependence on one exchange, or repeated roadmap changes without explanation.
Assign an owner and deadline to each unanswered question. Some gaps can be resolved through documentation or a governance forum. Others remain unknowable. Decide in advance which unknowns are acceptable, which require a smaller risk budget, and which end the research. “I could not verify it” is a valid conclusion.
12. Make and document the decision
Finish with a dated decision: reject, watch, research further, or allocate within a defined limit. State the reason in plain language, the maximum risk budget, the conditions for review, and the evidence that would cause an exit. This protects you from rewriting history after the market moves.
Keep the file even when you reject the asset. Over time, your archive becomes a record of which signals were useful, which assumptions failed, and where emotion entered the process. Pair this workflow with our tokenomics guide and market-research framework to make the process more quantitative without pretending uncertainty disappears.
Conclusion: a repeatable process beats a perfect prediction
No checklist can eliminate fraud, code failure, market shocks, or regulatory change. It can, however, slow down urgency, surface hidden dependencies, and force a thesis to connect the product with the token. That is a meaningful advantage in a market where stories travel faster than verification.
The best due diligence process is one you can repeat consistently. Keep it short enough to use, rigorous enough to challenge you, and flexible enough to reflect different token types. When evidence is weak, the disciplined answer is not to fill the gap with confidence. It is to reduce exposure, continue watching, or walk away.