Yearn-V3 Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

This record covers a token named "Yearn-V3" (YV3) deployed on Ethereum on 7 June 2021 at 0x9a3098aa…6b3641 by 0x377A8FBF…1379Ab; it borrows the Yearn name but is not a Yearn Finance token. Its transfer and transferFrom run through a modifier, burnTokenCheck, that lets the owner and one owner-chosen address move tokens freely but makes ordinary holders' transfers revert with a fake "transfer amount exceeds balance" error unless the recipient is the Uniswap V2 router itself. A Uniswap sale sends tokens to the pair, not the router, so holders who are not whitelisted cannot sell.

Owner-only functions disguised with ERC-20 names (increaseAllowance, addApprove, decreaseAllowance) edit a whitelist, a blacklist and the privileged address, and a public owner-only _mint can create new tokens at any time. De.Fi's REKT database lists the token as a honeypot; no loss figure is recorded.

How it happened

  1. The constructor calls _mint 50 times. Each call credits the new tokens to _owner (_balances[_owner] = _balances[_owner].add(amount);) but emits a Transfer event naming 0x7A1057E6…fC4c67 or 0x2D407dDb…47d45C, so explorers show mints to addresses that never received the balance.
  2. The owner's first outgoing transfer sets _safeOwner to its recipient. After that, transfers from _owner or _safeOwner, or to _owner, always pass.
  3. For any other sender, burnTokenCheck passes the transfer only if the sender is whitelisted, or if the amount is below _sellAmount. _sellAmount starts at 0 and only the owner can raise it, by sending tokens to itself.
  4. Every other transfer hits require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). A sale through the Uniswap V2 router moves tokens from the seller to the pair, so it reverts with a misleading balance error.
  5. If the owner does raise _sellAmount, a small sale to _safeOwner goes through once and then blacklists the seller: if(recipient == _safeOwner){_blackAddress[sender] = true; ...}.
  6. The owner can whitelist addresses with increaseAllowance(address[]), blacklist them with addApprove(address[]), replace _safeOwner with decreaseAllowance(address), and airdrop through multiTransfer, which also whitelists recipients and approves the router to spend their tokens. The contract has no function to renounce or transfer _owner.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain delta.theta Loss not disclosed Ethereum Cooktail Inu Loss not disclosed Ethereum komainu.finance Loss not disclosed Ethereum JUST FAIR LAUNCH 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