Direct answer

To verify a token contract: confirm the address from a source the project controls, check the source code is verified on a block explorer, read the contract for privileged functions (mint, pause, blacklist, transfer fee, upgradeable proxy) and who controls them, check holder concentration, and confirm any claimed liquidity lock on-chain. Unverified source on an unfamiliar token is sufficient reason to decline.

Prerequisites

A block explorer for the relevant chain.
The project's own website or verified account, reached by typing the domain — not a search result or a message.

Time required: about ten minutes.

Step 1 — Get the address from the right place

Everything downstream is worthless if you verify the wrong contract.

The contract address must come from a source the project controls. Not a search advertisement, not a social post, not a message you received, not a reply under an announcement.

Two things to remember:

Names and tickers are not unique. Anyone can deploy a contract using an existing project's name and symbol, and this is one of the most common ways buyers acquire a worthless token.
A project may deploy on several chains with different addresses. An address valid on one chain is meaningless on another.

Step 2 — Confirm the source code is verified

Open the address on the explorer and look for verified source.

Verified means the published source has been confirmed to compile to the deployed bytecode. Without it you are trusting a description of the contract rather than the contract.

For an unfamiliar token, unverified source is where the check ends. There is no way to assess what you cannot read, and legitimate projects verify because it costs nothing and builds trust.

Step 3 — Confirm it is the token contract

Check the address is the token itself, not something adjacent:

A liquidity pool address.
A proxy admin or timelock.
A treasury or team wallet.

The explorer's token page should show name, symbol, decimals, total supply, and holder count. If those are absent, you are not looking at a token contract.

Compare name, symbol, and decimals against the project's own documentation. A mismatch is a stop.

Step 4 — Read for privileged functions

You are looking for what the contract can do that an ordinary holder would not expect. Use the explorer's search within the source, or read the function list:

Look for	The question it raises
`mint`	Can supply increase after you buy, and who decides?
`pause`, `freeze`	Can transfers be halted?
`blacklist`, `blocklist`	Can a specific address be blocked from selling?
Fee or tax on transfer	Does the recipient receive less than was sent — and is it asymmetric between buy and sell?
`upgradeTo`, proxy admin	Can the implementation be replaced entirely?
`owner`, `onlyOwner`	Who holds these powers now?

These are not automatically disqualifying. Pause functions have saved projects during live exploits, and mint capability is necessary for many legitimate designs.

What matters is whether they are disclosed and who controls them. A mint function behind a multisig and a timelock is a very different risk from the same function behind one hot key.

Two specific red flags:

Asymmetric transfer fees — a higher fee on sells than buys, or a sell fee that can be raised after launch. This is the honeypot pattern.
A blacklist controlled by a single key on a token promoted to the public.

Step 5 — Check ownership status

Find the current owner and whether ownership has been renounced.

Be careful with "ownership renounced" as a claim. Renouncing Ownable does not necessarily remove other privileged roles. A contract can have separate admin, minter, or pauser roles that survive renunciation. Check the roles that actually exist rather than accepting the headline.

Step 6 — Look at holder concentration

The explorer's holders tab shows distribution. Ask:

What percentage does the largest non-contract holder control?
How much sits in team or treasury wallets?
Do the top holders look like a distribution or like a handful of addresses funded from the same source at the same time?

High concentration is not proof of anything — early projects are naturally concentrated — but it tells you how much of the supply could arrive on the market at one person's decision.

Step 7 — Verify claimed locks on-chain

If a project claims liquidity or team tokens are locked, that claim is checkable:

Find the lock contract address.
Confirm the tokens are actually held there.
Check the unlock date.

A verifiable lock is worth considerably more than a stated intention. An unverifiable claim of a lock should be treated as no lock.

Step 8 — Decide

You now have enough to make a decision rather than a guess:

Address obtained from a project-controlled source
Source code verified
It is the token contract, not a pool or proxy admin
Privileged functions enumerated and their controllers identified
No asymmetric or mutable sell fee
Ownership status understood, including roles beyond Ownable
Holder concentration acceptable
Claimed locks confirmed on-chain

Any failure is a reason to decline or to reduce size — not necessarily proof of fraud, but a known unknown you are choosing to accept.

What this does not tell you

Worth being honest about the limits:

It is not an audit. A contract can be verified, unprivileged, and still contain an exploitable bug.
It says nothing about the project. A technically clean contract can belong to a project that fails or abandons.
It cannot see off-chain risk — team, legal, or operational.
State can change. A contract with an upgradeable proxy or an active owner can become something else after you check.

This routine catches impersonation, honeypots, and undisclosed powers. Those are the majority of avoidable losses, which is why it is worth ten minutes.

Smart Contract Review Basics — the concepts behind each check.
How to Spot a Rug Pull
How to Pass Smart Contract Review — the same material from a project's side.

How to Verify a Token Smart Contract Before You Trade