Flare Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

FLARE was a BEP-20 token on BNB Smart Chain that borrowed the name of the unrelated Flare Network project. Its _approve function only stores an allowance when the approving wallet is one hard-coded address, the deployer; for every other holder it writes an allowance of 0 while still emitting an Approval event. Because selling through a PancakeSwap-style router requires the router to pull tokens with transferFrom, ordinary holders could buy and hold FLARE but any router sell would revert.

De.Fi's REKT database lists FLARE as an exit scam/honeypot.

How it happened

  1. The constructor mints the full supply of 200,000,000,000,000 raw units (4 decimals) to the deployer: _balances[msg.sender] = _totalSupply;.
  2. _approve checks if (owner == address(0x6D156858dd42e77B40F4Afd0EA7896FBF2a7dEae)) and only then stores the requested amount. Any other wallet gets _allowances[owner][spender] = 0; followed by emit Approval(owner, spender, 3);, so the approval transaction succeeds but grants nothing.
  3. Buying works, because the pair sends tokens with a plain transfer, which has no restriction.
  4. Selling through a router calls transferFrom, which then runs _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"). With a stored allowance of 0, any non-zero sell reverts. Only the hard-coded deployer address can grant the router an allowance, so only that wallet can sell or add liquidity through it.
  5. The owner also holds an uncapped mint(uint256 amount) public onlyOwner function. renounceOwnership would remove that mint power, but it would not change the approval check, which compares against a fixed address rather than owner().

Protocol details

Classification Exchange (DEX)
Protocol Type Chain
Affected asset / contract FLARE
Protocol links Website @FlareNetworks

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.