Do not begin crypto research by asking whether a project is “good.” Begin by writing one claim that can die.
For example:
After incentives decline, this protocol can retain economically useful demand, and the token captures enough of that demand to justify owning the token rather than merely using the product.
That sentence forces four different investigations. Does the product work? Does usage persist? What does the token actually receive? Can the market absorb the supply?
Most weak crypto research collapses those questions into one narrative. A strong protocol can have a weak token. A useful token can be overpriced. A liquid market can temporarily hide fragile governance.
This article is an educational research method, not a recommendation to buy any asset.
Keep four ledgers separate
| Ledger | What belongs here | What does not prove it |
|---|---|---|
| Protocol | Product function, users, contracts, dependencies, security | Token price |
| Token | Supply, rights, incentives, emissions, governance, value capture | Protocol usage by itself |
| Market | Float, liquidity, venues, positioning, executable exit | Fully diluted valuation by itself |
| Control | Entities, upgrade keys, governance, treasury, legal structure | A “decentralised” label |
Do not move a positive observation from one ledger into another without explaining the mechanism.
Protocol ledger: prove there is a useful system before pricing the token
Start with the job the product performs.
What does a user do that could not be done as well through an ordinary database, centralised service or existing protocol? Which trust assumptions disappear, and which new ones are introduced?
Primary evidence should come from documentation, deployed contracts, source repositories, governance records and observable product activity where available. Marketing screenshots and follower counts are discovery inputs, not proof.
Then inspect the dependencies. Smart-contract systems can depend on upgrade administrators, oracles, bridges, front ends and external libraries. Ethereum’s current security guidance explicitly treats access control and governance as material security boundaries; code being public does not make administrative power irrelevant.
The output of this ledger should be a mechanism statement, not a feature list:
The protocol is useful because X user repeatedly needs Y function, and the system can provide it only while dependencies A, B and C remain credible.
Token ledger: trace the path from use to holder value
Now temporarily forget the protocol’s brand.
Write down current and future supply, emissions, unlocks, treasury holdings, staking rewards, governance rights and any mechanism that directs economic value toward the token.
Then draw the value-capture path.
“More users” is not a path. Neither is “ecosystem growth.” The path has to name the economic event:
- users must acquire the token to consume a scarce resource;
- fees are paid in the token and removed from supply;
- holders receive a defined share of protocol economics;
- staking creates necessary collateral or security demand;
- governance controls an economically meaningful right.
If users can obtain the product’s benefit while avoiding the token, that belongs in the counter-thesis.
Also distinguish protocol fees, protocol revenue and tokenholder value. They can move together, but they are not synonyms.
Market ledger: ask whether the thesis can be entered and exited
A research memo is incomplete if it explains the technology but not the market structure.
Record circulating float, major unlocks, holder concentration, exchange concentration, order-book depth and the venues that are legally and operationally available to the intended user.
Market capitalisation is not executable liquidity. A token can have a large quoted value and very little depth at the size you actually need to trade.
Future supply also matters differently from current supply. An unlock schedule is observable; recipient behaviour is not. Research should therefore separate the known dilution schedule from assumptions about selling.
The output of this ledger is an execution statement:
The position can be entered and exited at the intended size under normal conditions, but liquidity depends materially on venues X and Y and scheduled supply event Z.
Control ledger: identify who can change the thing you think you own
This is where many crypto theses become less comfortable.
Map who can upgrade contracts, pause functions, mint supply, alter parameters, move treasury assets, change oracle sources or control the main interface. If a multisig exists, record the threshold and whether signers are genuinely independent. If governance exists, inspect who can propose, delegate and execute changes and whether users receive a meaningful exit window.
Control is not automatically bad. Emergency powers can limit damage. The research question is whether the power is visible, constrained and compatible with the thesis.
A token marketed as decentralised while one entity can rapidly change the economic or technical system requires a different risk premium from one whose powers are narrowly constrained.
Now attack the original claim
Return to the sentence you wrote before researching.
For the example claim, the strongest counter-case might be:
Usage is primarily incentive-driven, the token is not required for the valuable product action, insiders receive substantial future supply, and the protocol retains upgrade control that can change economics before holders can exit.
Do not answer that by adding more bullish facts. Ask what evidence would actually defeat the counter-case.
Useful tests might include:
- retention after a known incentive reduction;
- fees paid by users without token subsidies;
- a documented value-capture mechanism that survives governance changes;
- liquidity that can absorb scheduled supply without relying on one venue;
- control changes that reduce unilateral admin power rather than merely renaming it.
If you cannot state what would change your mind, the memo is becoming advocacy.
Separate facts, models and judgments in the research note
A useful final memo should make the evidence status visible.
Fact: a contract grants a named role the power to pause.
Inference: that role creates a central operational dependency.
Model: a data provider groups several addresses into one exchange entity.
Judgment: the dependency is unacceptable at the proposed position size.
Unknown: whether an unlocked holder intends to sell.
These categories can appear naturally in prose. They do not need five mechanical headings in every article. What matters is that the conclusion is not allowed to borrow certainty from a weaker evidence type.
Build the decision from the weakest decisive link
Do not average the four ledgers into a score.
A project can have excellent code and still fail the investment test because the token captures no value. It can have strong token economics and still be uninvestable at the intended size because liquidity is thin. It can have healthy usage and still depend on one upgrade key whose compromise changes the entire exposure.
The decision should therefore name the weakest decisive link:
I would reject, watch or size this position differently because X dependency can invalidate the thesis before Y upside mechanism has time to work.
That is more useful than an 8.4/10 project score.
What the final research record should preserve
- the original falsifiable claim;
- primary sources and their dates or versions;
- protocol, token, market and control findings;
- the strongest counter-thesis;
- material unknowns;
- the invalidation condition;
- the evidence that would change the conclusion;
- the date the thesis was last reviewed.
When new information arrives, update the conclusion and preserve the earlier view. A research process that rewrites history after every market move cannot tell you whether the method improved or merely followed price.
The question to keep
Crypto research is not a hunt for enough facts to justify conviction. It is an attempt to find the mechanism that makes the claim true, then identify the evidence that would prove the mechanism failed.
Separate the protocol from the token, the token from the market and the market from the people who can change the system. Only then decide whether the remaining uncertainty is worth owning.
For the risk layer, continue with the Crypto Risk Framework. For data-model caveats, use the on-chain analytics methodology guide.
