What happened
LOVELY SHIBA (LSHIBA) is a BNB Smart Chain token (0xdca9507e…a44296, deployed 2021-06-11 in transaction 0xe26ca7f9…eadc33) whose _approve function only stores a real allowance when the token owner is one hard-coded address, 0xa4f6c912…735211, which is also the deployer. For every other holder the allowance is written as 0 while the Approval event shows 2, so any transferFrom of a holder's tokens (the call a router makes when selling) reverts on the allowance check, while direct transfer calls still work. The file's header comment advertises renounced ownership, LP burned at 100 holders and a 5% liquidity fee; none of those fee or burn mechanics exist in the code, and renouncing ownership would not touch the _approve restriction.
De.Fi's REKT database lists the token as an exit scam / honeypot dated 2021-06-18, saying the owner could disable the transfer function and that this restricted users in selling. No loss figure, attacker address or exploit transaction is established.
How it happened
- The constructor credits the whole supply to the deployer:
_balances[msg.sender] = _totalSupply;. The deployer is 0xa4f6c912…735211. - All approvals go through one internal function, which special-cases that address:
if (owner == address(0xa4f6c9122dCA05421160136b7db2082b14735211)) { _allowances[owner][spender] = amount; emit Approval(owner, spender, amount); } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 2); }.approveandincreaseAllowanceboth call it, so a normal holder's approval to a router is stored as 0 although the event shows 2. transferFromfinishes with_approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"));. For a holder other than the hard-coded address the stored allowance is 0, sosubreverts for any amount above zero and the whole transfer is undone. A router-based sale of such a holder's tokens therefore fails.transferis_transfer(_msgSender(), recipient, amount)with no allowance check, so tokens sent directly, including a pool sending tokens out to a buyer, are not affected by step 3. The hard-coded address's own approvals are stored normally, so it can usetransferFrom.- The restriction is keyed to a fixed address, not to the owner role.
renounceOwnershipandonlyOwnerexist, and an eth_call read ofowner()on 2026-09-30 returned the zero address, but that read is current state and does not show when ownership was renounced. Renouncing would not lift the_approverestriction. While an owner exists,mint(uint256 amount)isonlyOwnerand can add supply. - What happened is only what the listing states: De.Fi's REKT database records the token as an exit scam / honeypot dated 2021-06-18. The linked CryptoT3ddyBear post shows the same address-gated
_approvein other tokens and says buyers could swap in but not back; the Token Sniffer proof link could not be opened. No transaction was examined, so the code shows how sells could be blocked, not who held the liquidity tokens or when any liquidity was removed.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
