Audits are not a magic shield. They are a snapshot of risk, triaged by severity, at the time of review. If you know how to read those severity levels, you can tell whether a protocol is carrying a loaded gun or just has a loose strap on the holster.
Below is how I interpret severities when I audit, how teams should respond, and what regular traders can infer before pressing Buy.
Why severity matters more than the badge
An “audited” stamp alone is useless. What matters is which issues were found, how severe they are, and whether the fixes landed on-chain. A protocol with one unfixed critical is a different animal than a protocol with five low nitpicks.
Severity expresses two things at once. First, the impact if exploited. Second, the conditions or likelihood of triggering it. The art in a good audit is weighing both without diluting urgency. When a report from Consensys Diligence, CertiK, PeckShield, or Hacken says “Critical,” teams should treat that as a production outage with risk to funds, not a backlog item.
Investors should read the diff between “findings” and “resolved.” If read more the fix requires a contract redeploy or a timelock upgrade, make sure it actually happened on the deployed address. A quick Etherscan contract check often exposes the truth.
The common severity tiers, in plain English
Critical
This is the fund drainer tier. Think reentrancy that lets an attacker empty a vault, infinite mint that inflates supply, or a price oracle that can be manipulated with a single trade. A token with an owner-only setFeeTx that can set fee to 100 percent on sells lives here for traders because the token cannot sell once the owner flips the switch. That becomes a practical honeypot crypto pattern when the sell path is always blocked or punished.
Criticals require immediate patching, pausing, or pulling liquidity. If the system cannot be paused, you are gambling with user funds. No sugarcoating.
High
High means serious loss is plausible, often via privilege misuse or edge cases that are easier to reach than teams admit. Examples include an unbounded transferFrom that fails to decrement allowances in custom ERC20 logic, admin functions that can whitelist insiders, or flawed fee take math causing value leakage.
In token contracts, a sell restriction guarded by an owner-controlled flag can sit in High if the team promises to renounce later, yet the code still enables arbitrary changes to maxTxAmount, trading enable flags, or blacklist toggles. If renounceOwnership is missing or nonstandard, upgrade risk stays high.
Medium
Medium issues can cost money, but usually need more setup, more capital, or specific timing. Rounding errors that accrue to the protocol, vault share calculation drift, or imperfect slippage checks fit here. Market manipulation that needs multi-block positioning, not a single click, often lands as Medium.
For traders, Medium can hide in DEX mechanics. If the token exempts certain addresses from fees but not others, sandwich bots can lean on those asymmetries. The impact per user may be smaller, yet it compounds.
Low
Low is about correctness, clarity, and minor grief. Unchecked return values, misleading events, or poor input validation. Not exciting, but low friction to fix. Too many lows still add up to maintenance pain and incident noise.
Informational and Gas
Informational covers style and documentation. Gas relates to optimization. Neither should block a launch, but both signal engineering discipline. Teams that clean up gas suggestions usually show they care about long-term costs and readability. That correlates with faster incident response later.
Severity is not just impact, it is context
The same bug can jump tiers depending on the system. A mint function gated by a 2-of-5 multisig is risky, but less so than a single EOA holding the key. A reentrancy in a read-only function is informational. A reentrancy in a token hook that touches a lending market is critical.
When an audit labels something Medium because “admin must misbehave,” ask who is admin. If it is a fresh deployer wallet on BNB Chain with no timelock and no multisig, I treat that as High in practice. Severity frameworks are guides, not blindfolds.
How auditors weigh honeypots and sell restrictions
Honeypots show up in code paths that let you buy but revert on sell, or confiscate most of the sell proceeds via adjustable taxes. I look for:
- A gated transfer or transferFrom that checks pair address and blocks sells if a flag is set or if sender is not whitelisted. setFeeTx or similar functions that can spike fees mid-flight, especially different fees on sell vs buy. Blacklist or restrictWhale mechanics that can arbitrarily mark retail wallets. Liquidity controls where trading is disabled for the public until the team flips a switch, then never flipped. Proxy patterns that look safe today but delegate to a future implementation that hides the trap.
From a severity lens, a permanent trap is Critical. A temporary restriction with a plan to renounce and documented parameters can be Medium or High, depending on how provable the plan is. Public commit to renounceOwnership means little until you see it executed and verified on Etherscan or BscScan.
Community tools like a honeypot token checker or safe token scanner help, but they are not omniscient. They often simulate a buy and a sell against the main liquidity pool. If liquidity migrates, or the token routes sells through a different path, the check can miss it. Always confirm the code, not just the outcome.
What each severity usually implies for teams and users
- Critical - stop the bleeding. Pause, revoke, or pull front ends until fixed. Disclose promptly. High - schedule an urgent patch, ship with a timelock if possible, and publish clear mitigations. Medium - fix in the next sprint, add monitoring, and document risk to users. Low - tidy up. Take the easy wins. Informational/Gas - optional, but a proxy for code health and future agility.
Reading an audit beyond the headline
Start with the findings, but do not stop there. Good reports include a remediation section with code diffs or commit hashes. Cross reference those hashes with the deployed bytecode via an Etherscan contract check. If it is a proxy, verify both the proxy and the implementation. Read the trust model. Does the protocol depend on an external price oracle, a cross chain bridge, or a DEX LP that the team controls?
Check whether the audit was for the exact version you are using. A surprise upgrade after the report resets the risk profile. Firms like PeckShield often flag post audit incidents on X, and on-chain sleuths amplify them fast. Pay attention when that swarm lights up your token.
Quick pre-trade checks you can do in five minutes
- Search the token on Etherscan or BscScan, open the contract, and check Read/Write Contract for functions like setFeeTx, setTax, blacklist, enableTrading, excludeFromFee, and renounceOwnership. If write functions are hot and owner is an EOA, caution. On Etherscan, simulate a small transfer in the Read Contract tab if supported, or use a honeypot token detection tool for a quick bsc honeypot check on BNB Chain. Treat a failed sell simulation as a red flag. On DexScreener, inspect the main pair and liquidity depth. Thin liquidity plus volatile fees often equals pain. If the pool was just created and ownership is unverified, assume higher risk. On CoinGecko, look for contract verification status and links to audits. If an audit exists, confirm it references the same contract address and implementation. Review on-chain owner actions. In the token’s Etherscan “Contract Creator” tab, scan for ownership transfers, proxy upgrades, or large mint calls. Suspicious activity often precedes a trap.
Ownership, fees, and trade controls that flip severity
Admin power is the single biggest multiplier on risk. A contract with perfect math can still rug if the owner can alter transfer logic. If a token has:
- renounceOwnership missing or replaced with a fake version that only emits an event, not an actual state change, the risk jumps. Fee setters like setFeeTx or setSellTax without caps, the owner can raise taxes to 99 percent and drain value from retail selling into the LP. Blacklist controls that can target arbitrary addresses, you are trusting the admin not to hit back on sellers. Sometimes the check looks like require(!isBlacklisted[sender]), other times it is a modifier on sell path only. Trading toggles like enableTrading that sit false until launch, then stay controllable. Teams may promise they will flip it and renounce, but many never do.
Severity ratings in token audits should reflect these knobs. A fully renounced token, immutable after launch, lowers High to Medium in many cases. A proxy with a multisig owner, plus a timelock, can also reduce practical risk. Without those controls, the same code is far more dangerous.
Audits and real life exploit stories
Think about the classics. Reentrancy tore through early DeFi before pull pattern withdrawals became normal. Price oracle manipulation drained lending markets when spot DEX prices were trusted without TWAP. Infinite mint hit multiple bridges when message validation failed.
Severity follows blast radius. If a bug lets a small LP swing a protocol’s valuation, that is High to Critical. If it needs a billion dollar position and 12 blocks of sequencing, it falls to Medium. As frequently highlighted by security firms like PeckShield and Consensys, the line between Medium and High often shows up in the mempool when an attacker demonstrates feasibility.
What severity should change for you
Severity is a decision tool. For builders, it drives sprint priority and requires comms. For users, it sets position size and timing. If an audit flags High issues that are unfixed, I treat the token like a live beta and size accordingly. If the only findings are Low and Informational, I still check owner powers, because that sits outside the usual severity buckets and can dwarf them.
If you want to avoid crypto scams, you cannot outsource judgment. Use auditors as a filter, then do the basic checks. A check if token is scam mindset looks at both code and control, not just a single report.
A minimal severity playbook for teams and traders
- Builders - fix Criticals before launch, and gate risky functions behind a timelock and multisig. Publish exact commit hashes. Builders - cap fee setters in code, and document limits in the README. If you promise to renounce, set a date and do it on-chain. Traders - assume centralized fee and blacklist power means you might be the exit liquidity. Size small or pass. Traders - confirm post audit changes on the deployed address, not in a PDF. Verify the proxy implementation. Everyone - monitor X and on-chain alerts. Community sleuths often beat formal disclosures by hours.
The limit of scanners and the value of habit
A safe token scanner can spot common tripwires, but it will not reason about upgradeability, off-chain governance, or social engineering. The reflex you want is simple: read the write functions, glance at the owner, skim the recent transactions, and understand the sell path. If a token brags that “you can always sell” yet the code gates sells on a flag the owner controls, believe the code.
Severity labels help you triage. The rest is pattern recognition. When you practice those five minute checks and weigh audit findings with context, you stack the odds in favor of DeFi safety. And if a token smells off, let it pass. There will always be another chart on DexScreener that looks tempting without you needing to discover the hard way that a token cannot sell.