rock solid Vaults Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists rock solid Vaults (RSV, BNB Smart Chain, contract 0xe9a063e3…e3c983) as an exit scam/honeypot, stating that the contract owner could disable the transfer function, which restricted users in selling their tokens. In the verified source, every transfer and transferFrom runs through a burnTokenCheck modifier. For an ordinary holder who the owner has not whitelisted, a transfer to any address other than the hard-coded _unirouter (0x9B087bC3…6F4403) or the owner reverts with a message that reads like a balance error.

The owner can also whitelist or blacklist holders, change the exempt _safeOwner address, and mint new supply to itself. The code shows what the owner can do; this draft cites no transaction showing which of these powers were used.

How it happened

  1. The constructor stores the owner argument as both _owner and _safeOwner and calls _mint(_owner, initialSupply*(10**18)). _mint requires msg.sender == _owner, so the deployment can only succeed if owner is the deployer, 0x444ff12F…cf9400. No function in the contract reassigns _owner.
  2. transfer and transferFrom both call _approveCheck(sender, recipient, amount), which is declared with the burnTokenCheck(sender,recipient,amount) modifier. The balance is only debited inside the modifier body, so a revert leaves the holder's balance untouched.
  3. Privileged paths pass. While _owner == _safeOwner, any transfer sent by the owner passes and resets _safeOwner to the recipient (if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}). After that, if (sender == _owner || sender == _safeOwner || recipient == _owner) lets the owner, the _safeOwner address, and anyone sending to the owner through. An owner-to-owner transfer in that branch sets _sellAmount = amount.
  4. Whitelisted senders pass unconditionally (if (_whiteAddress[sender] == true){ _; }).
  5. Every other holder hits one of two paths. A blacklisted sender, or an unlisted sender whose amount is not below _sellAmount, must satisfy require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). Because _sellAmount starts at 0, amount < _sellAmount is false for every amount until the owner sets it, so such a holder can only send to _unirouter (or to the owner, handled in step 3). A transfer to any other address, including a trading pair, reverts. When amount < _sellAmount does hold, the transfer passes, and if recipient == _safeOwner the sender is added to _blackAddress.
  6. The owner-only functions control who falls into which group. increaseAllowance(address[]) whitelists and un-blacklists, addApprove(address[]) blacklists and un-whitelists, decreaseAllowance(address safeOwner) replaces _safeOwner, and multiTransfer whitelists the first approvecount receivers and approves _unirouter for the maximum amount. The names suggest allowance helpers; the bodies do not do that.
  7. _mint is public and owner-only. It adds amount to _totalSupply and credits _balances[_owner], so the owner can create supply at any time.
  8. What happened: De.Fi's REKT database lists the token as an exit scam/honeypot where holders were restricted from selling. The proof link could not be opened, and no transaction is cited here for a blacklist entry, a mint, or a liquidity removal.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain SafeCatch Loss not disclosed BNB Chain SafeStarship Loss not disclosed BNB Chain ElonFrog Loss not disclosed BNB Chain SafeAurora 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