Event Horizon Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

Event Horizon (EHO) is a BNB Chain token deployed on 21 April 2021 at 0xaa2743ab…d94e28. Its internal _approve function only stores an allowance when the approving address is the hard-coded deployer 0x422303FF…5FC98e; for every other holder it stores zero while emitting an Approval event with the value 2. A PancakeSwap sale needs the router to move the holder's tokens with transferFrom, which then fails the allowance check, so holders can buy but not sell through the router, while the deployer's own approvals work.

The owner can also mint any amount of EHO to itself. De.Fi's REKT database lists Event Horizon as an exit scam/honeypot, stating that the contract owner could disable transfers and so stop holders from selling.

How it happened

  1. The constructor mints 10,000,000 EHO (3 decimals) to the deployer.
  2. When a holder approves the PancakeSwap router, _approve checks if (owner == address(0x422303FF698C8f5631B5652d19A1BcBd315FC98e)). For any other holder it runs _allowances[owner][spender] = 0; and emits Approval(owner, spender, 2), so the approval appears to succeed but grants nothing.
  3. A router sale calls transferFrom, which subtracts the amount from the zero allowance with sub(amount, "BEP20: transfer amount exceeds allowance") and reverts.
  4. Buys use the pair's transfer to the buyer, which needs no allowance, so buying keeps working.
  5. The hard-coded deployer address keeps normal allowances, so it can still sell through the router. The onlyOwner function mint(uint256) can create unlimited EHO for the owner. renounceOwnership would remove the mint power, but the allowance exception is tied to a fixed address, not to the owner role.

Protocol details

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

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.