Anatomy of a Self-Transfer Exploit: Technical Breakdown of the Super Sushi Samurai $4.6M Smart Contract Bug

On March 21, 2024, blockchain game Super Sushi Samurai lost $4.6 million worth of tokens to a remarkably simple smart contract vulnerability — a bug in the token’s transfer function that allowed users to double their balance by transferring tokens to their own address. The exploit, which occurred on the Blast layer-2 network hours before the game’s official launch, resulted in the creation of 11.5 trillion tokens from an initial 690 million, ultimately extracting approximately 1,310 ETH from the project’s liquidity pool. This technical walkthrough dissects exactly how the vulnerability worked, why standard auditing practices missed it, and how developers can prevent similar bugs in their own contracts.

The Objective

By the end of this guide, you will understand the mechanics of self-transfer exploits in ERC-20 token contracts, recognize the code patterns that create these vulnerabilities, and be able to implement defensive coding practices that prevent them. This is not a theoretical exercise — the Super Sushi Samurai exploit demonstrates that these bugs exist in production code handling millions of dollars, and understanding them is essential for anyone involved in smart contract development or auditing.

Prerequisites

This guide assumes familiarity with Solidity syntax, ERC-20 token standards, and basic smart contract security concepts. You should understand how the _transfer function in ERC-20 tokens works: it decrements the sender’s balance, increments the recipient’s balance, and emits a transfer event. You should also have a basic understanding of how automated market maker (AMM) liquidity pools function, as the exploit ultimately targeted the token’s liquidity pool.

Step-by-Step Walkthrough

Step 1: Understanding the vulnerable code. The Super Sushi Samurai (SSS) token contract contained a transfer function with the following logic pattern: first, decrement the balance of the sender (the from address), then set the balance of the recipient (the to address). In normal transfers between two different addresses, this works correctly — the sender loses tokens and the recipient gains them. However, when from and to are the same address (a self-transfer), the order of operations creates a critical flaw.

Step 2: The doubling mechanism. When a user transfers their entire balance to themselves, the function first decrements the user’s balance to zero, then sets the user’s balance to the transferred amount — which is the original balance. In effect, the balance is restored rather than changed. However, if the code is structured to set rather than add, and if the decrement happens after the amount is already captured but before it is deducted from the sender, a specific edge case emerges: the user’s balance gets doubled because the decrement applies the subtraction after the amount is already captured but before it is deducted from the sender.

Step 3: The exploit chain. The attacker acquired 690 million SSS tokens and initiated a series of self-transfers through an attack contract specifically designed for this purpose. Each self-transfer doubled the token balance. By repeating this process approximately 25 times, the attacker inflated their holdings from 690 million to 11.5 trillion tokens — a 16,667x increase achieved through pure arithmetic exploitation.

Step 4: Liquidity pool drainage. With 11.5 trillion newly minted tokens, the attacker swapped them into the SSS/ETH liquidity pool, extracting approximately 1,310 ETH (worth roughly $4.6 million at the time, with ETH trading near $3,493). The token price crashed by 99% following the dump, as the liquidity pool was effectively drained of its ETH reserves.

Step 5: The fix. The correct implementation for an ERC-20 transfer function must handle the self-transfer edge case explicitly. The OpenZeppelin standard implementation addresses this by checking if from and to are the same address before performing any balance modifications. If they are identical, the function can simply return early without modifying any state. Alternatively, the function can use addition and subtraction rather than set operations, which naturally handles the self-transfer case.

Troubleshooting

If you are auditing a token contract and suspect a self-transfer vulnerability, look for these patterns: balance operations that use = (set) instead of += and -= (add/subtract), transfer functions that do not explicitly handle the from == to case, and balance checks that occur in the wrong order relative to state modifications. Fuzzing tools like Echidna can automatically discover these edge cases by generating random transfer patterns, including self-transfers, and checking for balance inconsistencies.

Mastering the Skill

The Super Sushi Samurai exploit is a masterclass in how simple logical errors can have catastrophic financial consequences. To level up your smart contract security skills, practice auditing real token contracts and specifically look for edge cases in arithmetic operations. Study the OpenZeppelin ERC-20 implementation to understand how battle-tested code handles these scenarios. Consider using formal verification tools like Certora to mathematically prove that your contracts maintain balance invariants under all possible transaction patterns. Finally, always run comprehensive test suites that include edge cases like zero-amount transfers, self-transfers, and transfers to the zero address — because in smart contract security, the edge cases are where the millions of dollars live.

Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any investment decisions.