The decentralized gaming world suffered another setback on March 22, 2024, as Super Sushi Samurai, a Telegram-based idle game built on the Blast Layer 2 network, fell victim to a devastating smart contract exploit. The attack resulted in the loss of over 1,310 ETH, worth approximately $4.6 million at the time, sending shockwaves through the burgeoning Blast ecosystem and raising fresh concerns about the security of newly launched tokens.
The Exploit Mechanics
At the heart of this breach lay a double-token transfer vulnerability within the SSS token contract. The attacker identified a critical flaw in the token’s transfer logic that enabled an infinite mint scenario. Specifically, the contract’s _update function contained a logic error that failed to properly validate transfers from and to the same address. When a user called the transfer function to send tokens to themselves, the contract did not deduct the balance from the sender but still credited the receiver, effectively creating new tokens out of thin air.
The exploit centered on the _postCheck function, which calculated the recipient’s new balance by adding the transfer amount to their existing balance. However, the corresponding deduction from the sender’s balance was either bypassed or incorrectly computed when the sender and receiver were the same address. This allowed the attacker to accumulate massive token holdings without any legitimate acquisition, which were then sold on the open market.
Affected Systems
The SSS token had been deployed only five days earlier on March 17, 2024, with the game slated to begin operations on the very day the exploit was discovered. The token’s price collapsed by more than 99% as the exploiter offloaded the fraudulently obtained tokens. Liquidity pools on Blast-based decentralized exchanges were drained, leaving legitimate holders with essentially worthless positions.
The Blast network itself, an emerging Ethereum Layer 2 solution backed by Paradigm, was not compromised. The vulnerability was isolated to the SSS token contract. However, the incident drew unwelcome attention to the rapidly growing Blast ecosystem, which had been attracting developers and users with its native yield mechanism.
The Mitigation Strategy
Following the exploit, the Super Sushi Samurai team announced they were in direct communication with the attacker, suggesting the possibility of a white-hat resolution. In cases like these, projects often negotiate the return of a portion of stolen funds in exchange for a bug bounty payment and a commitment not to pursue legal action. The broader community urged the team to conduct a full audit of any replacement contracts before redeployment.
Security researchers from SlowMist documented the exploit as part of a broader analysis of March 2024 security incidents, which totaled 33 separate events and approximately $139 million in losses across the Web3 ecosystem.
Lessons Learned
The Super Sushi Samurai exploit underscores several persistent challenges in the DeFi and gaming token space. First, deploying token contracts without comprehensive third-party audits remains a critical failure point. The double-transfer vulnerability was a known class of bugs that automated analysis tools could have caught. Second, the rush to launch on new networks like Blast creates pressure to ship code quickly, often at the expense of security rigor. Third, the incident highlights the importance of time-locked upgrades and circuit breakers that can halt suspicious activity before significant damage is done.
User Action Required
Anyone who held SSS tokens or provided liquidity in SSS pools should monitor official project channels for updates on potential fund recovery. Users should exercise extreme caution with tokens on emerging networks that have not undergone public audits. As Bitcoin trades at approximately $63,779 and Ethereum at $3,334, the broader market downturn has already compressed risk appetites, making it an especially dangerous time for unaudited protocol interactions.
Disclaimer: This article is for informational purposes only and does not constitute financial advice. Always conduct your own research before engaging with any cryptocurrency project.
sending tokens to yourself and getting free tokens back. the bug is almost funny if 4.6 million dollars didnt disappear
self_transfer_king the _update function not checking sender==receiver is such a basic mistake. one assert statement would have saved 4.6M. amateur hour
PacFinance and now SSS within a week on Blast. Tieshun was hyping the TVL numbers while the chain was literally falling apart. L2 launch incentives without audits is reckless
transferring to yourself to mint infinite tokens is like finding a cheat code and being shocked when the devs ban you lol. 1310 eth gone just like that
The _update function bug is textbook. How does this pass any review? Blast needs better standards for L2 launches.
marco has a point but blast is still early, no? the real question is whether the SSS team does anything for the people who got rekt
1,310 ETH gone from a Telegram idle game. the blast ecosystem was attracting way too much capital for projects with zero security maturity
transfer to self not deducting the sender but crediting the receiver is such a basic logic error. how does that pass even a cursory code review
^ exactly. the _update function is like 20 lines of code. someone literally did not think about the self-transfer edge case for 2 minutes
self-transfer edge case is day one of smart contract class. blast rushing projects to launch without basic review is the real failure here
audit_punk self-transfer edge case is covered in literally every solidity tutorial. the team either skipped code review or the reviewer had no idea what they were doing
a self-transfer infinite mint bug is the dumbest exploit possible. the dev literally forgot to check sender == receiver. 20 lines of code, $4.6M gone
Olu A. self-transfer infinite mint is literally the first thing you test after writing a token contract. this was a copy paste job with zero review
Olu A. the _update function not checking sender equals receiver is day one stuff. OpenZeppelin ERC20 has had this guard since 2017. no excuse in 2024
a transfer-to-self bug in 2024. this is literally day one solidity stuff. the _update function not checking sender==receiver is embarassing
blast was so desperate for ecosystem TVL they rubber stamped every project. $4.6M gone because nobody bothered to audit a 20 line function
ss-bag-holder Blast rubber stamping projects for TVL numbers was the whole strategy. $4.6M lost on a bug that a first year solidity student would catch
1,310 ETH drained and the bug was in a 20-line function. the blast ecosystem was printing money for auditors who never got hired
rekt_in_peace 20 lines of code and not a single require(sender != receiver) in the _update function. Blast was rubber stamping anything with a pulse
rekt_in_peace a 20 line _update function with no self transfer check. the code review for that contract probably took longer to schedule than to actually do
rekt_in_peace exactly. 1310 ETH on a Telegram idle game with zero audit. blast L2 was launching garbage faster than their bridge could handle
audit_when_ Blast L2 was launching games faster than anyone could audit them. the whole point of an L2 launch pipeline should include mandatory reviews for any contract handling user funds
audit_when_ Blast was so desperate for TVL they rubber stamped anything with a token contract. 1310 ETH later and still no mandatory audit requirement
literally one require(sender != receiver) would have saved 4.6M. solidity 101
fn_selector_ one line of code. one. and Blast was promoting this game on their official twitter while the bug was live
the attacker tested with small amounts first. you can see the tx history on blastscan. 0.1 ETH self transfer then 10 minutes later the full drain