Case Study: ERC-20 Token Audit — Four Critical Vulnerabilities Including Honeypot and Rug Pull on Ethereum

50/100

Risk Score (C)

Total Findings

Critical + High

Severity Distribution

Executive Summary

This contract combines a sell-blocking honeypot with a developer wallet backdoor and an immediate liquidity rug pull vector. The balance reporting function is deliberately overridden so regular users always appear to hold zero tokens, making every sell fail. A separate backdoor grants the dev wallet unlimited allowance that never decreases. And when trading opens, LP tokens go directly to the owner — who can remove all liquidity at any time.

The sell fee can be configured up to 99%, and the contract allows sending accumulated ETH to arbitrary owner-controlled addresses without any validation. The combination of all four critical vectors means holders have no path to recover funds under any scenario.

Risk Assessment

This contract is an engineered theft mechanism. Holders cannot sell, the dev wallet can drain any approved account, and the deployer can remove all liquidity at will. There is no legitimate reason to hold this token.

Key Findings

critical

Allowance Bypass Backdoor for Dev Wallet via State Variable Manipulation

What We Found

The dev wallet has a special shared variable that is injected into the allowance accounting. Every time the dev wallet executes a transferFrom, the deduction amount is replaced with this variable's value — which the dev can set to zero. This means the dev wallet can take tokens from any account that approved it without ever reducing the approval counter, enabling repeated unlimited drainage.

Why It Matters

The dev wallet can repeatedly drain any account that has granted it approval. The allowance is never decremented, enabling unlimited and repeatable theft.

What Should Be Done

Remove the shared state variable used in allowance accounting. The deduction amount must come only from the function's own parameter, scoped to that call.

critical

Honeypot via Manipulated balanceOf() — Prevents All Sells

What We Found

The contract overrides the standard balance reporting function to return zero for regular users. Trading platforms check this function before allowing a sell. Because it always returns zero for non-privileged addresses, every sell attempt is rejected. Only wallets with the bypass code path — specifically the deployer — can successfully sell.

Why It Matters

All sell transactions by regular holders are permanently blocked at the routing layer. The deployer retains full sell capability. User funds are irreversibly trapped.

What Should Be Done

Remove all address-conditional logic from balanceOf. The function must return the actual token balance from the internal mapping for every address.

critical

tx.origin Used for Authorization — Selective Bypass Enabling Honeypot

What We Found

The contract uses a flawed method to identify who is really in charge of a transaction. This method can be tricked by attackers and, more importantly, is used here to create the two-tier system that lets the deployer sell while blocking everyone else. If the deployer's wallet is ever used in a phishing transaction, the attacker also gains sell access.

Why It Matters

The honeypot bypass relies on a phishable authorization primitive. The system is structurally vulnerable and cannot be safely secured without a full redesign.

What Should Be Done

Replace all tx.origin authorization with msg.sender. The tx.origin primitive should never be used for access control in any modern contract.

critical

LP Tokens Sent to Owner on OpenTrade() — Rug Pull Vector

What We Found

When the contract launches trading, all liquidity pool tokens go directly to the owner's wallet instead of being locked. Liquidity pool tokens represent ownership of the trading pool. With them in hand, the owner can call the liquidity removal function at any time and drain the entire trading pool, making the token instantly worthless.

Why It Matters

Owner can execute a complete liquidity removal at any time after launch. Combined with the honeypot that prevents user sells, this forms a total fund extraction mechanism.

What Should Be Done

Send LP tokens directly to a time-lock contract at launch. Use a minimum lock period of 6-12 months enforced by a reputable third-party locker.

What a Secure Contract Should Have

balanceOf returns the real stored balance for every address — no conditional overrides based on caller identity

Allowance deductions use only the amount passed to the function — no shared state variables

tx.origin is never used for any authorization logic

LP tokens are locked at a third-party locker address at the moment of liquidity addition

Sell fee is capped at a disclosed maximum (typically 10%) with no runtime override

Disclaimer: This case study is published for educational purposes only. It reflects the state of the analyzed contract at the time of audit and does not constitute investment advice, an endorsement, or a guarantee of security. Smart contracts may be modified after an audit. HyperAudit is not liable for losses arising from interaction with any contract referenced in this report. Project names and addresses have been removed to protect ongoing remediation efforts. For a full audit of your own contracts, visit hyperaudit.io.

Building a project?

Get the same depth of analysis on your own contracts before you deploy. Reports delivered in hours, not weeks.

Audit Your Contract

Thinking about buying a token?

Before you buy, find out if the contract is safe. We can audit any token on any EVM chain and tell you exactly what risks you're taking — in plain language you can act on.

Check a Token Before You Buy

← Back to all articles