Turn a pitch into questions.

First, know what you are investigating.

Write the exact asset and network. If it is a token, record its contract address from independently verified project documentation and compare it with the relevant explorer. A familiar name or symbol can be copied. Even an official site can be compromised, so a single link is not the whole check.

Now explain the product in one ordinary sentence. Who needs it? What alternative do they use today? What does the token let a holder do? These questions keep a broad promise from substituting for a specific mechanism.

Ask which layer supplies security and who holds special powers. Look for minting, freezing, upgrades, treasury control, emergency switches and governance rules. A public chain can host a project with concentrated control.

Follow the units and the payments.

Record circulating supply, the broader supply used for FDV, allocations and release schedules. Who can sell now? Who may be able to sell later? What can change those rules?

Check markets rather than only a headline valuation. How much depth is available near the quote? What would the intended trade do to price? Are there restrictions, transfer taxes or fees? A deep market today can still become thin.

If someone offers yield, trace its payer. Does it come from borrower interest, trading fees, newly issued tokens, or a temporary subsidy? More tokens are not necessarily more purchasing power. Ask what happens if rewards stop or the reward token’s price falls.

Protocol revenue is a useful measure only once you know what it counts and who receives it. It may go to service providers or a treasury without belonging to token holders.

Check the work behind the story.

Find usage evidence and its method. Active addresses are not the same as people. Volume can include bots or wash trading. A paid incentive can make a quiet service look busy. Ask whether customers return when rewards shrink.

Look at the team’s relevant work, disclosures, incentives and ability to change the system. Read audits with their scope and date: they examine particular code under particular assumptions. They do not guarantee safety, especially after upgrades.

A history of surviving stressful conditions adds evidence about those conditions. It does not prove the next failure is impossible. A new project has less operating history; that is uncertainty to record, not proof of dishonesty.

Consider the narrative too: what story is attracting attention, and what evidence supports it? A beautiful site, a listing, a famous promoter and “the next Bitcoin” are all weak substitutes for answering the underlying questions.

Write the case against it.

Finish with a short failure story. “If the token’s voting power does not create demand and the subsidy ends, holders may compete to sell into a thin market.” That gives you something to investigate. “It might go down” does not.

Write what new evidence would change your view. Then record a decision: continue researching, set it aside, or decide that it does not fit your circumstances. Passing is a complete decision.

The repeatable order is identity and purpose, control, supply, markets, use and yield, then failure and decision. Keep sources and the date beside each claim. The page can be short; the work behind it may take time.

Apply the same standard to something you already own or something a teacher mentions. Research can reduce avoidable mistakes. It cannot certify a winner or remove uncertainty. Keep the number of things you follow within the time you can actually give them.

The idea to keep

A good research page makes the connection between a claim and its evidence visible. It also shows where the connection is missing.

You can understand a project and still decide not to own its token. Next, consider the responsibilities that begin before any purchase.