Start with the job
Ask what the project is supposed to do in plain language.
Good answers usually sound specific:
- payments settlement
- decentralized exchange liquidity
- stablecoin issuance
- data availability
- lending markets
- staking security
- tokenized real-world assets
Weak answers often lean on vague words like "revolutionary," "community," or "AI-powered" without explaining who uses the product and why the token is needed.
Check whether the token has a real role
A token can be useful, but it should not be assumed useful just because it exists.
Look for:
- fees paid in the token
- staking or validator security
- governance with real scope
- collateral use
- revenue, burns, or protocol incentives that are clearly explained
If the product could work exactly the same without the token, treat that as a warning sign.
Read the supply story
Token supply can change the whole risk profile.
Check:
- circulating supply versus total supply
- upcoming unlocks
- team and investor allocations
- inflation schedule
- whether large wallets can pressure the market
A project can be useful and still have a difficult token structure.
Look for operating proof
Useful signals include:
- active users or transaction volume
- integrations with known wallets, exchanges, protocols, or issuers
- open documentation
- public security reviews
- visible governance history
- steady development activity
None of these guarantees safety. Together, they help separate a working network from a pitch deck.
Review liquidity before price
Price is not enough.
Check market cap, 24 hour volume, exchange depth, major trading pairs, and whether liquidity is concentrated in one venue. Thin liquidity can make entries, exits, and stop losses much worse than the chart suggests.
Watch for red flags
Be careful when you see:
- guaranteed yield
- anonymous teams with custody control
- pressure to buy quickly
- unclear unlocks
- fake partnerships
- copied documentation
- no clear withdrawal or custody path
- a token that only seems useful because the price went up
The practical rule is simple: if the project needs urgency to overcome basic questions, slow down.