Kimchi Inu Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

Kimchi Inu (KIMU) is an ERC-20 token deployed on Ethereum on 21 May 2021 at 0xf1ff017f…94119a. Its transfer logic runs through a modifier named burnTokenCheck that, by default, reverts any transfer by an ordinary holder unless it goes to the Uniswap router address or comes from the owner's chosen _safeOwner address, and the revert reuses the standard message "ERC20: transfer amount exceeds balance" so a blocked sale looks like a balance error. The owner can whitelist chosen wallets, blacklist others, set a small amount below which a first sale is allowed (after which the seller is blacklisted), and mint new tokens, all through functions with misleading ERC-20 names such as increaseAllowance, decreaseAllowance and addApprove.

De.Fi's REKT database lists KIMU as an exit scam/honeypot on 22 May 2021, saying the owner could disable transfers so holders could not sell.

How it happened

  1. The constructor sets _owner and _safeOwner to the owner argument and calls the public _mint five times, 25,000,000,000,000 KIMU in total. _mint credits _balances[_owner] but emits Transfer events naming other addresses as recipients, so explorers show tokens going to wallets that never received a balance.
  2. The first outgoing transfer from _owner sets _safeOwner = recipient. If that transfer seeds the Uniswap pool, the pool becomes _safeOwner, and transfers out of it (buys) pass the sender == _safeOwner check. The owner can also point _safeOwner at any address with decreaseAllowance.
  3. For any other sender, burnTokenCheck allows the transfer only if the sender is on _whiteAddress. Otherwise it requires sender == _safeOwner or recipient == _unirouter. A sale sends tokens to the pool, not to the router, so it reverts with a fake "transfer amount exceeds balance" error.
  4. The owner can open a narrow exit with a self-transfer, which sets _sellAmount. A non-listed holder may then move less than _sellAmount once; if that transfer goes to _safeOwner, the holder is added to _blackAddress and every later sale reverts.
  5. The owner controls both lists: multiTransfer and increaseAllowance add wallets to _whiteAddress, and addApprove moves wallets to _blackAddress. _mint stays callable by _owner after deployment, and no function transfers or renounces _owner.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum Mommy Milkers Loss not disclosed BNB Chain BraveHeart TOKEN Loss not disclosed BNB Chain Kobe Loss not disclosed BNB Chain ORANGE TOKEN 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