Gigachad Kishu Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

Gigachad Kishu (GISHU) is an Ethereum token (contract 0xd92a608a…20881d) whose transfers pass through an owner-controlled burnTokenCheck modifier. With the default _sellAmount of 0, holders the owner has not whitelisted can only send tokens to the hard-coded _unirouter address (or to the owner), so a sale that pays tokens to a trading pair reverts with the message "ERC20: transfer amount exceeds balance" even when the balance is sufficient. The owner can whitelist or blacklist any address and can also mint to its own balance.

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

How it happened

  1. The constructor sets _owner = owner; _safeOwner = owner; and calls _mint(owner, initialSupply*(10**18)), so the owner holds the whole initial supply. No function changes _owner after construction.
  2. Every transfer and transferFrom runs _approveCheck, which is wrapped in the burnTokenCheck modifier. First branch: if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}. While _safeOwner still equals the owner, any transfer sent by the owner passes and _safeOwner becomes the recipient of that transfer.
  3. Privileged senders pass: if (sender == _owner || sender == _safeOwner || recipient == _owner) lets through the owner, the current _safeOwner, and anyone sending to the owner. Inside it, if (sender == _owner && sender == recipient){_sellAmount = amount;} lets the owner set _sellAmount by sending tokens to itself.
  4. For every other sender: a whitelisted sender (_whiteAddress[sender] == true) passes unconditionally. A blacklisted sender must satisfy require((sender == _safeOwner)||(recipient == _unirouter), ...), and since _safeOwner already passed in step 3, in practice the recipient must be _unirouter.
  5. An address that is on neither list takes the last branch. If amount < _sellAmount the transfer passes, and when recipient == _safeOwner the sender is also moved to the blacklist (_blackAddress[sender] = true; _whiteAddress[sender] = false;). Otherwise it needs recipient == _unirouter. _sellAmount starts at 0, so amount < _sellAmount is false until the owner sets it, and ordinary holders can only send to 0x7a250d56…F2488D.
  6. A sale that moves tokens into a pair with transferFrom(holder, pair, amount) therefore reverts for a non-whitelisted holder. Whether purchases work depends on the pair being _safeOwner, whitelisted, or the recipient being _unirouter; the source alone does not show which address received the owner's first transfer.
  7. The owner controls the lists: increaseAllowance(receivers) whitelists, addApprove(receivers) blacklists, decreaseAllowance(safeOwner) replaces _safeOwner, and multiTransfer whitelists the first approvecount recipients and approves the router for the maximum amount on their behalf. The function names suggest ordinary allowance helpers; the bodies only edit these lists.
  8. _mint is public and owner-only: it raises _totalSupply and credits _balances[_owner], so the owner can create more tokens, while the Transfer event names the account argument.
  9. What happened is known only from the listing: De.Fi's REKT database classifies the token as an Exit Scam/Honeypot and gives no loss figure. No transaction was opened showing the owner whitelisting, blacklisting, minting or removing liquidity.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain AstroDoge Loss not disclosed BNB Chain DRAGON INU Loss not disclosed BNB Chain LordShiba Loss not disclosed Ethereum Instadapp 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