SIR Protocol Exploit: Analyzing the Transient Storage Vulnerability

Summary

On March 30, 2025, the SIR Trading protocol, an Ethereum-based leveraged trading protocol, was exploited, resulting in a loss exceeding $360,000 in multiple assets like USDC, wETH, and wBTC. This attack marks one of the earliest exploits leveraging Ethereum’s transient storage feature. Understanding this incident is critical for developers, security researchers, and stakeholders in the blockchain community to prevent similar vulnerabilities in future implementations.

About SIR Trading

SIR Trading (Synthetics Implemented Right) is a leveraged trading platform built on Ethereum that launched on February 20, 2025. The protocol allows users to mint leveraged tokens backed by collateral, interacting primarily with Uniswap V3 for token swaps. Despite promising innovation, the project operated on limited resources, having raised only $70,000 from supporters on Twitter, facilitating a single security audit conducted by Egis Security before the exploit.

Initial Reporting and Founder Reaction

The exploit was first flagged on X (formerly Twitter) by Web3 security firms such as TenArmorAlert and Decurity, who identified abnormal activity and began publicly analyzing the situation. Shortly after, the founder of SIR Trading, Xatarrer, acknowledged the exploit and confirmed that the protocol’s total TVL—over $360,000—had been drained. Xatarrer responded with visible distress, offering a $100,000 bounty to the attacker in hopes of retrieving a portion of the lost funds. The attack highlighted the devastating impact of inadequate security practices.

Later, SlowMist published a detailed technical report analyzing the root cause of the exploit and confirming the misuse of Ethereum’s transient storage feature.

Major Addresses Involved

• Exploiter Wallet: 0x27defcfa6498f957918f407ed8a58eba2884768c

• Victim (Vault) Contract: 0xb91ae2c8365fd45030aba84a4666c4db074e53e7

• Malicious Contract (Deployed via CREATE2): 0x00000000001271551295307acc16ba1e7e0d4281

• Token A : 0xea55fffae1937e47eba2d854ab7bd29a9cc29170

Prerequisite Knowledge

To fully understand this exploit, one must be familiar with Ethereum's storage mechanisms, especially with EIP-1153. Previously, smart contracts primarily relied on SSTORE and SLOAD for storing and retrieving data. These operations were permanent and expensive, consuming significant gas due to their long-term persistence on-chain.

Ethereum's Dencun upgrade introduced transient storage via EIP-1153, providing temporary, low-cost storage limited to a single transaction. Operations like TSTORE(key, value) temporarily storing data, while TLOAD(key) retrieves this data within the same transaction. Crucially, transient storage automatically resets after transaction completion, significantly lowering costs but introducing complexity that can be exploited if mismanaged.

Decoding the Exploit

The exploit was a direct result of the Vault contract's improper handling of transient storage. Initially, the Victim (Vault) contract 0xb91ae2c8365fd45030aba84a4666c4db074e53e7 utilized a transient storage slot 0x01 to store the address of the Uniswap V3 liquidity pool 0xe4c684f944b26b21167ef5a25f52311ab7822831 , created by the exploiter during token swap operations. However, the same transient storage slot was later reused within the same transaction to store the mint amount of tokens, effectively overwriting the initial pool address.

In simple terms, the vulnerable contract was initially executed TSTORE(0x01, poolAddress) to temporarily store the Uniswap pool address. Later in the same transaction, the code performed another TSTORE(0x01, amount) operation on the same storage slot, 0x01. As a result, the verification logic within the uniswapV3SwapCallback() function, require(msg.sender == TLOAD(0x01)); no longer retrieved the intended pool address, but instead retrieved the mint amount value.

The attacker exploited this oversight by calculating the exact mint amount 95759995883742311247042417521410689 to match a specific Ethereum address. This involved brute-forcing a vanity Ethereum address 0x00000000001271551295307acc16ba1e7e0d4281 labelled as Malicious contract to precisely equal this numerical value. Then, by deploying the Malicious contract at this exact address using Ethereum's CREATE2 opcode, the attacker perfectly matched the overwritten transient storage value.

Then, it set up Token A by injecting a final minting amonut 1337821702718000008706643092967756684847623606640 , which is stored in the transient storage third time. With this setup, the attacker called the vulnerable Vault function uniswapV3SwapCallback() directly from their Token A contract. Since msg.sender it matched the overwritten transient storage value, the security and caller check mistakenly passed, allowing the attacker to impersonate the legitimate Uniswap pool and enabling unauthorized transfers of funds from the Vault.

