What happened
Chava is a BEP-20 token on BNB Chain built on a honeypot template that blocks transfers into one hidden address, stored in a variable named prevOwner. The first transferFrom after deployment silently stores its recipient there. When that call is the liquidity deposit into the PancakeSwap pair, the pair becomes the blocked address, and while the owner's ownerLock flag is on, which it is from deployment, every later transfer into the pair reverts.
Buyers can receive tokens from the pool, but holders cannot sell into it. The misleadingly named transferOwnership does not move ownership: it lets the owner point the block at any address. De.Fi's REKT database lists Chava as an exit scam/honeypot, with no loss figure.
How it happened
initData()gives the deployer all 100,000,000Chava(9 decimals) and setsownerLock=true.- The first
transferFromwith a non-zero sender records its recipient:if(from != address(0) && prevOwner == address(0)) prevOwner = to;. Adding liquidity through the router is atransferFrominto the pair. - While
ownerLockis true,transferreverts onrequire(to != prevOwner, "Handling Request")andtransferFromreverts onrequire(to != prevOwner, "Order TransferFromMiddleware"). A sale sends tokens into the pair and fails, while a buy sends tokens out of it and succeeds. - The owner can switch the block with
setOwnerLock(bool)and retarget it withtransferOwnership(address newOwner), whose body is onlyprevOwner = newOwner;. The real_owneris unchanged, and the publicpreviousOwner()getter makes the variable look like harmless history. renounceOwnership()does clear_owner, but the on-chainowneris still the deployer. The lock and the recordedprevOwnerstay in force either way.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
