HostHostDeFi › Guides › Contract red flags
How to read a token contract for red flags
A token contract is a list of things its deployer can still do to you. Reading it is pattern-matching a small parts kit — owner privileges, mints, blacklists, taxes, proxies — plus the market-layer flags the code can't show you.
The 60-second version: paste the contract address into a risk scanner and read the flag set — can it mint, pause, blacklist, change its own taxes, upgrade under your feet, and who holds the supply and the liquidity. The manual version is the same list read off the explorer's contract tab. Either way, you're answering one question: after I buy, what can this contract's owner still do to my position? This guide is the field map — what each flag lets a deployer do, where to see it, and which ones the code can't tell you at all.
Step 0: identity before internals
A flawless read of the wrong contract is the cloner's entire business model — they deploy a clean copy of a famous token's code, buy a few dollars of liquidity, and wait for ticker-searchers to do the rest. Before reading a single function, confirm the address and the chain against the project's canonical source. Verify the contract address first — the two-source rule takes thirty seconds and it's the check that makes every check below mean something.
The code layer: what the owner can still do
Open the contract on the chain's explorer (Etherscan, Basescan, Arbiscan — the address page's "Contract" tab). The read decomposes into five question-shaped flags:
| Flag | What it lets them do | Where it shows up |
|---|---|---|
| Owner privileges | Call every gated function below | owner() — a live address vs 0x0 (renounced) |
| Mint function | Print supply — dilute you to zero | mint() in source; a live mint authority |
| Pause switch | Freeze all transfers on command | pause()/paused, pausable base classes |
| Blacklist / whitelist | Choose per-wallet who can sell | blacklist/isBlacklisted maps gating transfer |
| Modifiable tax | Raise the sell fee to 99% after launch | setFee/setTax setters with no cap |
| Proxy / upgradeable | Swap the entire contract under your feet | delegatecall to a changeable implementation |
Ownership is the master flag. Every gated function answers to whoever owner() returns. "Renounced" — owner set to the zero address — freezes the rulebook as deployed, and it's the strongest single signal a contract can send. The two caveats that keep it honest: renouncement only matters if dangerous functions exist to renounce, and a proxy can be upgraded around the whole thing. A multisig or timelock holding ownership is the middle ground — slower, more accountable, not trustless. Single key vs multisig is the read on who the owner actually is.
The mint decides whether "supply" is a number or a suggestion. A live mint() means the deployer can create tokens at will — every chart, every market cap, every "locked" percentage recalculates the moment they do. Fixed supply with no mint path is the only version of "21 million" that means anything.
Pause, blacklist, and the trading switch are the honeypot parts kit. Any mechanism that gates transfer per-address — a blacklist map, a whitelist-only mode, a pause flag, a tradingEnabled toggle — is the same shape: a lever that decides who may leave. One flag doesn't convict a token (legitimate launches use anti-bot windows), but an owner-controlled lever over your exit deserves a reason it exists. The honeypot check sequences these with the sell simulation, and the variants guide covers the disguised versions.
Taxes are flags when they're writable. A fee-on-transfer is a design choice; a setFee that can move it to 99% after launch is a trapdoor. Read the setter's cap — the difference between "5% tax" and "5% tax today" is one line of code. Token taxes and what they do to your exit prices the effect.
A proxy means the code you read has an expiry date. Proxies delegate to an implementation contract the owner can replace — every flag above can be added later to a contract that read clean today. Check for delegatecall-style proxy patterns and who controls the upgrade path; the proxy risk guide is the deep version. This is also why "the contract is verified" is not a safety verdict — verified means readable, not benign.
The market layer: what the code can't tell you
A contract can be technically clean and still sit on a trapdoor of market structure:
- Liquidity disposition. If the deployer holds the LP tokens spendable, they can drain the pool — the rug that needs no honeypot code at all. Check whether the LP is burned, locked, or just sitting in a wallet: liquidity locks, explained and locked vs burned cover the difference that matters.
- Holder concentration. Top-10 wallets holding most of the supply isn't a code flag — it's a ceiling over every seller who isn't them. Reading the holder table is the skill; the benchmarks guide gives the numbers context.
- Deployer history. The address that deployed this contract deployed others — and explorers remember. A wallet with a trail of week-long tokens is telling you the cadence before you buy in.
- Has anyone actually sold? The strongest market-layer signal: thousands of buys, near-zero outsider sells. That asymmetry is the honeypot's signature in the data even when the code stays quiet.
The read, ordered: right contract? (identity) → who owns it? (renounced / multisig / lone EOA) → can it mint? → can it freeze or blacklist you? → can the fee move? → can the code itself be swapped? → is the liquidity door locked? → did anyone like you ever exit? Eight answers, and the scanner compresses all of them into one page.
Where the scanner fits — and its honest limits
The scanner automates this exact checklist: contract flags from static analysis and the provider feeds, the liquidity and holder reads from the market data, graded into one page. Use it as the fast pass — then read the flagged items yourself for the size you're actually risking. Two honest limits: scanners read today's contract (a proxy can change it tomorrow), and novel trap mechanisms lag the parts kit until the detectors learn them — which is why the manual field map above stays worth knowing.
Run the contract read now
Paste the address — owner controls, mint, pause, blacklist, tax, proxy, liquidity lock and holder spread in one pass. Free, no signup.
Frequently asked
How do I check a token contract for red flags?
Fastest: paste the address into a scanner and read the flag set — mint, pause, blacklist, modifiable tax, proxy, ownership, liquidity lock, holder concentration. Manually: the explorer's contract tab — verify the source, read the owner, and search the functions that gate the transfer path.
Biggest red flags in a contract?
An uncapped mint, a blacklist or whitelist controlling who sells, a pause on transfers, an owner-modifiable tax, and an upgradeable proxy. An owner that's a single wallet — not a multisig — concentrates all of it in one key.
What does renounced ownership mean?
owner() reads the zero address — no key exists that can call privileged functions, so the rules are frozen as deployed. Strongest single signal available, with two caveats: it only matters if dangerous functions existed to renounce, and a proxy can upgrade around it.
Does 'verified' on the explorer mean safe?
No — verified means the published source compiles to the deployed bytecode, so you can read what it does. A verified honeypot is still a honeypot; the badge buys readability, not safety.
Can a clean contract turn unsafe later?
Yes — through a proxy that delegates to an implementation the owner can swap. The code you read isn't necessarily the code that runs tomorrow; a timelock or multisig on the upgrade path softens it, a lone-EOA proxy is a blank check.
What can't the contract code tell me?
The market layer: holder concentration, whether liquidity is locked or pullable, the deployer's history, and whether outsiders have ever sold. Those reads come from pool accounts and the holder table — code review is half the check, never all of it.