Magic Rug Pull
What happened
Magic (Magic) is a BNB Smart Chain token whose owner keeps broad control after launch. The contract lets the owner mint new tokens to their own address, burn tokens from any holder's balance, blacklist any address so it cannot send or receive, and pause all transfers. De.Fi's REKT database lists the project as a rug pull with about $47,315 taken, and records that tokens were swapped for 8,485.69 USDT (BSC-USD).
De.Fi's listing gives these addresses and transactions:
- Token: 0x37760475…565c84
- Swap of tokens for 8,485.69 BSC-USD: 0xcd2e66b8…a1c502
- Tokens minted to: 0xfae915e7…06f995
- Then transferred to 0xcb49a393…00cd0b, which transferred to 0x377636cc…b9f310 and then to 0x739e6290…51fac7
The verified source shows the whole 10,000,000 supply is credited to the deployer in the constructor, so the deployer starts holding all tokens before any pool exists. The code does not show who supplied or removed liquidity, and the transactions above could not be opened, so the movement of funds is attributed to De.Fi's listing only.
How it happened
- At deployment the constructor credits the whole supply to the deployer:
_balances[msg.sender] = _totalSupply;with_totalSupply = 10000000 * 1e18. The deployer, 0xfAe915e7…06F995, is also the owner (ownerstill reads 0xfae915e7…06f995 on-chain), so one address holds all tokens and every admin power. - The owner can create more supply at will:
function mint(uint256 amount) public onlyOwner { _mint(_msgSender(), amount); }. There is no cap and the new tokens always go to the owner. An owner can also reduce any holder's balance:function burn(address account, uint256 amount) public onlyOwner { _burn(account, amount); }. - Transfers can be shut off per address or for everyone.
_transferstarts withrequire(!isBlackListed[sender] && !isBlackListed[recipient],"blacklisted");, so a blacklisted holder cannot sell (the holder issender) and a blacklisted pair cannot receive or send;addBlackList(address _evilUser) public onlyOwnersets the flag.pause()isonlyOwnerand_beforeTokenTransferiswhenNotPaused, which stops every transfer. - Trades through the recognised pairs (RLT or USDT pairs on BitbyteSwap or PancakeSwap, plus any pair the owner adds with
addOtherSwapPair) pay a fixed 2% burn and 4% fee: the sender is debited the fullamount, the recipient receivesamountminus both fees, and the 4% goes tolpFeeTo, which the owner can change withsetFeeTo. The rates are constants (burnRate = 2 * 1e16,lpFeeRate = 4 * 1e16), so this is a trading tax rather than a sell block. - All the powers above can be given up by the owner through
renounceOwnership(), but nothing in the contract forces this, and the owner address is unchanged on-chain. - What happened, per De.Fi's REKT database: tokens were swapped for 8,485.69 BSC-USD, tokens were minted to 0xfae915e7…06f995 and moved through three further addresses, and about $47,315 was taken in total. Whether the owner
mintfunction was called, and how the liquidity was removed, is not shown by the source and the BscScan transactions could not be opened.
Protocol details
Evidence
- transaction De.Fi REKT database listing for Magic (as imported in meta.json) bscscan.com
- address BscScan verified source: Magic 0x37760475953a7b37fdcee8d6c7506d9624565c84 bscscan.com
- address bscscan.com address 0x3776…5c84 bscscan.com
- address bscscan.com address 0x3776…f310 bscscan.com
- address bscscan.com address 0x739e…fac7 bscscan.com
- address bscscan.com address 0xcb49…cd0b bscscan.com
- address bscscan.com address 0xfae9…f995 bscscan.com
- analysis Sourcify match: Magic.sol repo.sourcify.dev
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.