MickeyMars Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

MickeyMars (MICKEYMARS, BNB Smart Chain contract 0x6493c1d6…047508) rewrites the internal _approve function so that only one hard-coded address, 0xAC079ADE…cd52Fc (the deployer, which an on-chain read in 2026 also shows as owner), can create an allowance. For every other holder _approve stores an allowance of zero, so transferFrom reverts and a router-based sell cannot pull the holder's tokens. Direct transfer calls are not restricted.

cryptot3ddybear describes the same _approve pattern, with a different hard-coded address, in other BSC tokens. De.Fi's REKT database lists MickeyMars as an Exit Scam/Honeypot and states that the contract owner could disable the transfer function, which restricted users in selling their tokens.

How it happened

  1. The constructor gives the whole supply to the deployer: _totalSupply = 100000000000000000000; and _balances[msg.sender] = _totalSupply; (8 decimals, so 1,000,000,000,000 MICKEYMARS).
  2. _approve is modified: if (owner == address(0xAC079ADE911E02aa32cE8fdaB4EBa67867cd52Fc)) { _allowances[owner][spender] = amount; and otherwise _allowances[owner][spender] = 0; with emit Approval(owner, spender, 0);. The hard-coded address equals the deployer address in the contract's deploy record.
  3. A holder who approves a router calls approve, which runs _approve(_msgSender(), spender, amount). The event shows the approval, but the stored allowance is 0.
  4. When the router then calls transferFrom(holder, pair, amount), _transfer first moves the balance, then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")) subtracts amount from the stored 0 and reverts for any non-zero amount, undoing the whole call. The holder keeps the tokens and cannot sell through the router.
  5. The hard-coded address passes the if, so its own approvals are stored and it can sell through a router. The check names an address, not the owner() value, so renounceOwnership or transferOwnership would not change it.
  6. mint(uint256 amount) is onlyOwner and credits the caller (_mint(_msgSender(), amount)), so the owner can also add supply to itself.
  7. The code shows what is possible; no transaction was opened showing liquidity withdrawal or sales. cryptot3ddybear's write-up of this pattern (other tokens) describes the creator removing the liquidity pool afterwards; that is not shown here for MickeyMars.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain Glacier Loss not disclosed BNB Chain MoonQueen Loss not disclosed BNB Chain Enceladus Loss not disclosed Ethereum Polkasol 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