Following this, the attacker repeatedly triggered swap callbacks and mint operations, leveraging the manipulated identity check to mint APE tokens and extract assets from the Vault. Each interaction allowed the attacker to further drain USDC, WBTC, and wETH, which were then swapped into wETH eventually using ParaSwap and Odos. Ultimately, the attacker routed the stolen funds into Railgun, a privacy-focused protocol, effectively concealing the transaction trail and making on-chain recovery more difficult.

On-Chain Activity

To better understand the exploit from an on-chain perspective, we analyzed it using Blockscope’s Tracer tool. The first trace (Tracer 1) captures the exploit in action—showing how the attacker triggered the vulnerable uniswapV3SwapCallback function and initiated unauthorized token transfers from the Vault. The below attacker shows the various contracts and addresses involved during the exploit.

The second trace (Tracer 2) highlights the post-exploit fund flows, revealing how the attacker swapped, consolidated, and routed stolen asset into Railgun, a privacy-focused protocol, effectively obfuscating their origin and movement.

Timeline and Breakdown

30 January 2025 at 6:18 UTC

The Exploiter 0x27defcfa6498f957918f407ed8a58eba2884768c deployed two malicious ERC20 tokens: Token A 0xea55fffae1937e47eba2d854ab7bd29a9cc29170 and Token B 0x341c853c09b3691b434781078572f9d3ab9e3cbb. Subsequently, the attacker created a liquidity pool for these tokens on Uniswap V3 to establish credibility within the Vault system.

Token A creation tx: 0xa0b04f968ddafd059bee3f97c2f1af9b77ef41a4c402486985dd6c424c579291

Attack tx: 0xa05f047ddfdad9126624c4496b5d4a59f961ee7c091e7b4e38cee86f1335736f

30 January 2025 at 6:21 UTC

The Exploiter invoked the Vault's initialization function initialize to create a leveraged trading market named "APE-21", explicitly setting Token A as collateral and Token B as debt tokens.

Attack tx: 0xa05f047ddfdad9126624c4496b5d4a59f961ee7c091e7b4e38cee86f1335736f

The attacker then executed a mint operation through the Vault's mint function (mint). Initially, a transient storage slot 0x01 was correctly used to temporarily store the address of the Uniswap V3 liquidity pool 0xe4c684f944b26b21167ef5a25f52311ab7822831. However, within the same mint function, the Vault contract mistakenly overwrote this slot with the mint amount (95759995883742311247042417521410689).

Leveraging Ethereum's deterministic deployment capability (CREATE2), the attacker deployed a malicious contract precisely at address 0x00000000001271551295307acc16ba1e7e0d4281, matching the overwritten transient storage slot.

The attacker also had pre calculated the final minted value, which set the Token A contract as the caller in the last Transient storage, which called the Vault's callback function (uniswapV3SwapCallback). Due to the transient storage vulnerability, the security check incorrectly verified the Token A and Malicious contract as legitimate, enabling unauthorized token transfers.

January 30 2025 at 6:25 UTC

Finally, the attacker converted the stolen tokens (WBTC and USDC) into WETH and consolidated the assets. These funds were then routed into Railgun, a privacy-enhancing protocol, effectively obfuscating their trail and complicating recovery efforts.

Cohort Analysis

A detailed cohort analysis revealed 49 interactions between the exploiter-associated addresses and the Victim (Vault) contract—all occurring within a single transaction. This level of coordination reflects meticulous pre-planning and execution, leveraging Ethereum’s deterministic behavior and the transient storage vulnerability with surgical precision.

Conclusion

This exploit highlights the urgent need for thorough and repeated security audits, especially when adopting innovative blockchain features such as transient storage. The founder's distress and immediate reaction—offering a $100,000 bounty to the attacker—underscores the significant damage insufficient security practices can inflict on blockchain projects.

Relying on a single audit while handling user funds proved to be a costly mistake for SIR Trading—and a cautionary tale for the entire ecosystem.

Web3 forensics and monitoring platforms like Blockscope are essential in equipping users, businesses, and law enforcement with the tools needed to trace, prevent, and respond to exploits. In the crypto space, security should no longer be optional—projects must take greater accountability and prioritize proactive investment in security from day one.

Investigation by: Tushar Tiwari, Analyst @ Blockscope

For more information, please reach out to us at [email protected]

Disclaimer: Best Effort Investigation

This investigation and its findings represent our best effort based on the information available at the time. However, please be aware of the following limitations:

• The data used in this investigation may contain inaccuracies, omissions, or errors.

• Information sources may be incomplete or subject to change.

• New evidence may emerge that could alter the conclusions.

• Analysis and interpretations are based on current understanding and may evolve.

We have made every reasonable attempt to ensure accuracy, but cannot guarantee that all information is entirely correct or complete. This report should be considered a snapshot of our current knowledge and understanding, subject to revision as new information becomes available.