Mother Rug Pull

Reported loss $734K
Rugpull

What happened

MOTHER is a BEP20 token built from a CoinToken template that gives its owner a minting function with no cap, a blacklist, a whitelist and a greylist that blocks selling. The token's name, symbol and supply are set by initToken after deployment, and the owner is set in the same call. Because Ownable has no renounceOwnership or transferOwnership, the code gives the owner no way to hand the powers over or give them up.

De.Fi's REKT database lists MOTHER as an exit scam / rug pull in which the deployer profited by 733,883 USD, and De.Fi Security's post of 2023-05-16 reports about 734,000 USD stolen in MOTHER tokens and notes that MOTHER and LINDA were deployed with the same smart contract. The existing text states that the deployer minted 2,000,000,000,000 MOTHER and drained the pool over several transactions, moving the proceeds to another address. Addresses from that listing: scammer address 0x6f0fc555…4f74bd, funds holder 0xf5a19d8d…b7b2ae, mint transaction 0x23ad2c25…888e49, draining transaction example 0xeeCfF022…19d841 and liquidity removal transaction 0x85aff054…9b8ff4. The explorer pages could not be opened, so these come from the De.Fi listing only.

How it happened

  1. initToken assigns the supply and the owner in one call that anyone can make once: balances[tokenOwner] = totalSupply; and owner = tokenOwner;, guarded only by notInitialized. The contract has no renounceOwnership or transferOwnership, so the owner stays fixed.
  2. The owner can create unlimited tokens: function mint(address account, uint256 amount) onlyOwner public { totalSupply = totalSupply.add(amount); balances[account] = balances[account].add(amount); .... There is no cap and no timelock. Minted tokens can be sold into the PancakeSwap pool for its BNB or USDT side, and every other holder is diluted.
  3. A sell block is built into the transfer functions. When changeAb(true) has been called (onlyOwner), if(msg.sender==LP&&ab&&!tokenWhitelist[_to]){ tokenGreylist[_to] = true; ...} marks every non-whitelisted wallet that receives tokens from the pair, which means every buyer. The pair sends tokens with transfer, so the check runs on buys.
  4. A greylisted wallet cannot sell. A router sale calls transferFrom(_from=holder, _to=pair) and transferFrom requires require(tokenGreylist[_from] == false);, which reverts; a direct transfer reverts on require(tokenGreylist[msg.sender] == false);. The only escape is tokenWhitelist, which bypasses all of these checks when _from or _to is whitelisted and which only the owner can set with whiteListAddress.
  5. The owner can also freeze individual holders with blackListAddress, blackAddressList and geryListAddress. Blacklisting the router blocks it as msg.sender in transferFrom, which stops router-based sells for every non-whitelisted wallet.
  6. What happened, per the De.Fi listing and De.Fi Security's post: the deployer minted tokens, sold them into the pool in several transactions, removed liquidity and moved the proceeds to another address, for about 734,000 USD. The code shows that these actions were possible; whether ab was ever switched on or any wallet was greylisted is not established by an opened transaction.

Protocol details

Classification Token
Protocol Type Exit Scam/Rugpull
Affected asset / contract MOTHER

Evidence

Same attack technique

Browse all hacks →
POOPEPE token $100K lost Fintoch $31.7M lost Linda Yaccarino $375K lost DerpMan $88K lost

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