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.
a self-transfer exploit on blast hours before launch. you literally cannot make this up. 690 million tokens inflated to 11.5 trillion
blast l2 rush jobs everyone. launch fast, audit never. 1310 ETH extracted was probably the best day of that attackers life
1310 ETH gone because nobody tested the transfer-to-self edge case. basic unit testing would have caught this in 5 minutes
5 minutes is generous. transfer(to, amount) where to == msg.sender is literally the first edge case you test
literally chapter 1 of any solidity course. test that your token doesnt double when sent to self. blast ecosystem projects skipping this is embarrassing
11.5 trillion tokens from 690M. that’s not a bug that’s a money printer with extra steps. Blast rush jobs keep producing these greatest hits
690 million to 11.5 trillion tokens from a self transfer bug. the math on that dilution is comedic
The inflation from 690M to 11.5T tokens is a 16,000x increase. Even by crypto standards that is spectacular incompetence.
SoliditySam 690M to 11.5T is a 16,739x inflation from one missing check. the math on that incompetence is genuinely staggering
luna_ctrl 16739x inflation from a single missing require statement. auditors literally have a checklist for this exact pattern and it still ships to production
the fix is literally one line: check if sender equals receiver and revert. standard erc20 audits catch this, how did this slip through before mainnet?
one line fix but the audit team missed it because everyone was rushing to launch on blast before the competition
690M tokens inflated to 11.5T from a single missing require. the Solidity docs literally have a warning about self-transfers in the ERC20 section. you have to actively ignore the documentation to ship this bug
transfer(to, amount) where to == msg.sender and nobody thought to add a require. 1310 ETH extracted from a bug that’s literally in the Solidity docs warning section
1310 ETH extracted because nobody wrote sender != receiver. Blast L2 was paying incentives for projects to launch fast and this is what fast gets you. one line of code
11.5 trillion tokens from 690 million. the math is so absurd it sounds fake but thats what happens when your transfer function has zero balance validation
11.5 trillion tokens from 690 million. the blast L2 was basically a casino and the house forgot to lock the vault. any decent audit would have caught the self transfer bug in 10 minutes
launching on blast hours before the exploit. imagine the team staying up all night for launch just to watch 1310 eth walk out the door
blast launching before the game and the smart contract hadnt been audited for the simplest possible exploit. 1310 ETH gone because someone forgot to check if sender equals receiver
blast_larp_ launching hours before the game and skipping the most basic checks. 1310 ETH gone because sender == receiver wasnt blocked. one line of code
self-transfer exploits are one of the oldest tricks in the book. openzeppelin ERC20 has had this check for years
OZ has had this check since 2017. copy paste the import and youre safe. these devs either forked a broken contract or removed the modifier intentionally
Raj P. OpenZeppelin had this check since 2017. if you forked OZ and removed it youre either lazy or malicious
16,739x inflation from a missing require. seen this exact bug pattern in 3 different audit reports this year. people keep forking code without understanding what the modifiers actually protect against
the sad part is the fix was probably 1 line of code. 1310 ETH gone because nobody wrote a test for sender == receiver. this is day one solidity stuff
Tomasz W. one line of code and 1310 ETH gone. OpenZeppelin ERC20 has had this check since 2017 but people keep forking random contracts instead