Super Sushi Samurai Transfer Bug

On March 21, 2024, the Blast GameFi token Super Sushi Samurai (SSS) lost approximately $4.8 million to a token transfer logic bug: transferring tokens to oneself credited the balance without debiting it, doubling the sender's holdings each self-transfer. An attacker looped self-transfers to mint an effectively infinite balance, then dumped into the liquidity pool. A white-hat had independently discovered the same bug and was attempting to rescue funds when the malicious actor struck.

What happened

SSS's ERC-20 transfer implementation handled the from == to case incorrectly — it added the amount to the recipient before subtracting from the sender, so a self-transfer net-increased the balance. Repeated self-transfers inflated the attacker's SSS to arbitrary size; selling that supply drained the SSS/WETH pool of ~$4.8M.

Aftermath

• A white-hat recovered a portion (had been racing to secure funds via the same bug).
• The project negotiated partial returns; SSS collapsed.

Why it matters

Super Sushi Samurai is the same self-transfer / from == to accounting bug as MonoX (swap a token for itself) — the degenerate-input class. No legitimate user self-transfers to double their balance; precisely because it's degenerate, it goes untested. The catalogue's recurring rule: test the inputs no honest user would ever submit, because those are exactly the inputs an attacker will. Property-based testing ("for all a,b: balanceOf invariant holds after transfer(a,b) including a==b") catches this trivially; example-based tests written around expected user behaviour never will.