Alaskan Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists Alaskan (ALASKA) on BNB Smart Chain as an Exit Scam/Honeypot, stating that the contract owner could disable the transfer function and so restrict users from selling. The verified source (a contract named KingAkita) shows a mechanism that can do this: every transfer passes through a burnTokenCheck modifier. A holder on neither the owner's whitelist nor its blacklist can send tokens to the hard-coded _unirouter address or to the owner, and, once the owner has set _sellAmount above 0, to any recipient for amounts below it.

A blacklisted holder gets no amount-based pass and can send only to _unirouter or the owner. Other transfers revert with "ERC20: transfer amount exceeds balance" even though the holder's balance is not the cause. The source does not state what _unirouter is.

No loss figure is listed.

How it happened

  1. The owner address _owner is set once in the constructor and the source has no function that changes it. transfer and transferFrom both call _approveCheck, which carries the burnTokenCheck modifier.
  2. The first transfer sent by the owner while _owner == _safeOwner passes and runs _safeOwner = recipient. After that, transfers pass when the sender is _owner or _safeOwner, or when the recipient is _owner.
  3. For other senders, a whitelisted sender (_whiteAddress[sender] == true) passes. A blacklisted sender must satisfy require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). A sender on neither list passes when amount < _sellAmount; otherwise the same require applies. _unirouter is the hard-coded address 0x05fF2B0D…608C7F. A transfer into a liquidity pool address is covered by neither exemption, so it reverts with a message that blames the balance, unless the sender is on neither list and amount < _sellAmount, or is whitelisted.
  4. _sellAmount starts at 0, so the amount < _sellAmount branch is never true until the owner sets it. The owner can set it with a transfer to itself (if (sender == _owner && sender == recipient){_sellAmount = amount;}), but only once _safeOwner is no longer the owner; while _owner == _safeOwner, a self-transfer takes the first branch and does not reach that line. Once _sellAmount is set, a holder on neither list can send amounts below it to any recipient, and if the recipient is _safeOwner the sender is flagged: _blackAddress[sender] = true; _whiteAddress[sender] = false;. A blacklisted holder can then send to _unirouter, to _owner, or as _safeOwner.
  5. The owner alone controls the lists and the exemption target: increaseAllowance whitelists, addApprove blacklists, decreaseAllowance(address safeOwner) replaces _safeOwner, and multiTransfer can whitelist receivers and set their allowance to _unirouter to the maximum.
  6. The owner can also mint: _mint is public, requires msg.sender == _owner, and adds the amount to _balances[_owner]. The code shows this power; no transaction was opened showing it used.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain KumaInu Loss not disclosed BNB Chain GDOGE Loss not disclosed BNB Chain GOATMOON Loss not disclosed BNB Chain Dasani 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