Case Study: ERC-20 Token Audit — Deliberate Honeypot with Six Critical Vulnerabilities on Ethereum
Executive Summary
This contract is one of the most aggressively engineered scam tokens we have audited. Six coordinated critical vulnerabilities work together: a broken balance function that returns zero to trading platforms (preventing sells), a shared mutable state variable that lets the deployer steal tokens from any approved wallet, and ETH drain conditions hardwired to always be true so every sell empties the contract to the deployer.
The code is deliberately obfuscated — variable and function names are chosen to mislead reviewers, and the logic is structured to look legitimate on a quick pass. Reviewers who do not trace every execution path will miss the traps.
Every standard safeguard is absent: no fee caps, no timelocks, no multisig, no locked liquidity. The deployer retains total unilateral control over all funds.
Risk Assessment
Do not interact with this contract. It is a deliberate, multi-layered scam: holders can buy but can never sell, and the deployer can drain both tokens and ETH at will. Token holders face permanent and total loss of funds.
Key Findings
Broken balanceOf — Missing Return Path Creates Honeypot Trap
What We Found
The function that reports your token balance to trading platforms is deliberately broken. It returns zero for regular users, so when anyone tries to sell, the platform sees a zero balance and blocks the transaction. The deployer has a special code path that bypasses this, so only they can sell. You can buy in, but you can never get out.
Why It Matters
All sell transactions by regular holders will be permanently rejected. The deployer retains full ability to sell. User funds are irreversibly trapped.
What Should Be Done
Remove the conditional balance override entirely and return the actual balance stored in the mapping for every caller without exception.
Shared State Variable Enables Allowance Bypass Backdoor
What We Found
A hidden shared variable lets the deployer's wallet receive tokens from any account that has ever granted an approval — and the approval counter is never reduced. The deployer can drain the same wallet over and over, indefinitely. The variable is named to look like a legitimate internal counter, hiding its true purpose.
Why It Matters
Deployer can repeatedly extract tokens from any approved wallet with no reduction in allowance. This enables unlimited, repeatable theft from holders.
What Should Be Done
Replace the shared state variable with a local variable scoped to each transfer call so allowances are correctly decremented on every use.
tx.origin Used for Authorization in balanceOf
What We Found
The contract identifies whether a transaction is allowed based on who originally triggered it, not who is calling the function right now. This is a known flawed technique that can be exploited by attackers to trick the contract into thinking a privileged user is acting when they are not — and it is used here to reinforce the honeypot bypass for the deployer.
Why It Matters
The authorization bypass relies on a phishable primitive. Attackers can craft malicious contracts to impersonate privileged wallets, and the honeypot mechanism is structurally unsound.
What Should Be Done
Replace all tx.origin checks with msg.sender. Never use tx.origin for authorization in any modern contract.
Multiple Unrestricted ETH Drain Vectors for Deployer — Rug Pull
What We Found
Several functions allow the deployer to send the entire ETH balance of the contract to their own wallet in a single transaction. There are no limits, no delays, and no approvals needed. This, combined with the honeypot that traps user funds, means the deployer extracts ETH while holders are permanently locked in.
Why It Matters
Deployer can drain 100% of accumulated ETH at any time. Combined with the sell-blocking mechanism, users cannot recover their investment while the deployer can exit freely.
What Should Be Done
Remove unilateral ETH drain functions. Implement per-call withdrawal caps, a 48-hour timelock, and multisig approval for any fee extraction.
What a Secure Contract Should Have
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 ContractThinking 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