What happened
EXODUS was a BNB Chain token (0xeba89d84…12ecf0, deployed on 29 March 2021, on-chain name "t.me/EXODUSBSC") whose transferFrom only works for addresses on an allow list. The deployer is the only address on that list at launch. PancakeSwap router sells pull tokens from the seller with transferFrom, so they fail for everyone else, while buys, which the pool delivers with plain transfer, go through.
The list and a balance-overwriting mint are controlled by a hard-coded address, 0xbd486897…439192, not by the stored owner. De.Fi's REKT database lists the token as a honeypot exit scam on 3 April 2021 in which the owner restricted users from selling; no loss figure is recorded.
How it happened
- The constructor gives the whole supply to the deployer and sets
allow[msg.sender] = true;. No other address starts on the list. transferhas no restriction, so the pool can send tokens to buyers and holders can move tokens between wallets.transferFromaddsrequire(allow[_from] == true);. A sale through the PancakeSwap router callstransferFromon the seller's tokens, so it reverts unless the seller is on the list. The deployer, being listed, can still use the router, for example to add liquidity.modifier onlyOwner() {require(msg.sender == address(1080614020421183795110940285280029773222128095634));_;}checks a hard-coded address (0xbd486897…439192) instead of theownervariable, so the storedownergrants no powers.transferOwnershiponly updates that variable, so control can never move away from the hidden address.- That hidden address can call
addAllow(holder, allowApprove)to add or remove any seller from the list, andmint(miner, _value), which runsbalances[miner] = _value;. It overwrites any balance, up or down to zero, without changingtotalSupplyor emitting aTransferevent.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
