TrustPad Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

This TrustPad (TPAD) token on Ethereum routes every transfer through a burnTokenCheck modifier that the owner can tune. Holders that the owner has not whitelisted can only send tokens to the Uniswap V2 router address stored in _unirouter or to _owner; any other recipient reverts with the misleading message "ERC20: transfer amount exceeds balance". The owner can whitelist or blacklist addresses through functions named increaseAllowance and addApprove, and can change _safeOwner through decreaseAllowance.

De.Fi's REKT database lists the token as an Exit Scam/Honeypot, saying the contract owner could disable the transfer function, which restricted users in selling their tokens.

How it happened

  1. The constructor sets _owner = msg.sender; and _safeOwner = msg.sender;, and mints 100,000,000 tokens (18 decimals) to the owner. _unirouter is hard-coded as 0x7a250d56…F2488D, and _sellAmount starts at 0.
  2. Both transfer and transferFrom call _approveCheck, which runs the burnTokenCheck(sender,recipient,amount) modifier. The check is applied to the token's sender (the from address), not to msg.sender.
  3. While _owner == _safeOwner, any transfer whose sender is the owner runs _safeOwner = recipient; and then proceeds, so the first owner transfer hands the privileged _safeOwner role to its recipient. After that, a transfer passes if sender == _owner || sender == _safeOwner || recipient == _owner; when the owner sends to itself, _sellAmount = amount is set.
  4. For every other sender: a whitelisted address passes; a blacklisted address must have recipient == _unirouter; any other address passes only if amount < _sellAmount, otherwise it must also send to _unirouter. Because _sellAmount is 0 until the owner sets it, amount < _sellAmount is false, so an ordinary holder can only send to the router or to _owner. A sale routed through the router pulls tokens with transferFrom(holder, pair, amount); its recipient is the pair, not _unirouter, so it reverts for a non-whitelisted holder unless the pair address is _owner, which the code does not show.
  5. Once _sellAmount is set, a non-whitelisted holder sending a smaller amount to _safeOwner is moved to the blacklist by _blackAddress[sender] = true; _whiteAddress[sender] = false; while that transfer still goes through.
  6. The owner-only setters are named like ERC20 helpers: increaseAllowance(address[]) whitelists and un-blacklists, addApprove(address[]) blacklists and un-whitelists, decreaseAllowance(address) sets _safeOwner, and multiTransfer whitelists its first approvecount receivers and gives them a maximum allowance for _unirouter. _mint is public and owner-only, so the owner can add to its own balance and the total supply. The source has no ownership transfer or renounce function.
  7. Whether purchases from the pair pass depends on whether the pair is _safeOwner or whitelisted, which the code alone does not show. De.Fi's REKT database lists the token as an Exit Scam/Honeypot.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract TPAD

Evidence

Same attack technique

Browse all hacks →
Ethereum Polylastic Loss not disclosed BNB Chain MoonSquirrel Loss not disclosed Ethereum The Doge Space X Loss not disclosed BNB Chain KimJongMoon Loss not disclosed

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.

Start Free Trial Explore attack classes