Knight Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

Knight ($Knight) is a BNB Smart Chain token (0xc78df97c…140719, deployed 2021-06-19 by 0x0912E13B…94Ce7F in transaction 0x3280292c…240b19) with 8 decimals and a supply of 1000000000000000000 base units credited to the deployer. Its transferFrom stores the recipient of the first call it ever receives in a variable called newun, and from then on both transfer and transferFrom revert with please wait for any recipient equal to newun. If that first recipient is a liquidity pool, which the code does not itself establish, sales into the pool fail while transfers out of it to buyers do not.

Only the owner can repoint newun. De.Fi's REKT database lists the token as an exit scam / honeypot dated 2021-06-19, saying the owner could disable the transfer function and that this restricted users in selling; its proof links include a CryptoT3ddyBear write-up of the same code pattern in other tokens. No loss figure, attacker address or exploit transaction is established.

How it happened

  1. The constructor makes the deployer owner, sets symbol = "$Knight", name = "Knight", decimals = 8 and credits the whole supply to the owner: balances[owner] = _totalSupply;.
  2. transfer rejects any recipient equal to newun: require(to != newun, "please wait");. Before newun is set it holds address(0), so this only rejects transfers to the zero address.
  3. transferFrom captures the recipient on its first use: if(from != address(0) && newun == address(0)) newun = to;. Every later call takes the other branch, else require(to != newun, "please wait");. No sender, including the owner, is exempt.
  4. A token sale through a router pulls tokens with transferFrom, so if newun is the pool address (for example because the first transferFrom was the liquidity being added), the sale reverts with please wait. A purchase moves tokens out of the pool to the buyer, whose address is not newun, so the check does not block it. The check only looks at the recipient, so it does not by itself restrict transfers out of newun.
  5. The owner controls the block through function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing newun at an unused address lifts the block for the pool; setting it to address(0) re-arms capture, so the next transferFrom with a non-zero from stores its recipient again.
  6. clearCNDAO() is onlyOwner and sends the contract's BNB balance to the caller, and KnightTOKEN has a payable fallback (function() external payable {). Ownership can be handed over with transferOwnership and acceptOwnership; there is no function to renounce it.
  7. What happened is only what the listing states: De.Fi's REKT database records the token as an exit scam / honeypot dated 2021-06-19. The linked CryptoT3ddyBear post shows the same newun lines in other tokens, and its author says buyers could swap in but got a please wait error when swapping back. The Token Sniffer proof link could not be opened and no transaction was examined, so the code shows how sales could be blocked, not when or by whom transfernewun was used.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract $Knight

Evidence

Same attack technique

Browse all hacks →
BNB Chain PepeRise Loss not disclosed Ethereum VitaDAO.com $627K lost BNB Chain MoonRise Loss not disclosed BNB Chain MoonSquad 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