EverTiki Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists EverTiki (EVERTIKI, BNB Chain, contract 0x99718428…319046) as an exit scam/honeypot dated 2021-06-24, stating that the contract owner could disable the transfer function and so restrict users from selling. In the verified source the restriction sits in the internal _approve function: it stores a real allowance only when the token owner is one hard-coded address, and for every other address it stores 0 while emitting an Approval event with the value 4. A DEX sell needs the router to pull tokens with transferFrom, which subtracts from that allowance, so it reverts for any holder other than the hard-coded address.

Plain transfer calls are unaffected, so tokens can still move out of a pool to buyers. The contract was deployed on 2021-06-19; no loss figure is listed.

How it happened

  1. The constructor mints the full supply to the deployer: _balances[msg.sender] = _totalSupply;. The deployer, 0xB35e064b…567F50, is also the address hard-coded inside _approve, and the current on-chain owner reads as the same address.
  2. approve, increaseAllowance and transferFrom all end in the internal _approve, which is rewritten: if (owner == address(0xB35e064b12E3B301bF57f5675335d66B62567F50)) { _allowances[owner][spender] = amount; ... } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 4); }.
  3. A holder who approves a DEX router therefore ends up with an allowance of 0 while the logged Approval event shows 4, so wallets and explorers that read events do not show the real allowance.
  4. To sell, the router calls transferFrom(holder, pool, amount). That function runs _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"), and subtracting a positive amount from an allowance of 0 reverts the whole call, including the balance change made by _transfer.
  5. transfer(recipient, amount) calls _transfer directly with no allowance, so a pool can still send tokens to a buyer. The code lets buys work while sells through an approval-based router fail for everyone except the hard-coded address.
  6. The hard-coded exception is separate from ownership, so renounceOwnership() would not remove it. The owner can also create supply with mint(uint256 amount) public onlyOwner; the source does not show whether it was used.
  7. What happened, per the listing: De.Fi's REKT database lists the token as an exit scam/honeypot where the owner could disable transfers so users could not sell. No transaction was opened, so the number of affected holders and any amount lost are not established.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum lightningshib.com Loss not disclosed BNB Chain SafeSolarStar Loss not disclosed Ethereum Efinity Token Loss not disclosed Ethereum Baby Doge Coin 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