Every new token launch is a gamble — not because of market volatility, but because you often cannot tell whether the contract is legitimate or a carefully disguised trap. The difference between a real project and a honeypot is usually hidden in the contract code, liquidity status, and holder distribution. All of that data is on-chain and publicly accessible.

This guide walks through a complete verification checklist you should run before buying any token. Every step uses free, publicly available data.

BLUF: Before buying any token, check six things — (1) source code is verified, (2) liquidity is locked, (3) holders are distributed, (4) no hidden mint function, (5) sell tax is reasonable, (6) both buys and sells appear in transaction history. If any of these fail, do not buy.

Step 1: Verify the Contract Source Code

The single most important check. A verified contract means its Solidity source code is published on a block explorer like Etherscan, and you can read exactly what the contract does.

What to Look For

CheckSafeDangerous
Source codeVerified and readableNot verified (bytecode only)
StandardERC-20 or ERC-777 compliantCustom transfer logic with extra conditions
Proxy patternTransparent, documented upgrade pathHidden proxy that can change logic at any time
Owner privilegesLimited or renouncedOwner can mint, pause, or blacklist at will

How to Check

  1. Find the token contract address (from a legitimate source — the project’s official site or a trusted DEX)
  2. Go to Etherscan, search the address, and look for a green checkmark indicating verified source code
  3. Read the contract tab — especially the transfer(), transferFrom(), and approve() functions
  4. Check for any functions the owner can call: mint(), pause(), setBlacklist(), setFee()

A contract without verified source code is an automatic no. You are sending funds to code you cannot read.

Red Flag: Hidden Proxy Contracts

Some tokens use a proxy pattern where the “real” logic lives in a separate contract that the owner can swap out. This means the safe contract you verified today can be replaced with a malicious one tomorrow. Check if the contract has a delegatecall to an upgradable implementation address — if that address is controlled by an EOA (externally owned account), the owner can change the rules at any time.

Step 2: Check Liquidity Lock Status

Liquidity is what allows you to buy and sell the token. If the developer holds the liquidity pool tokens and can withdraw them at any time, they can execute a rug pull — removing all liquidity and making the token untradeable.

What to Look For

  • Liquidity locked: LP tokens are held by a time-lock contract (Team Finance, UncxNetwork, PinkLock, etc.) for a minimum of 6 months
  • Liquidity burned: LP tokens sent to a dead address (0x000…dEaD), permanently removing the ability to withdraw
  • Liquidity unlocked: LP tokens held by the deployer or a small group — high risk of rug pull

How to Check

  1. Go to the token’s liquidity pool on a block explorer
  2. Find the LP token contract address
  3. Check the top holders of the LP token
  4. If the deployer address holds LP tokens with no lock, liquidity is unlocked

A lock of less than 3 months is a warning sign. A lock of less than 1 week is meaningless.

Step 3: Analyze Holder Distribution

Even with locked liquidity and verified source code, concentrated token ownership is dangerous. If one address controls 30%+ of the supply, they can dump and crash the price instantly.

What to Look For

MetricHealthySuspicious
Top 10 holders (excluding LP/exchange)< 25% of supply> 40% of supply
Number of holders1,000+< 100
Deployer balance< 5% (team tokens vested)> 20%
Known exchange addresses in top holdersPresent (organic trading)Absent (no real volume)

How to Check

  1. Go to the token page on Etherscan → Token Holders tab
  2. Identify the LP pair address and exchange addresses — these are legitimate large holders
  3. Exclude those and look at the remaining top 10 holders
  4. If unknown addresses hold large percentages, trace them using token flow analysis — check if they received tokens from the deployer before launch (pre-allocation to insiders who plan to dump)

For a deeper dive into identifying who owns what, see our wallet labels guide.

Step 4: Check for Mint Functions

A mint function lets the contract owner create new tokens out of nothing. If present and uncapped, the supply is effectively unlimited — the owner can mint millions of tokens and dump them.

