AstroCum Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

AstroCum (ASCUM, 3 decimals) blocks transfers to one stored address, newun. The first transferFrom call with a non-zero from writes its recipient into newun: if(from != address(0) && newun == address(0)) newun = to;. After that, every transferFrom and transfer whose recipient equals newun reverts with please wait.

A router-based liquidity add or sale calls transferFrom with the pool as recipient, so if the pool is the first recipient captured, selling into it is blocked, while buying (the pool paying out with transfer to a different address) is not. The owner can change newun through transfernewun: setting it to an unused address lifts the block, and setting it to zero makes the next transferFrom capture a new recipient. De.Fi's REKT database lists the token as an Exit Scam/Honeypot and describes it as: the contract owner could disable the transfer function, which restricted users in selling their tokens.

The listing dates the incident 2021-06-13 and gives no loss figure. A write-up by cryptot3ddybear describes this same function pattern in other BSC tokens (SafeRocket, SafeBinance).

How it happened

  1. The constructor sets symbol = "ASCUM", name = "AstroCum", decimals = 3 and _totalSupply = 5000 * 10**6 * 10**3 (5e12 raw units, 5 billion tokens) and credits it with balances[owner] = _totalSupply;, where owner is the deployer, 0xFd520a1b…413605. newun starts as the zero address.
  2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; for the first call that has a non-zero from. That call is not restricted and stores its recipient in newun. A router-based liquidity add calls transferFrom(provider, pool, amount), so the pool address is a natural first recipient; the opened source does not show which address newun holds on-chain.
  3. On every later transferFrom, the else branch runs require(to != newun, "please wait");. A sale through a router is transferFrom(holder, pool, amount), so with newun equal to the pool it reverts for every sender, the owner included. transfer has the same guard: require(to != newun, "please wait");.
  4. A pool paying out a purchase sends tokens to the buyer, whose address differs from newun, so buys and wallet-to-wallet sends pass.
  5. The owner can call transfernewun(address _newun) (onlyOwner) at any time. Pointing newun at an address nothing uses lifts the block; setting it to zero re-arms capture, and the next transferFrom stores a new recipient. The reading of owner on 2026-09-30 is still the deployer, and the source has no renounceOwnership; ownership moves only through the two-step transferOwnership and acceptOwnership.
  6. What the code allows: holders can buy but, while newun is the pool, cannot sell through a router, and the owner controls when that changes. What is documented as having happened: De.Fi's REKT database lists the token as an Exit Scam/Honeypot; no opened transaction shows what newun was set to, any sale, liquidity removal or loss amount.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain EASYFEEDBACK Loss not disclosed BNB Chain CocoBee Loss not disclosed BNB Chain MIAU Loss not disclosed BNB Chain AurataGoldCat 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