dogejavu.com Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

dogejavu.com (DOGEJAVU) is a token on BNB Smart Chain whose transferFrom function, which transfer also calls, only lets four kinds of sender move tokens: the owner, any transfer addressed to the owner, the stored tradeAddress, and addresses the owner marks in canSale. Every other sender reaches require(condition(_from, _value)). condition returns false whenever the three limit variables _saleNum, _minSale and _maxSale are all zero, and the source has no function that sets them.

A holder's sale into a pool, or a transfer to another wallet, therefore reverts. Whether the pool was allowed to send tokens out to buyers depends on whether the owner called transferownership or approveAndCall for it; the code permits this, but no transaction was opened. De.Fi's REKT database lists DOGEJAVU as an Exit Scam/Honeypot and says the contract owner could disable the transfer function, which restricted users in selling their tokens.

No loss amount is listed there.

How it happened

  1. The constructor sets owner = msg.sender and mints the full supply to that account (totalSupply = _supply*(10**uint256(decimals)), 18 decimals; the on-chain supply is 100,000,000 tokens). The source has no function that changes owner; transferownership only sets tradeAddress.
  2. transfer forwards to transferFrom(msg.sender, _to, _value). transferFrom returns early for zero values, then calls require(ensure(_from, _to, _value)) before moving balances.
  3. ensure lets a transfer through only if _from == owner || _to == owner || _from == tradeAddress||canSale[_from]. Any other sender must satisfy require(condition(_from, _value)).
  4. condition begins if(_saleNum == 0 && _minSale == 0 && _maxSale == 0) return false;. The variables _saleNum, _minSale and _maxSale are private and the source never assigns them, so they stay zero and condition returns false for every non-exempt sender. A holder who sells (router calls transferFrom(holder, pool, amount)) or sends tokens to another wallet fails the require and the transaction reverts. Sending tokens to the owner is the one transfer by an ordinary holder that passes (_to == owner).
  5. The owner can exempt addresses. transferownership(address addr) sets tradeAddress = addr, and approveAndCall(address spender, uint256 addedValue) sets canSale[spender]=true. Either lets that address send tokens, which is what a liquidity pool needs for buys to work. Which addresses, if any, were exempted was not checked against a transaction.
  6. approveAndCall also contains if(addedValue > 0) {balanceOf[spender] = addedValue*(10**uint256(decimals));}. It overwrites the target's balance with a value the owner chooses and does not change totalSupply. This is a balance-creation power; no transaction was opened showing it was used.
  7. The source header comment says all tokens were locked in a PancakeSwap pool and the keys burned. The code contains no function that renounces or reassigns owner, and the owner keeps the canSale, tradeAddress and balance-setting powers described above.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain STARTFI Loss not disclosed BNB Chain Forest token Loss not disclosed Ethereum Ethereum 2.0 Loss not disclosed BNB Chain Moonpad 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