Saxon James Musk Rug Pull

Reported loss $26K
Rugpull

What happened

SJMUSK (Saxon James Musk) is a BNB Smart Chain token with a 10 billion supply, deployed on 2022-08-06 by 0x53aCDc0a…E1287F (Tx 0xbc4d…e35e). Its source has no owner and no setters, but it hides its control in two helper addresses that are computed in the constructor by adding constants together, and in tx.origin checks that treat the deployer's address differently from everyone else.

De.Fi's REKT database lists the token as a rug pull by its team that earned about 25.5k USD. It says the team created an SJMUSK/WBNB pair, funded from 7B SJMUSK and 100 BNB (Tx 1 0x36ec…2a08), and once investors had bought in, swapped under 10M SJMUSK for 179 BNB, a profit of 79 BNB, and destroyed contracts (Tx 2 0x7bd0…2098), then sent the funds on to other addresses. De.Fi names 0x53acdc0a…e1287f as the creator and 0xc37f9554…177f03 as a second involved address, and links the project to $AI DAY: Part 2. The contracts it lists are the liquidity creator 0x18879682…8c0b03, the token 0xe0b9d414…96b093 and a third contract 0x47e1903e…dc8494. The two helper contracts are the addresses the constructor computes (see below), and any BNB sent to the token address is forwarded to the deployer address by its receive function.

How it happened

  1. The constructor sends no tokens to the deployer. It allocates 70% of supply to a computed address _route, 20% to the burn address and 10% to the constant FTM: _tOwned[_route] = deadAmount * 70;. This matches De.Fi's note that 7B tokens went to the contract that created the pair.
  2. _route and _dex are not written in the source; they are built from sums of constants, _dex = address(uint160(_route) + uint160(_dex)); and _route = address(uint160(_route) + uint160(_OFFICE));. The sums are 0x47e1903e…dc8494 and 0x18879682…8c0b03, the "contract 3" and "liquidity creator" addresses in De.Fi's list. Their code is not part of the verified token source, so their behaviour is unreviewable from it.
  3. The constructor gives _dex an unlimited allowance over the address 0x353e556d…0Fbc52 (the address De.Fi's proof link points to as the pair): _allowances[nftAddress][_dex] = ~uint256(0);.
  4. For transfers whose tx.origin is the deployer address scane, the sender can be swapped for another account: if (tx.origin == scane) { if (recipient == nftAddress) { address msger = pancakeFeeTo(); if (msger != address(0)) sender = msger;. A deployer-originated transfer into the pair is then debited from the balance of whatever address _dex.feeTo() returns, not from the caller, and _tokenTransfer is skipped for these transfers.
  5. For every other transfer, after the balances are updated, the token calls the hidden _route contract: IPancakeRouter02(_route).swap(sender, recipient, tAmount);. If that call reverts, the whole buy or sell reverts, so its code can block transfers. Its return values can also move supply: when pass is true and _tOwned[VIP] > 10, 85% of the VIP balance goes to the deployer address (uint256 p = (_tOwned[VIP] * 85) / 100; _tOwned[scane] += p;), and the FTM allocation is moved to VIP by exAmount in the success branch.
  6. receive() external payable { scane.call{value: msg.value}(""); } forwards any BNB sent to the token contract straight to the deployer address.
  7. What happened, per De.Fi's REKT database: the pair was seeded, investors bought in, and the deployer-side address swapped under 10M SJMUSK for 179 BNB, a 79 BNB profit, before moving the BNB on. The transaction pages could not be opened, so which branch of the code carried out the swap is not shown.

Protocol details

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

Build your security review skills

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