How to Check

  1. Read the verified contract on Etherscan (Contract → Read Contract)
  2. Check if totalSupply can increase — compare maxSupply vs totalSupply
  3. Search the source code for mint( or _mint(
  4. Check who can call the mint function — if it’s restricted to onlyOwner, the owner has unlimited inflation power

A legitimate token with a fixed supply should have no mint function, or one that is permanently disabled (e.g., renounced owner role). Compare the token’s max supply against its circulating supply to confirm.

Step 5: Verify Buy and Sell Tax

Many DeFi tokens implement transaction fees (taxes) — a percentage deducted on each buy or sell. Legitimate projects use these for liquidity generation, reflections, or treasury. But taxes can also be weaponized.

Tax Risk Levels

Tax RateAssessment
0–5%Normal for DeFi tokens
5–15%Acceptable if well-documented
15–25%High — verify the use case
25–50%Very high — likely unsustainable
50–100%Effectively a honeypot — you cannot sell profitably

How to Check

  1. Read the contract’s fee logic in the verified source code
  2. Look for setFee(), setTaxRate(), or similar functions — check the maximum value they can be set to
  3. If the owner can change the fee to 100% at any time, the token can become a honeypot instantly
  4. Simulate a sell transaction using a tool like Honeypot.is to see the actual received amount

Some contracts have dynamic fees that change based on market conditions. If the fee can be set above 10% by the owner, treat it as a risk factor.

Step 6: Review Transaction History

The simplest check: can people actually sell? Look at the token’s recent transactions on Etherscan or DexScreener.

What to Look For

  • Both buys and sells present: Healthy — the market is functioning
  • Only buys, no sells: Massive red flag — likely a honeypot where sells revert
  • Sells with very small received amounts: Hidden high tax
  • Large sells from the same address repeatedly: Insider dumping

Step 7: Check the Deployer’s History

A scammer’s address usually has a history. Check the deployer address on a block explorer.

  • Has this address deployed other tokens? Check if those tokens are still active or abandoned
  • Did the deployer receive funds from a mixer like Tornado Cash?
  • Is the address flagged on any blacklist databases?
  • Does the address have ties to sanctioned entities?

For tracking deployer addresses and understanding on-chain identities, see our on-chain analysis workflow guide.

Quick Reference: The 30-Second Checklist

Before buying, confirm:

  • Source code is verified on Etherscan
  • Liquidity is locked for at least 6 months (or burned)
  • No active mint function (or owner role renounced)
  • Owner cannot set tax above 10%
  • Owner cannot pause trading or blacklist addresses
  • Top 10 holders (excluding LP/exchanges) control < 30% of supply
  • Both buys AND sells appear in recent transactions
  • Deployer address has no scam history
  • Project has a contract audit from a reputable firm (optional but preferred)

Using the Token Risk API

For developers building safety checks into applications, Onchain Diary provides a token risk API that returns a comprehensive security report for any token address. The API aggregates data from multiple security sources into a single structured response, covering:

  • Contract security (honeypot detection, source verification, proxy detection)
  • Trading security (buy/sell tax, trading cooldown, slippage limits)
  • Holder analysis (concentration, known whale addresses)
  • Market data (liquidity, volume, age)

For implementation details, see the token safety API guide.

What On-Chain Verification Cannot Catch

No checklist is foolproof. These risks exist even when all on-chain checks pass:

  • Off-chain fraud: Social media hype, fake partnerships, and Discord scams don’t leave on-chain fingerprints until the damage is done
  • Delayed rug pulls: A contract can be safe for months, then the owner calls an unlocked function at the moment of peak liquidity
  • Cross-chain complexity: Tokens bridged across chains may have different contract behavior on each chain
  • MEV exploitation: Even legitimate tokens can be exploited by sandwich attacks and front-running — on-chain security doesn’t protect against MEV

Always combine on-chain verification with basic common sense: if a project promises guaranteed returns, has anonymous founders with no track record, and its community is purely hype-driven, the contract may be clean but the project is still a scam.