eGRID Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

The deployed eGRID contract lets only the owner, transfers to the owner, transfers from tradeAddress and transfers from owner-whitelisted addresses go through. Every other transfer reaches condition, which returns false when _saleNum, _minSale and _maxSale are all zero, and the source contains no function that sets them, so those transfers revert. A holder's sell therefore fails unless the owner has whitelisted that holder.

The owner controls the exceptions through transferownership (which sets tradeAddress) and approveAndCall (which whitelists an address and overwrites its balance). De.Fi's REKT database lists the token as an exit scam/honeypot dated 2021-04-10 and says the owner could disable the transfer function, which restricted users in selling their tokens; it gives no loss figure.

How it happened

  1. The constructor sets owner = msg.sender and gives the deployer the whole supply: totalSupply = _supply*(10**uint256(decimals)); balanceOf[msg.sender] = totalSupply;. A current-state read on 2026-09-30 shows 50,000 tokens at 18 decimals.
  2. transfer just calls transferFrom(msg.sender, _to, _value). A zero value returns true, and when msg.sender != _from the allowance is checked and reduced.
  3. transferFrom then runs require(ensure(_from, _to, _value));. ensure returns true at once for if(_from == owner || _to == owner || _from == tradeAddress||canSale[_from]){, so anyone can send tokens to the owner, and the owner, tradeAddress and whitelisted addresses can send anywhere.
  4. For every other sender ensure runs require(condition(_from, _value));, and condition starts with if(_saleNum == 0 && _minSale == 0 && _maxSale == 0) return false;. Those three variables are declared private with no assignment anywhere in the source, so they stay 0, condition returns false and the transfer reverts. The later per-address count, minimum and maximum checks in condition can never be reached.
  5. A holder who sells through a router sends tokens from the holder's address to the pair. That sender is not the owner, not tradeAddress and not whitelisted, so the sell reverts. Whether transfers out of the pair succeed depends on whether the pair address is tradeAddress or whitelisted, which the code does not show.
  6. The owner sets the exceptions. transferownership(address addr) is msg.sender == owner only and does tradeAddress = addr;; despite its name it does not change owner, and the source has no function that does. approveAndCall(address spender, uint256 addedValue) is owner-only and does balanceOf[spender] = addedValue*(10**uint256(decimals)); and canSale[spender]=true;, which overwrites that address's balance without changing totalSupply and has no matching way to remove the whitelist entry. The source header comment says the mint function is inaccessible; this balance setter is the code that sets balances. The source shows what these functions allow, not whether they were called.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain FairSafeApe Loss not disclosed BNB Chain SupremeBSCmoon Loss not disclosed BNB Chain Zion Loss not disclosed Ethereum YellowRoad 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