Maxxi Protocol Honeypot
What happened
De.Fi's REKT database lists Maxxi Protocol (MAXX, BNB Chain, contract 0xef1360c1…ccb21e) as an Exit Scam/Honeypot and says the contract owner could disable the transfer function, which restricted users in selling their tokens. The verified source has no owner-operated switch. Instead, the first transfer made from any non-zero sender stores its recipient in _xowner, and every later transfer whose recipient is _xowner reverts with "Recipient not found." The owner is not exempt and no function changes _xowner.
If that first recipient was the liquidity pair, holders could buy from it but every sale into it would revert; the code does not show who the first recipient was.
How it happened
- The constructor sets
_tokenSupply = 100000000 * 10**9;and calls the two-argumentsetWallets(payable(msg.sender),_tokenSupply);, which credits the whole supply to the deployer and leaves_xownerat the zero address. - The first
transferortransferFromrunssetWallets(sender, recipient, amount), whereif(sender != address(0) &&_xowner == address(0)){ _xowner = recipient;records that first recipient. - Every later transfer takes the
elsebranch,require(recipient != _xowner, "Recipient not found.");, so no transfer to that stored address can succeed, whoever the sender is and including the owner. _xowneris written only in this branch.renounceOwnershipandtransferOwnershipchange_owneronly, andgetBurnAddress()just lets the owner read_xowner. The block therefore cannot be lifted by any function in the contract.- If the stored recipient was the pair created when liquidity was added, a sale would transfer tokens to it and revert, while purchases from it would succeed. The code alone does not show whether that happened.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.