Case Study: ERC-20 Token Audit — Sell-Blocking Honeypot and Allowance Bypass on Ethereum

What We Found

When the Uniswap trading pool checks how many tokens a seller has — which it does before executing every sell — this contract returns a fake balance of zero. The pool sees zero tokens available and cancels the transaction. This is a targeted, surgical sell block: regular balance checks elsewhere appear normal, but every sell attempt through the trading pool fails.

Why It Matters

Every sell transaction routed through Uniswap is permanently rejected. The deployer retains a bypass. This is a precision-engineered honeypot targeting the specific address that enables token liquidity.

What Should Be Done

Remove all address-conditional logic from balanceOf. The function must return the real balance for every address, including the Uniswap pair address.

What We Found

The contract stores the amount used in allowance accounting in a shared variable that the owner can change at any time. By setting this to zero, the owner can execute transferFrom calls that take tokens without reducing the approval counter. The same approval can be used repeatedly, indefinitely, to drain the same wallet.

Why It Matters

Owner can drain any approved wallet indefinitely with no reduction in allowance. Combined with the honeypot, users cannot sell or recover their tokens.

What Should Be Done

Store the transfer amount only in a local variable scoped to each function call. Never use a shared mutable state variable to pass amounts between functions.

What We Found

The owner can change the sell tax to as high as 99% in a single transaction with no delay and no notification to holders. A user could be holding tokens expecting a 5% sell tax and find themselves hit with 99% the moment they try to sell. Combined with the honeypot, this adds a secondary mechanism to punish any holder who finds a bypass.

Why It Matters

Holders face unpredictable and potentially total fee extraction on sells. The owner can move the fee to near-100% at any point, including immediately before a holder attempts to sell.

What Should Be Done

Cap the sell fee at a disclosed maximum in the contract (typically 10%). Protect fee changes with a 48-hour timelock so holders have time to exit before changes take effect.

What We Found

One wallet has unchecked control over every sensitive function: fees, trading gates, ETH drains, and fund movements. There is no second key required, no waiting period, and no oversight. If this wallet is compromised or acts maliciously, there is nothing stopping total fund extraction.

Why It Matters

Single point of failure for all security-sensitive operations. Key compromise or malicious action by the owner results in total loss for all holders.

What Should Be Done

Transfer ownership to a Gnosis Safe multisig with at least 3-of-5 signers. Apply timelocks to all parameter changes and fund movements.