Pera Finance Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

Pera Finance ($Pera) is a BEP-20 token on BNB Smart Chain, deployed from 0xded51b18…bF537e at contract address 0xcb0ff1a8…f74a38. The source file opens with a comment describing a yield-farming protocol, but the contract itself contains only a token and an owner BNB-withdrawal function, with no staking or reward logic. Its transfer and transferFrom functions use a variable, newun, that records the first address to receive tokens through transferFrom and then rejects every later transfer to that address with the message "please wait".

A trading pool receives tokens whenever someone sells, so once the pool address is captured, selling reverts while buying (tokens leaving the pool) is not checked. De.Fi's REKT database lists the token as an Exit Scam/Honeypot in which the contract owner could disable the transfer function, restricting users from selling; it gives no loss figure and no transaction hashes.

How it happened

  1. The constructor sets symbol = "$Pera", name = "Pera Finance", decimals = 8 and _totalSupply = 1000000000000000000, i.e. 10 billion tokens, and assigns all of it to balances[owner]. The owner is the deployer: Owned sets owner = msg.sender.
  2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom with a non-zero sender therefore stores its recipient in newun without any check. A router-based liquidity add moves the owner's tokens to the pool with transferFrom, so the pool can become newun this way (the code allows this; the on-chain newun value was not read).
  3. From then on every transferFrom whose recipient equals newun reverts, because the else branch requires to != newun. A sell through a router calls transferFrom(seller, pool, amount), so it fails for every holder. transfer has the same guard: require(to != newun, "please wait");.
  4. Buys are not affected by this check: the pool pays buyers with transfer(buyer, amount), and the guard only tests the recipient against newun. Holders can therefore acquire tokens that they cannot sell back through the pool.
  5. The owner can call transfernewun(address _newun) (onlyOwner) to overwrite newun. Setting it to address(0) makes the next transferFrom recipient be captured again, so the block re-arms; only pointing it at an address that is not the pool lifts it. The only ownership functions are transferOwnership and acceptOwnership; there is no renounceOwnership.
  6. clearCNDAO() (onlyOwner) sends the contract's own BNB balance to the owner, and the contract has a payable fallback. This does not touch holders' tokens or the pool.
  7. What happened on chain is not established here: no sell transactions, liquidity removal or owner calls were opened. Only De.Fi's REKT database listing states that selling was restricted.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract $Pera

Evidence

Same attack technique

Browse all hacks →
BNB Chain XSPACE Loss not disclosed BNB Chain AnimalHouse Finance Loss not disclosed BNB Chain Free Britney Loss not disclosed BNB Chain TRUMP 2024 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