Chapter 01
Attention is the starting signal, not the evidence
Meme coins can move from obscurity to enormous visibility before reliable documentation catches up. That speed makes the research order important. Price, follower counts and repeated slogans describe attention; they do not establish who controls the contract, whether liquidity is durable or whether a quoted market can absorb a sale.
Begin with a neutral record containing the network, contract address, observation time and the official channels that asserted the address. If those basics cannot be reconciled, stop. A polished website and a familiar ticker are easy to copy, while a transaction sent to the wrong contract cannot be repaired by later research.
Chapter 02
Confirm the network and contract address independently
The same name or ticker can exist on several networks, and impostor contracts can appear beside the original. Obtain the address from more than one authoritative path—for example, a project's official documentation and a separately verified announcement—then compare every character with the blockchain explorer used for that network.
Record the chain as well as the address. An address without its network is incomplete evidence. Avoid search advertisements, unsolicited messages and social replies as the sole source; they can lead to convincing copies of a legitimate project.
Chapter 03
Verified source code answers one question, not every question
Source-code verification compares published source and compiler settings with the bytecode deployed at a contract address. Ethereum.org explains that this makes the running code easier to inspect and can expose privileged functions or unexpected behavior that would be difficult to evaluate from bytecode alone.
A verification badge does not mean the code is safe, audited, fairly distributed or connected to the people promoting it. It only supports a narrower proposition about the relationship between published source and deployed code. Reviews should name the explorer, verification type and observation date rather than turning the badge into an endorsement.
Chapter 04
Look for powers that can change the holder's position
Identify roles or functions that can mint additional supply, freeze transfers, block addresses, change fees, pause trading, upgrade implementation code or move assets. A privileged function is not automatically malicious, but it creates a dependency that must be understood together with the keys or governance process controlling it.
Check whether ownership was renounced only after confirming what that means for the specific contract. Upgradeable proxies, external contracts and separate liquidity controls can preserve meaningful authority even when one ownership field appears inactive.
Chapter 05
Distribution data needs labels and context
A holder table can exaggerate concentration if exchange, bridge, burn, vesting or liquidity-pool addresses are treated as ordinary individuals. It can also understate concentration when one entity controls several wallets. Label known infrastructure, preserve uncertain classifications and show both raw and adjusted views when possible.
Then examine scheduled unlocks, treasury controls and the movement history of large balances. The goal is not to produce a magical concentration score; it is to identify who could create supply or selling pressure and how confidently that control can be attributed.
Chapter 06
Pool size and price impact matter more than a headline price
In an automated market maker, the displayed token price comes from reserves in a liquidity pool. Uniswap's guidance explains that larger trades have greater price impact when pool liquidity is low. A high quoted valuation can therefore coexist with a pool too shallow to support meaningful exits near the displayed price.
Record pool addresses, paired assets, current reserves, estimated price impact at several trade sizes and whether liquidity positions can be withdrawn. Do not describe liquidity as 'locked' without identifying the mechanism, beneficiary, unlock date and verifiable transaction.
Chapter 07
Separate project statements from independent evidence
A research file should distinguish what promoters say, what on-chain records show and what an independent source has verified. Screenshots need URLs and timestamps; deleted or edited claims should not silently disappear from the chronology.
Partnership, audit and listing claims should be confirmed with the named counterparty. An audit can provide useful technical review, but Ethereum.org's security guidance cautions that independent review is not a guarantee that every defect has been found.
Chapter 08
Treat urgency and guaranteed returns as risk signals
The CFTC and FTC both warn consumers to research digital tokens carefully and to distrust guarantees or pressure to act immediately. Promises of certain returns, private recovery help, surprise giveaways and requests to send funds in order to receive more are not substitutes for verifiable product information.
Do not connect a wallet or sign a transaction merely to continue research. Read the requested permissions, use a separate low-value research wallet when interaction is unavoidable and revoke unnecessary approvals. Research should reduce exposure, not create a new attack path.
Chapter 09
Publish the uncertainty, not just the conclusion
A responsible assessment states what was checked, when it was checked and which material questions remain unanswered. Contract controls, distribution and liquidity can change after publication, so the record needs a review date and a correction path.
No checklist converts a meme coin into a safe investment. It can only surface verifiable facts, dependencies and warning signs. Readers still face volatility, technical failure, fraud and the possibility that the market disappears entirely.
