Case Study: ERC-20 Token Audit — Three Critical Honeypot and Backdoor Mechanisms on Ethereum

What We Found

The function that tells trading platforms how many tokens you hold is intentionally broken for regular users. It silently returns zero instead of your real balance, so every sell attempt is rejected. The deployer bypasses this check and can sell freely. This is the core of a honeypot: you can buy, but you can never sell.

Why It Matters

All regular holder sell transactions will be rejected. Only the deployer can sell. User funds are permanently trapped with no recovery path.

What Should Be Done

Remove all conditional balance overrides and return the actual balance from the token mapping for every address without exception.

What We Found

Instead of reducing your allowance after each transfer as required, the contract uses a shared counter that the deployer can reset. This lets the deployer drain your wallet repeatedly using the same approval, and your allowance never decreases. The mechanism is hidden behind innocuous-looking variable names.

Why It Matters

Deployer can repeatedly drain any approved wallet indefinitely. The allowance system — the primary user-facing safety mechanism — is fully bypassed.

What Should Be Done

Store the transfer amount in a local variable within each function call. Never use a shared state variable to pass values between functions in an allowance flow.

What We Found

A separate hidden function lets the deployer overwrite the amount used in allowance accounting at any time. By setting this value to any number before a transfer, the deployer controls exactly how much can be taken from any account that has given an approval — effectively giving them a master key to all approved wallets.

Why It Matters

Deployer can set the deduction amount to zero, making every transferFrom call take the full balance regardless of the original approval amount.

What Should Be Done

Remove the function that externally sets the shared transfer amount variable. The transfer amount must only come from the caller-provided argument in the transfer function.

What We Found

The condition that triggers the ETH send to the deployer checks whether a number is greater than or equal to zero. Since the number type can never be negative, this condition is always true. Every sell transaction drains the entire ETH balance to the deployer, regardless of how much ETH should stay in the contract.

Why It Matters

Every sell transaction results in complete ETH drainage to the deployer's wallet. There is no scenario where this condition is false.

What Should Be Done

Replace the tautological condition with a meaningful threshold check against a configurable minimum balance. Only send ETH when it meaningfully exceeds operating costs.