Every day, hundreds of new tokens launch across Ethereum, BNB Chain, Base, Solana, and other chains. Most are worthless. A meaningful fraction are deliberately fraudulent — designed from the start to extract money from buyers before the team exits.
The gap between "worthless" and "fraudulent" matters operationally, but both outcomes are bad for the person who bought in. The question worth answering is: what can you actually check before committing funds, and how much does checking help?
There are specific, observable signals in on-chain data and contract code that separate likely-legitimate from likely-fraudulent tokens. None are definitive in isolation. Combined, they build a usable risk picture in a few minutes.
Why Scam Tokens Work the Way They Do
Most token fraud operates through one of three mechanisms, and understanding them explains what you're checking for.
Liquidity removal (the rug pull): A team deploys a token, creates a trading pair on a DEX, and attracts buyers. The team provided the initial liquidity — they hold the LP tokens representing their share of that pool. When they're ready to exit, they withdraw all the liquidity, leaving buyers with tokens they can't sell for meaningful value because there's nothing to trade against. The fraud is in the intent, not the mechanism: legitimate liquidity providers remove positions all the time.
Honeypot contracts: The contract is coded so buyers can purchase tokens but can't sell them. The sell function either reverts, charges a 99%+ tax that makes exiting economically pointless, or is gated behind conditions that block ordinary wallets. Buyers only discover this when they try to exit.
Backdoor mints and admin controls: The contract contains undisclosed privileged functions — mint unlimited new tokens, pause all trading, blacklist specific wallets, or force-transfer tokens. These get exercised after enough buyers are in.
The on-chain checks target the technical preconditions for each of these mechanics.
The Six Checks
1. Is the contract source code verified?
On Ethereum and Ethereum-compatible chains, verified contracts have their Solidity source code published on the block explorer (Etherscan for Ethereum, BscScan for BNB Chain, Basescan for Base) and confirmed as matching the deployed bytecode. Unverified contracts show only bytecode — you can't read what the code actually does.
Most legitimate projects verify their contracts. Many scam deployments don't bother, or deploy through proxy patterns that decouple the publicly visible code from actual execution. Unverified doesn't equal scam, but unverified combined with aggressive promotion and a new launch date is a red flag worth taking seriously.
2. Does the contract have dangerous admin functions?
A verified contract can still contain malicious design. Look for: unlimited mint authority (the owner can create new tokens at will, diluting all existing holders); trading pause (all transfers can be frozen, preventing anyone from selling); blacklist or whitelist controls (the owner can block specific wallets from trading); and fee modification (launch tax can be changed after deployment — 2% becomes 99%).
Automated scanners catch these efficiently. Token Sniffer (tokensniffer.com) and GoPlus Security (gopluslabs.io) analyze verified contracts against known risk patterns and report results immediately. They're not comprehensive — novel implementations can slip through — but they flag the standard abuse vectors reliably.
3. Is liquidity locked?
If the team can withdraw all liquidity immediately, the token is one transaction away from a rug. Check whether LP tokens are time-locked in a separate smart contract — services like Unicrypt, Team Finance, and PinkLock provide this. The lock address and expiry date should be publicly verifiable.
A short lock doesn't help much. A 7-day lock expires before most buyers have decided whether to exit; meaningful locks run months or longer. Check the expiry date, not just whether a lock exists.
4. Can you actually sell it?
This is the honeypot test. Honeypot.is runs a simulation: it attempts a test buy and test sell against the contract and reports whether the sell succeeds and what the effective tax rate is. A result showing that selling fails, or that the effective tax exceeds 50%, is a strong indicator of a honeypot structure.
This test doesn't catch every variant — some contracts are conditionally malicious, behaving normally during simulation but blocking sells after a threshold of buyers is reached. But it catches the most common implementations and takes about ten seconds.
5. How is the token distributed?
Check the holder list on the block explorer. If 80–90% of total supply sits in two or three wallets — excluding the contract itself and locked liquidity pools — that concentration creates two problems: those wallets selling creates extreme price impact, and the concentration likely represents undisclosed team holdings queued for a dump.
Some concentration is expected early in a token's life. A launch from six hours ago will look different from one that's been trading for months. What you're looking for is extreme concentration combined with other red flags, not concentration alone.
6. What does the trading history look like?
Pull the token up on DEXScreener or DexTools. Look at the actual transaction list. Organic trading looks varied: different wallet sizes, different transaction amounts, a mix of buys and sells from different addresses. Wash trading — used to manufacture volume and attract buyers — tends to show uniform transaction sizes, the same addresses recycling back and forth, or volume disconnected from any identifiable event.
Artificial volume isn't always visible by eye, but obvious patterns are worth noticing. A token showing $5 million in 24-hour volume from twelve wallets executing identical-sized trades in alternating directions is not the same as genuine market activity.
Where the Limits Are
Automated scanners match patterns against known fraud templates. They're good at catching what they've seen before. They don't catch novel structures, conditional logic designed to pass tests while behaving maliciously in production, or proxy contracts where the deployed bytecode differs from the verified source.
Off-chain behavior is entirely out of scope. A team can pass every on-chain check and still stop development, withdraw treasury funds through individually justifiable transactions, or simply disappear. These slow rugs don't trip any scanner because nothing verifiably fraudulent ever appears on-chain — it just looks like a project that stopped executing.
The realistic posture: these checks eliminate the majority of unsophisticated scam tokens quickly. They don't provide certainty on the remainder.
What's Changing
Basic honeypots and unverified contracts get flagged within seconds by tools now integrated directly into some popular wallets. The unsophisticated end of the scam spectrum has become harder to operate against informed buyers. The response has been escalation in technical sophistication: more contracts are verified but hide malicious logic in proxy upgrades; more use conditional execution that behaves cleanly under simulation.
Some DEX launchpads have started enforcing minimum liquidity lock periods before listing, which removes the immediate-rug option for the tokens they list. Transaction simulation — showing exactly what a transaction will do before you confirm — is becoming a default wallet feature, which helps catch approval-based attacks that often accompany scam token launches.
Confirmation and Invalidation
Confirmation that on-chain checks reduce exposure: Rug pull and honeypot losses remain concentrated in unverified contracts and contracts flagged by standard scanners. The tools are identifying the right population.
What would break this picture: Widespread losses in fully verified, scanner-clean contracts through novel mechanisms currently outside scanner scope; sophisticated conditional logic becoming the industry standard for fraud, rendering pattern-based tools ineffective.
Timing
Now: Every new token interaction benefits from a 60-second scanner check before committing any funds. Token Sniffer and Honeypot.is are free and fast.
Next: Wallet-native security layers are expanding to cover more of this analysis automatically before transaction confirmation.
Later: On-chain deployer reputation systems — flagging addresses that have previously deployed scam contracts — may add a useful pre-check layer that looks back at the team rather than just the current contract.
Boundary
This covers on-chain signals and tooling for pre-trade token assessment. It doesn't address phishing attacks, exchange compromises, social engineering, or off-chain fraud — those are separate threat surfaces with different mitigations. A token passing these checks isn't endorsed as legitimate or likely to perform well. The analysis identifies red flags; it doesn't certify absence of risk.
