Volcano Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

Volcano (VOL) is a BEP-20 token on BNB Chain whose _approve function stores the requested allowance only for one hard-coded address, 0xCf038932…2fE820, which is also the deployer and current owner. For every other holder, approving the PancakeSwap router records an allowance of zero. A sell through the router uses transferFrom, which subtracts the amount from that zero allowance and reverts, so ordinary holders cannot sell through the router while the hard-coded address can.

Because the check compares against a fixed address rather than owner(), giving up ownership would not remove this exemption. The owner can also mint unlimited new VOL with mint. De.Fi's REKT database lists Volcano as a honeypot, and an April 2021 write-up describes the same _approve pattern in other BNB Chain tokens.

How it happened

  1. The deployer receives the full initial supply of 666,000,000,000 VOL (3 decimals) and is the only address _approve treats normally.
  2. Buyers purchase VOL from the PancakeSwap pair. The pair sends tokens with transfer, which has no restriction, so buys succeed.
  3. To sell, a holder approves the router. _approve sees that the holder is not the hard-coded address, sets the allowance to 0 and emits an Approval event for 0.
  4. The router then calls transferFrom. The balance moves in _transfer, but the following _allowances[sender][_msgSender()].sub(amount, ...) underflows the zero allowance and reverts the whole sell with "BEP20: transfer amount exceeds allowance".
  5. The hard-coded address keeps real allowances, so it can sell through the router, and it can call mint to create more VOL at any time.

Protocol details

Classification Token
Protocol Type Farm
Affected asset / contract VOL
Protocol links Website @volcano_big

Build your security review skills

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