Lesson 5 — Token contract red flags: ten patterns to scan for
Most malicious tokens reveal themselves in the contract source. Today: the ten code patterns that should trigger immediate skepticism, and how to spot each one.
Scam tokens — rug pulls, drainer setups, honeypots — almost always reveal themselves in the contract code if you know what to look for. The work isn't deep audit-level review; it's a ten-minute pattern-recognition pass. This lesson is the checklist. Run it on any token you're about to allocate to, and you'll catch a substantial fraction of the structurally dangerous designs before depositing.
**1. Mint function callable by owner.** Look for any function that increases `totalSupply` and is callable by an admin (`onlyOwner`, `onlyMinter`, or similar). A token with an active mint function gives the owner the power to dilute every holder to zero. Some legitimate tokens have mint functions controlled by governance with timelocks — that's different from a 'change-supply with a single signature' design. Search the source for `_mint` or `mint(` calls and trace who can invoke them.
**2. Blacklist or freeze function.** Functions named `blacklist`, `freeze`, `setBlocked`, or similar that prevent specific addresses from transferring. USDC and USDT have these (for sanctions compliance), but they're a specific feature of regulated stablecoins. A meme coin with a blacklist function is a token where the owner can stop specific users from selling — typically the early-buyers-other-than-insiders.
**3. Hidden admin / privileged transfers.** Functions that transfer tokens between arbitrary addresses without their consent. Search for `_transfer` calls that bypass `from == msg.sender` checks, or admin functions named `recoverTokens`, `adminTransfer`, `emergencyMove`. A legitimate-utility token rarely needs the operator to be able to move users' tokens.
**4. Pausable transfers without timelock.** A `pause()` function callable by admin without a timelock means the operator can freeze all transfers at any moment. This is sometimes used legitimately during emergencies, but combined with other red flags, it's a tool for executing exit liquidity.
**5. Fee-on-transfer with mutable fee.** Token contracts that take a fee on every transfer, with the fee rate or destination changeable by admin. Common rug pattern: launch with low fees, attract liquidity and holders, raise fees to 99 percent, drain. Check whether the fee parameters are `immutable` or admin-mutable.
**6. Liquidity not locked.** A token's tradeable liquidity (typically the LP tokens for the AMM pool) should be locked in a third-party locker (e.g., Unicrypt, Team Finance) or burned (sent to the dead address). If the LP is held in the deployer's wallet, they can withdraw it at any moment — the canonical rug pull. Check the LP token's holder distribution: an LP held entirely by a recently-active wallet is the highest-risk pattern.
**7. Renounced ownership theatre.** 'Ownership renounced' means the `owner` address was set to `address(0)` so no one can call `onlyOwner` functions. This is sometimes meaningful and sometimes theatre — if the ownership was renounced *after* admin functions were used to set permanent fees, blacklists, or mint allocations, the renunciation locks in the bad state. Check the transaction history: when was ownership renounced, and what was done before?
**8. Function selectors mismatching their names.** A function named `airdrop` whose 4-byte selector matches `transferFrom` (or any other transfer-equivalent) is a classic honeypot pattern. The user thinks they're claiming an airdrop; they're actually authorising a transfer from their wallet. This is rare on verified contracts (the source makes it visible) but common on unverified contracts where the calldata-to-function-name mapping is only visible through 4byte.directory lookups.
**9. External calls to suspicious addresses.** Functions that call out to external contracts the user has no reason to trust. A buy function that routes through a flash-loan-callable contract, or a stake function that delegates to a contract owned by the same admin — these create indirect drain paths. Trace external `call`, `delegatecall`, and `staticcall` instructions to their destinations.
**10. Anti-bot / honeypot logic that catches everyone.** Code that prevents transfers under specific conditions (e.g., 'only the deployer can sell during the first 24 hours,' or 'transfers above a certain size are blocked') started as legitimate anti-MEV measures but is routinely abused as a honeypot. Users buy, can't sell, and watch the price collapse. Read the `_transfer` function carefully for any conditional logic that asymmetrically benefits the deployer.
**The composite scan.** Each red flag alone is not necessarily disqualifying — some legitimate tokens have one or two for defensible reasons. The pattern that should trigger immediate exit: three or more red flags combined, especially mint + blacklist + mutable fee. This pattern is the textbook rug-pull setup, and applying the checklist takes under ten minutes.
Example
Run the checklist against a hypothetical recently-launched token. Contract source is verified — good, you can read it. Scan results: (1) Mint function exists, callable by `onlyOwner` — yes, red flag. (2) Blacklist function exists — yes, red flag. (3) Hidden admin transfer — no. (4) Pausable with no timelock — yes, red flag. (5) Fee-on-transfer with mutable fee — yes, currently 5 percent, no maximum — red flag. (6) LP locked — no, held entirely by deployer wallet — red flag. (7) Ownership renounced — no, deployer remains owner. (8) Mismatched selectors — no. (9) Suspicious external calls — one, to a contract owned by the same deployer — yellow flag. (10) Honeypot logic — no obvious patterns. Composite: five red flags, one yellow flag, fully controlled by a single owner. This is the textbook profile of a token designed to be rugged. Refuse to interact.
Common mistakes
- Skipping the checklist because 'the chart looks good.' Charts can be manipulated; the contract can't lie.
- Treating any single red flag as automatically disqualifying. Context matters — some legitimate stablecoins have blacklist functions because of regulatory compliance.
- Forgetting to check the LP token. The LP not being locked is one of the most-reliable rug-pull indicators.
- Trusting 'renounced ownership' without checking what was done before renunciation. Renouncing locks in whatever state existed at the moment of renunciation, good or bad.
- Running the checklist only on the implementation, not the proxy. For upgradeable tokens, the proxy can change the implementation — meaning today's clean code can become tomorrow's drain.
Check your understanding
You're evaluating a new meme token. The contract is verified. You find: a mint function callable by the owner with no cap, a blacklist function, fee-on-transfer with a mutable fee currently at 5 percent and no maximum, LP held entirely by the deployer wallet, and ownership not renounced. What is the most defensible response?
Key terms covered
Sources & further reading
- Primary
- Primary
- SecondaryGoPlus — Token Security API
Public scanner that flags common token-contract red flags automatically.
- Secondary
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.