ghostshiba.xyz Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

ghostshiba.xyz (GHOST SHIBA) is an Ethereum token whose compiled code stores an address in a public variable called newun. The first transferFrom call with a non-zero from while newun is empty sets newun = to, and after that every transfer or transferFrom whose recipient is newun reverts with "please wait". When newun is a liquidity pair, that stops holders from sending tokens into it, which is how a sale on a DEX is executed.

The source header says "Renounced Ownership & 100% LP Burnt -> NO RUGPULLS", but that is a comment, and the compiled code contains no renounce function and still has onlyOwner control over newun. De.Fi's REKT database lists the token as an Exit Scam/Honeypot, describing a contract whose owner could disable the transfer function, which restricted users in selling their tokens.

How it happened

  1. The compiled TokenBEP20 constructor sets symbol = " GHOST SHIBA ", name = "ghostshiba.xyz", decimals = 8 and gives the whole supply to owner. A public variable address public newun; starts empty. The header comment lists burn, liquidity and marketing fees and says ownership is renounced and the LP burnt; none of the fee code is compiled, because the swapAndLiquify block sits inside a comment.
  2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first call with a non-zero from therefore records its recipient in newun without any check. If that call is the router moving tokens into a new liquidity pair, the pair address is the one captured.
  3. From then on, transferFrom takes the else branch and require(to != newun, "please wait") reverts any transfer whose recipient is newun. transfer has the same guard unconditionally: require(to != newun, "please wait");.
  4. A holder selling through a router calls transferFrom(holder, pair, amount). With newun set to the pair, to == newun and the call reverts. The check is on the recipient only, so a transfer from newun to another address, which is what a purchase from the pair is, is not blocked by it.
  5. The owner can change the guard. transfernewun(address _newun) is onlyOwner and overwrites newun. Pointing it at an address nobody uses lifts the block, while setting it to address(0) re-arms capture, so the next transferFrom call with a non-zero from records its recipient as the new blocked address.
  6. The Owned contract has only transferOwnership and acceptOwnership, and no function that renounces ownership. GHOSTSHIBA also exposes clearCNDAO(), restricted by onlyOwner, which sends the contract's own ETH balance to the owner. The owner() value read on 2026-09-30 was 0x607487fb…67e2ba, the same address that deployed the contract; this is a current-state read, not a historical one.
  7. This describes what the code allows. The supplied source does not show which address newun held, whether it was ever changed, or whether any liquidity was removed on this deployment.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract GHOST SHIBA

Evidence

Same attack technique

Browse all hacks →
BNB Chain VOLCANOS Loss not disclosed Ethereum Croco Inu Loss not disclosed BNB Chain FLOUR FINANCIAL Loss not disclosed Ethereum DeFi Wonderland 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