saferipple Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

saferipple is a BEP-20 token on BNB Smart Chain whose transfer and transferFrom both revert when the recipient equals a stored address called newun. The contract fills newun itself on the first transferFrom call and the owner can reassign it with transfernewun. If newun ends up holding a liquidity pair address, a router-based sell, which calls transferFrom with the pair as recipient, reverts with "please wait".

De.Fi's REKT database lists saferipple as an Exit Scam/Honeypot in which the owner could restrict holders from selling. The code implements this as a recipient block on one address rather than a switch that disables all transfers. A third-party write-up of this code pattern describes newun being set to the pool address when liquidity is first added; it names other tokens, not saferipple.

How it happened

  1. The constructor mints the whole supply to the deployer (balances[owner] = _totalSupply;, 1000000000000000000000000000 raw units at 18 decimals). newun is never set in the constructor, so it starts as the zero address.
  2. The first transferFrom call with a non-zero from while newun is unset runs if(from != address(0) && newun == address(0)) newun = to;. That call is not checked and completes normally, and newun now holds that call's recipient. A liquidity add that pulls tokens into a pair through transferFrom would record the pair, as the third-party write-up describes. The code itself does not name the pair.
  3. After that, transferFrom runs else require(to != newun, "please wait"); and transfer runs require(to != newun, "please wait");. A holder's sell through a router calls transferFrom with the pair as recipient, so it reverts whenever newun is the pair. A buy moves tokens out of the pair to the buyer through transfer, which passes unless the buyer is newun.
  4. The owner can change the target with transfernewun(address _newun). Pointing it at an unused address lifts the block; setting it to the zero address lets the next transferFrom capture its recipient again. The code has no function to renounce ownership; transferOwnership followed by acceptOwnership hands it to another address.
  5. What actually happened is not established by the code. The record's listing says the token was a honeypot. No transaction showing newun holding the pair, a failed sell, or a liquidity withdrawal was opened.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum GamyFi Loss not disclosed BNB Chain Luxury Finance Loss not disclosed BNB Chain VanillaUnicorn Loss not disclosed BNB Chain ElonGain 1000X 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