Rug-pull fingerprints from bytecode

The Contract Reader compares every contract it checks against a library of real rug pulls. It looks for the same combination of owner powers — mint, pause trading, blacklist, mutable fees, upgradeability, privileged withdrawal, and whether an owner is still in control. The library is only as good as its entries, and our first entry was wrong. The Squid Game token's published source is nearly double the length our source reader handles, so the read was truncated and missed most of what mattered.

Bytecode doesn't have that problem. It's the code that actually runs, it can't be selectively published, and it's the same size whether or not the project verified anything. So we rebuilt the library from it.

1. Decompile. Each contract's deployed bytecode was decompiled with Ghidra and the open-source Mothra EVM extension. Every function was recovered in all five contracts: 50/50, 27/27, 194/194, 54/54, and 13/13 for Squid's proxy plus 94/94 for its implementation.
2. Name the functions. Function selectors were pulled from each contract's dispatcher and resolved against public signature databases.
3. Prove who can call them. A function name is a claim, not evidence. Each privileged function was simulated from a random address and from the real owner, as read-only calls. It had to fail for the first and succeed for the second to count.
4. Run what can't be simulated. For behaviour that needed real execution, we used a local copy of the chain (a fork running on our own machine) and traced every storage write. No transaction was ever sent to the live network.

The deployed Squid Game token is an upgradeable proxy. Its only function is named approveTo(address), which sounds like an ordinary token approval. It isn't one. The decompiled code checks whether the caller is the proxy admin, then replaces the contract's entire logic and emits the standard Upgraded event. It's an upgrade switch with a harmless name.

The bigger finding is a role that has nothing to do with the owner. A variable called _masterChef holds a plain wallet address, not a contract, and that wallet can call burn(address, uint256) against any holder. On the local fork, it burned the liquidity pool's entire token balance in one call. Two more functions, callable only by that wallet, force the pool to re-sync its reserves. Together they let one wallet wipe out the pool's token side and reprice everything left in it.

Squid Game's ownership was renounced. That's the check most people look at, and here it proved nothing, because the dangerous power was never the owner's.

Each fingerprint records whether an owner was in control at the time of the rug, not today. Several of these owners renounced afterwards, but the Contract Reader checks live contracts before anything goes wrong, so rug-time state is what has to match.

A match means a contract gives its owner the same combination of powers one of these rugs had. It does not mean the code is the same, or that the owner will use those powers. Plenty of legitimate projects keep an owner who can mint. We tested the matching before it went live: a contract whose only flag is an active owner, and a stablecoin-style profile with mint, pause, blacklist and upgrade powers, both stay below the match threshold.

The reverse holds too: no match is not a clean bill of health. It only means the contract doesn't look like these five.

Squid Game's implementation contains 22 functions that no public signature database can name. We probed all of them on the fork. None changed total supply or credited a target wallet, but we only tried one argument shape, so we score its trading-halt and fee powers as undetermined rather than guessing. The known-scam library is small by design: every entry has to be backed by this kind of evidence before it goes in.