SAFE CHARIZARD Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

SAFE CHARIZARD (CHARIZARD) is a BEP20 token on BNB Smart Chain whose _approve function stores a real allowance only for one hard-coded address and writes 0 for everyone else. A DEX sell has to pull tokens with transferFrom, and that call needs a non-zero allowance, so for ordinary holders it reverts while the hard-coded address can approve normally. De.Fi's REKT database lists the token as an exit scam/honeypot dated 2021-04-11 and says the contract owner could disable the transfer function, which restricted users in selling their tokens.

The verified code does not contain a transfer switch; the restriction comes from the allowance logic described here.

How it happened

  1. The constructor mints the whole supply to the deployer: _balances[msg.sender] = _totalSupply; with _totalSupply = 447800000000000 and 11 decimals.
  2. Every allowance write goes through _approve (approve, increaseAllowance, decreaseAllowance and transferFrom all call it). It branches on a hard-coded address: if (owner == address(0x583cE930fC4cB32D00B39B4B1Baa823A462c4cE1)) { _allowances[owner][spender] = amount; and otherwise _allowances[owner][spender] = 0; while emitting Approval(owner, spender, 0). That address is the deployer in the deployment record and the owner() value read on 2026-09-30.
  3. When a holder calls approve(router, amount), the stored allowance is 0 even though the event is emitted. A router that then calls transferFrom(holder, pair, amount) runs _transfer and finishes with _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"). With a stored allowance of 0 and a non-zero amount this reverts and rolls back the whole call, so an approval-based sell fails for every holder except the hard-coded address.
  4. transfer has no such check (_transfer(_msgSender(), recipient, amount)), so plain wallet-to-wallet transfers and pool-to-buyer transfers are not blocked by the code. The hard-coded address can approve and sell normally.
  5. renounceOwnership() only clears _owner. The allowance exemption compares against the literal address and never reads _owner, so renouncing ownership would not remove it.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain CaptainJackFans Loss not disclosed BNB Chain Bongo Cat Loss not disclosed BNB Chain HYPERIONMOON Loss not disclosed BNB Chain Glacier 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