SuperSwap Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

SuperSwap (SUSWA) is an Ethereum token whose transfer and transferFrom both run through a custom burnTokenCheck modifier. By default, anyone other than the owner and a privileged _safeOwner address can only move tokens to the hard-coded address 0x7a250d56…F2488D, so sending tokens to any other address, such as a liquidity pair, reverts with a misleading balance error. The owner can also whitelist or blacklist individual addresses and set a threshold that blacklists a holder after a sale.

De.Fi's REKT database lists SUSWA as an exit scam/honeypot and states that the contract owner could disable the transfer function, which restricted users in selling their tokens. The code shows these controls exist; no transaction in the sources opened here shows the owner using them.

How it happened

  1. At deployment, the constructor runs _mint ten times with initialSupply*(10**18). Inside _mint, the line _balances[_owner] = _balances[_owner].add(amount); credits the owner every time, while the Transfer event names ten different recipient addresses. Tokens that explorers show as sent to those addresses are therefore recorded in the owner's balance.
  2. _safeOwner starts as the owner. The first transfer by the owner sets it: if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}. The owner can reassign it at any time with decreaseAllowance(address safeOwner), a function whose name suggests an allowance change but which only sets _safeOwner.
  3. For every other sender, _sellAmount starts at 0 (uint256 private _sellAmount = 0;), so amount < _sellAmount is false. The code falls to require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). A holder can then only send tokens to 0x7a250d56…F2488D; a transfer to any other recipient, including a liquidity pair address, reverts. The one exception is a transfer to _owner, which passes via recipient == _owner.
  4. The owner controls who is exempt. increaseAllowance(address[] receivers) sets _whiteAddress[...] = true, and whitelisted senders skip all checks. addApprove(address[] receivers) sets _blackAddress[...] = true, and blacklisted senders hit the same require. multiTransfer also whitelists its first approvecount receivers and sets their allowance to the maximum for 0x7a250d56…F2488D.
  5. The owner can open a narrow window by sending tokens to itself: if (sender == _owner && sender == recipient){_sellAmount = amount;}. A non-listed holder may then transfer amounts strictly below that figure, but if the recipient is _safeOwner the code sets _blackAddress[sender] = true, and the holder is blocked by step 3 afterwards.
  6. What happened: De.Fi's REKT database lists SUSWA as an exit scam/honeypot where the owner could disable transfers and restrict selling. The sources opened here do not show a specific transaction in which these functions were called, nor any loss figure.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain UNITYtoken Loss not disclosed BNB Chain Binance-Peg Polygon Loss not disclosed BNB Chain ElonTech Loss not disclosed BNB Chain KitKat 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