PiggyBank Community Token Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

De.Fi's REKT database lists PiggyBank Community Token (PIGGY) on Ethereum as an exit scam / honeypot, noting that the owner could disable the transfer function and so restrict users from selling their tokens. The verified source shows a narrower control than a general transfer switch: the contract stores an address called newun and reverts any transfer whose recipient is that address with the message "please wait". The first transferFrom call from a non-zero sender while newun is unset records its recipient as newun, which for a token traded through a DEX pair is the address that receives tokens on a sell.

The owner alone can change newun with transfernewun. Whether and when this block was active for PIGGY holders is not shown by the code alone.

How it happened

  1. The constructor mints the whole supply to the deployer: _totalSupply = 100000000000000000000; balances[owner] = _totalSupply;. With decimals = 8 that is 1,000,000,000,000 tokens, matching the header comment.
  2. The contract declares address public newun;, which starts as the zero address. Nothing in the constructor sets it.
  3. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom from a non-zero sender therefore stores its recipient as newun. Router-based liquidity adds and swaps move tokens with transferFrom, so a liquidity deposit made this way would make the pool address the newun. This is what the code permits; the source does not show which address was captured.
  4. Once newun is set, both transfer paths refuse it as a destination. transfer starts with require(to != newun, "please wait"); and every later transferFrom hits the else require(to != newun, "please wait"); branch. A holder's sell, which sends tokens to the pool, reverts. There is no exception for the owner or any other address in these functions.
  5. Buys are not blocked by this check: tokens leaving the pool go to the buyer, who is not newun, so the require passes.
  6. The owner controls the switch: function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing newun at an address nobody uses lifts the block; setting it back to the zero address lets the next transferFrom capture a new recipient. No transaction showing the owner calling transfernewun was opened.
  7. The header comment advertises a 5% liquidity fee, 3% holder reward, 2% burn and a "Token Limitation for trade" of 500,000,000,000, but the contract contains no fee, reward, burn or trade-limit code, and transfer and transferFrom move the full tokens amount. Ownership has transferOwnership and acceptOwnership but no renounce function. clearCNDAO lets the owner send any ETH held by the token contract to themselves.

Protocol details

Classification Stablecoin
Protocol Type Exit Scam/Honeypot
Affected asset / contract PIGGY

Evidence

Same attack technique

Browse all hacks →
BNB Chain MentalHealth Loss not disclosed BNB Chain ElonSperm Loss not disclosed BNB Chain TeamRocket Loss not disclosed BNB Chain HOGtoken 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