Koshka Miu Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

Koshka Miu (Koshka) is a BNB Chain token deployed on 28 May 2021 at 0x885085a7…e0c929 by 0x5FC0DdB3…600DA7. Its transferFrom saves the recipient of the first transferFrom call as newun; if liquidity is added through the PancakeSwap router, that recipient is the pair. After that, every transfer or transferFrom into newun reverts with "please wait", so buys out of the pair work but no holder can sell into it.

Only the owner can change newun, through transfernewun. Removing liquidity sends tokens out of the pair, not into it, so whoever added liquidity and holds the LP tokens could still withdraw it. The contract has no renounceOwnership.

De.Fi's REKT database lists the token as an exit scam/honeypot.

How it happened

  1. The constructor mints the whole supply, 1,000,000,000,000 tokens at 9 decimals, to the owner.
  2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to;. The router's addLiquidityETH moves tokens into the pair with transferFrom, so a first liquidity add would set newun to the pair.
  3. From then on transferFrom runs require(to != newun, "please wait"), and transfer runs the same check. A router sale sends the seller's tokens into the pair, so it reverts; buys send tokens out of the pair and pass.
  4. transfernewun(address _newun) is onlyOwner, so only the owner can point newun elsewhere and reopen sales.
  5. Whoever added liquidity holds the LP tokens and could remove liquidity at any time, because the pair paying out tokens is a transfer from newun, not to it. The blog post De.Fi cites describes this template's exit as pulling liquidity after one-way buying.

Protocol details

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

Build your security review skills

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