Instadapp Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

This record covers a copycat token named "Instadapp" (INST) deployed on Ethereum on 15 June 2021 at 0x7b1385e6…d404ff by 0x05c4E2A3…A4C292; it is not the Instadapp protocol's INST 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 25 times. Each call credits the new tokens to _owner (_balances[_owner] = _balances[_owner].add(amount);) but emits a Transfer event naming another address, including 0x6f40d4A6…d303eb, the real Instadapp INST contract. Explorers therefore 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 INST

Evidence

Same attack technique

Browse all hacks →
Ethereum Gigachad Kishu Loss not disclosed BNB Chain LordShiba Loss not disclosed BNB Chain DOGEMASK Loss not disclosed BNB Chain Foxography 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