Check a token without turning a checklist into a verdict
A checklist helps you ask the right questions. It cannot tell you a token is safe. Mark each check as fine, a worry, unknown, or not relevant.
Being checked. An automatic check is done and the links work. A person still needs to confirm the facts.
Checked automatically against the review checklist. Links work, but an editor still needs to confirm each source backs the exact claim. (Automated check (not a human editor), 2 Oct 2026)
This is education, not advice on what to buy. Last edited 2 Oct 2026.
Read first, Chain and address identity.
The short answer
A token checklist organises questions. It cannot establish that a trade is safe or profitable. Some risks are visible, some change over time, and some sit entirely outside any scanner's coverage. Record four possible outcomes for each check: documented, concern, unknown, or not applicable.
Identity first
Begin with chain and asset identity. Record the exact contract or mint address and where you obtained it. A name, ticker, logo, verified-looking social badge or screenshot does not identify an asset. Copycat deployments with identical metadata are cheap and common.
Permissions differ by chain
On Solana, mint and freeze authorities have specific meanings. A live mint authority permits new supply; a live freeze authority permits freezing token accounts so holders cannot transfer. Revocation removes those specific paths. Token extensions can add further behaviour such as transfer fees or transfer hooks, meaning the amount received may differ from the amount sent.
On EVM networks, the relevant surface is different: contract ownership, upgradeable proxies, transfer taxes, blacklists, pause functions, maximum wallet or transaction limits, and whether source is verified at all. Verified source means the published code matches the deployed bytecode. It does not mean the code is benign.
Do not copy checks from one chain to another without explaining the difference. A page that lists "mint authority" for an EVM token is describing nothing.
Liquidity and the lock claim
Identify the route and the liquidity mechanism. A claim of locked liquidity should specify the pool, the position or LP token, the amount, the lock mechanism and the expiry. "Liquidity locked" with no pool address is not a finding.
A verified lock constrains one thing: the withdrawal of that specific position before that specific time. It does not constrain supply held elsewhere, contract permissions, a second pool, or the social risks around the project.
Distribution with exclusions
Inspect ownership distribution and recent transfers, and state your exclusions. Pool reserves, burn addresses, known custody and exchange addresses and vesting contracts routinely appear as large holders. Conversely, several related wallets can look independent, and one large address can represent many users.
Clustering by funding source, timing or behaviour supports a hypothesis. It is not proof of a single owner and it is certainly not proof of intent. Write it as a hypothesis with the evidence attached.
Social evidence
Record claims with primary sources and timestamps, and compare promotion against observable facts. Repeated messages, follower counts and account badges do not establish genuine identity or genuine participation.
The tiny test sell
A successful small sell demonstrates that one transaction worked, at that size, at that moment, from that address. It does not establish that a larger sale will work later, that rules will not change, or that an address-specific restriction does not exist. Treat it as one data point with narrow scope.
Common mistakes
- Converting a completed checklist into a score and then treating the score as safety.
- Reading "no issues found" from a scanner as evidence of no issues.
- Accepting a renounced-ownership claim without checking which permissions renouncing actually covered.
- Assuming a large holder is the developer, then publishing that as fact.
What this evidence cannot establish
Nothing here predicts price, and nothing here is permanent. Permissions can be exercised after you check, liquidity can be removed after you look, and a social actor can change behaviour at any time. The output is a research note describing evidence, remaining uncertainty, and reasons to avoid or investigate further.
Checklist
- Chain and exact address, with source
- Token program or contract identified
- Chain-appropriate permissions documented
- Route and pool identified; lock claims specified precisely
- Distribution read with exclusions stated
- Social claims saved with primary links and timestamps
- Every item marked documented, concern, unknown, or not applicable
Sources
- Solana docs: set authority , Solana · Backs up the claim · checked 2 Oct 2026
Page explains mint and freeze authority directly.
- RugCheck , RugCheck · Link works, exact page not confirmed · checked 2 Oct 2026
Homepage of the scanner, not documentation of its checks. Needs a page that lists what it actually checks.
Related reading
Start in the trenches with a research process
Your first goal is not finding a winner. It is following the same short checklist every time and writing down why you would buy or skip.
Investigate a failed sell before changing settings
A sell can fail for many reasons. Before you try again, check whether the transaction was actually sent and what the blockchain says happened.