SafeSolarStar Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists SafeSolarStar (SSS, BNB Chain, contract 0xd5626e28…6a88e6) as an exit scam/honeypot dated 2021-06-24, stating that the contract owner could disable the transfer function and so restrict users from selling. In the verified source the restriction sits in the internal _approve function: it stores a real allowance only when the token owner is one hard-coded address, and for every other address it stores 0 while emitting an Approval event with the value 0. A DEX sell needs the router to pull tokens with transferFrom, which subtracts from that allowance, so it reverts for any holder other than the hard-coded address.

Plain transfer calls are unaffected. The contract was deployed on 2021-06-13; no loss figure is listed.

How it happened

  1. The constructor mints the full supply to the deployer: _balances[msg.sender] = _totalSupply;, with _totalSupply = 1000000000000000000000000. The deployer is 0xD7bFD7d5…876664.
  2. approve, increaseAllowance and transferFrom all end in the internal _approve, which is rewritten around a different hard-coded address, 0xaD628C37…028ef0: if (owner == address(0xaD628C37aa60d11628E9dd5B4b7B7Ce5f8028ef0)) { _allowances[owner][spender] = amount; ... } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 0); }. That address is not the deployer, and the source does not show how it would receive tokens.
  3. Any other holder who approves a DEX router ends up with an allowance of 0, although an Approval event is still logged.
  4. To sell, the router calls transferFrom(holder, pool, amount), which runs _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"). Subtracting a positive amount from 0 reverts the whole call, including the balance change made by _transfer.
  5. transfer(recipient, amount) calls _transfer directly and needs no allowance, so tokens can still be sent out of a pool to buyers; the block applies to approval-based sells.
  6. The hard-coded exception does not depend on ownership. A current eth_call read (2026-09-30) returns the zero address for owner(), so the owner-only mint and ownership functions are no longer callable; the read does not show when or by whom ownership was renounced, and renouncing would not lift the _approve restriction.
  7. What happened, per the listing: De.Fi's REKT database lists the token as an exit scam/honeypot where the owner could disable transfers so users could not sell. No transaction was opened, so the affected holders and any amount lost are not established.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum Scaleswap Loss not disclosed Ethereum lightningshib.com Loss not disclosed BNB Chain EverTiki Loss not disclosed Ethereum Efinity Token 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