RASIM OZAN Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

RASIM OZAN (ROK, 6 decimals) blocks transferFrom calls to one stored address, newun. The first transferFrom with a non-zero sender writes its recipient into newun: if(sender != address(0) && newun == address(0)) newun = recipient;. Afterwards require(recipient != newun || sender == owner(), "please wait"); reverts every transferFrom into that address unless the sender is the owner.

A router sale is a transferFrom into the pool, so if the pool was the captured recipient, holders cannot sell, while transfer has no such check and buys from the pool are not affected. The owner could also pause() all transfers that do not involve the owner, change newun with transfernewun, and mint new tokens without a cap. The on-chain owner() reads the zero address as of 2026-09-30.

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-11 and gives no loss figure.

How it happened

  1. The constructor credits _totalSupply = 10000000000000 * 10**9; (1e22 raw units, 1e16 tokens at 6 decimals) to _msgSender(), the deployer 0xAA4b91F2…8aCF56. newun starts as the zero address.
  2. transferFrom runs if(sender != address(0) && newun == address(0)) newun = recipient; for the first call with a non-zero sender. That call is not restricted and stores its recipient in newun. A router-based liquidity add calls transferFrom(provider, pool, amount), so the pool is a natural first recipient; the opened source does not show which address newun holds on-chain.
  3. Every later transferFrom runs require(recipient != newun || sender == owner(), "please wait");. A holder's router sale is transferFrom(holder, pool, amount), so with newun equal to the pool it reverts for any sender other than owner().
  4. transfer calls _transfer directly with no newun check, so a pool paying out a purchase and wallet-to-wallet sends pass.
  5. Owner powers in the source: transfernewun(address _newun) (onlyOwner) sets newun to any address (an unused address lifts the block, zero re-arms capture); pause() sets paused, after which _transfer requires !paused || sender == owner() || recipient == owner(), stopping buys and sells alike; mint(address _to, uint256 _amount) raises _totalSupply and _balances[_to] with no cap.
  6. Current ownership: owner() and getOwner() read the zero address in an eth_call on 2026-09-30. The source has both renounceOwnership() and lock(uint256 time), which each set _owner = address(0); lock keeps _previousOwner, which can unlock() after _lockTime. The read does not show which was used or when. With owner() at zero, sender == owner() is false for every real sender, so no address is exempt from the newun block.
  7. What the code allows: holders can buy, but while newun is the pool they cannot sell through a router, and the owner controls the block, a pause and minting for as long as it holds ownership. 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, any pause, mint, sale, liquidity removal or loss amount.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain AurataGoldCat Loss not disclosed BNB Chain OCTOPIX Loss not disclosed BNB Chain VOLCANOS Loss not disclosed Ethereum Croco Inu 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