King Of The North Coin Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

King Of The North Coin (KOTN) has a rewritten private _approve that stores a real allowance only when the owner argument is the hardcoded address 0x5399d609…8D9006 (the deployer address) and stores 0 for every other address. A DEX router sells by calling transferFrom, which subtracts the amount from that zero allowance and reverts, so ordinary holders cannot sell through a router even though their approve call succeeds. The owner also holds uncapped fee setters and setMaxTxPercent, which can set the per-transfer limit to zero.

De.Fi's REKT database lists the token as an Exit Scam/Honeypot with no loss figure and says the owner could restrict selling.

How it happened

  1. The constructor credits the full supply to the deployer and creates the token's liquidity pair through the hardcoded router at 0x10ED43C7…56024E. _tTotal = 1000000000000000 * 10**9 with _decimals = 9, so 1,000,000,000,000,000 tokens; the deployer is 0x5399d609…8D9006.
  2. _approve is changed to: if (owner == address(0x5399d609E723607948dFF3A9032F191aaC8D9006)) { _allowances[owner][spender] = amount; for that address, and _allowances[owner][spender] = 0; emit Approval(owner, spender, 0); for everyone else. approve calls it, so a holder's approval of the router stores nothing.
  3. A sell through a router calls transferFrom(holder, pool, amount). After _transfer the function runs _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance")). The allowance is 0 and _transfer requires amount > 0, so sub reverts and the sell is undone. Plain transfer does not touch allowances, so wallet-to-wallet moves and tokens leaving the pool to a buyer are not blocked by this rule.
  4. The restriction is tied to the hardcoded address, not to the Ownable owner: renounceOwnership exists but does not change _approve. The owner can also call setMaxTxPercent(0), which sets _maxTxAmount = _tTotal.mul(maxTxPercent).div(10**2) to 0, so require(amount <= _maxTxAmount, ...) fails for every transfer where neither side is the owner, and setTaxFeePercent / setLiquidityFeePercent accept any value (a combined fee above 100 makes transfers revert through SafeMath sub).
  5. The contract's own liquidity routine hits the same rule: swapTokensForEth calls _approve(address(this), address(uniswapV2Router), tokenAmount), which stores 0, so the router's pull from the contract reverts. _transfer calls swapAndLiquify when the contract's token balance reaches numTokensSellToAddToLiquidity (250000000000 * 10**9), swapAndLiquifyEnabled is true and from != uniswapV2Pair, so once fees accumulate to that level, transfers not sent from the pool revert as well.
  6. What happened: De.Fi's REKT database lists the token as an Exit Scam/Honeypot dated 2021-07-02. No transaction showing a reverted sell, a setMaxTxPercent or fee-setter call, or any liquidity removal was opened, so the code shows what the owner can do, not what was done.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain MoonPilot Loss not disclosed BNB Chain BabyElonDoo Loss not disclosed BNB Chain Baby Doge Moon Loss not disclosed BNB Chain Cresco 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