NFT.Music Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists NFT.Music (NFT.MUSIC, BNB Smart Chain contract 0x7ae79c56…21b68b) as an exit scam/honeypot, noting that the contract owner could disable the transfer function, which restricted users in selling their tokens. In the verified source the restriction sits in _approve: for every account except one hard-coded address, which is the deployer 0xb991E6EA…1563d0, it stores an allowance of 0 and emits an Approval event showing 2. A DEX router cannot pull a holder's tokens through transferFrom without an allowance, so a router-based sell reverts, while buying from a liquidity pool does not need a holder approval.

The check is keyed to that fixed address rather than to ownership, so renouncing ownership does not lift it. De.Fi gives no loss figure, and the code alone does not show how many holders were affected.

How it happened

  1. The constructor sets the name and symbol and gives the whole supply to the deployer: _balances[msg.sender] = _totalSupply;. The deployer address equals the address hard-coded in step 3.
  2. Every allowance write goes through _approve. approve and increaseAllowance call it with _msgSender() as the token owner, and transferFrom calls it again to reduce the allowance after a transfer.
  3. _approve treats one address differently: if (owner == address(0xb991E6EAe36a388C34fCd48a8eB7b567C71563d0)) { _allowances[owner][spender] = amount; ...} else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 2); }. For any other holder the stored allowance stays 0, while the emitted event reports a value of 2.
  4. transferFrom computes _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"). A router that sells for a holder is the caller, and that holder's allowance to it is 0, so every non-zero sell reverts.
  5. Plain transfer has no such check and _transfer only moves balances, so tokens can still be bought from a pool and sent between wallets; only approval-based spending is blocked for holders. The deployer's own approvals are stored normally, so the deployer is the only account that can give a router a working allowance.
  6. The header comment advertises renounced ownership, burned liquidity and a 5% fee, but _transfer applies no fee and the contract has no liquidity logic. The owner-only mint(uint256 amount) mints to the caller. A read of owner() on 2026-09-30 returned the zero address, which does not show when ownership was renounced.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract NFT.MUSIC

Evidence

Same attack technique

Browse all hacks →
Ethereum Universe of Inu Loss not disclosed Ethereum Houbi Arena Loss not disclosed BNB Chain HODLEPUFF Loss not disclosed Ethereum Wrapped AMC 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