# SIR Protocol Exploit: Analyzing the Transient Storage Vulnerability

A view of addresses associated in SIR exploit.

## Summary [On March 30, 2025, the SIR Trading protocol, an Ethereum-based leveraged trading protocol, was exploited](https://x.com/leveragesir/status/1906320010210902298), 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**](https://x.com/leveragesir) **(Synthetics Implemented Right)** is a leveraged trading platform built on Ethereum that [launched on February 20, 2025](https://x.com/leveragesir/status/1892712271110975554). The protocol allows users to mint leveraged tokens backed by collateral, interacting primarily with [Uniswap V3](https://blog.uniswap.org/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 ](https://github.com/Egis-Security/audits/blob/main/reports/SIR-Trading.pdf)before the exploit. ### Initial Reporting and Founder Reaction The exploit was first flagged on X (formerly Twitter) by Web3 security firms such as [TenArmorAlert](https://x.com/TenArmorAlert/status/1906268185046745262) and [Decurity](https://x.com/DecurityHQ/status/1906270316935942350), who identified abnormal activity and began publicly analyzing the situation. Shortly after, the founder of SIR Trading, [**Xatarrer**, acknowledged the exploit ](https://x.com/Xatarrer/status/1906272345490407763)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 ](https://x.com/leveragesir/status/1906700496607248812)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](https://slowmist.medium.com/fatal-residue-an-on-chain-heist-triggered-by-transient-storage-10909e4a255a) 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**](https://medium.com/@organmo/demystifying-eip-1153-transient-storage-faeabbadd0d)**,** 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.

UniswapV3 pool created by the exploiter is stored in transient storage

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.

The flowchart shows a high-level view of how the exploiter injected the vanity address using Create2 opcode, which is **used** `uniswapV3SwapCallback` to bypass pool verification in the Vault (Victim Contract) via transient storage manipulation. This enabled the minting of tokens and granted Token A contract, which was the full transactional control during the exploit.

Final minted value being set by Token A contract for the final caller check of transient storage.

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.

Tracer 1 visualizes the complete exploit path, including all key transactions and the nodes (addresses and contracts) involved in executing the attack.

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.

Tracer 2 illustrates the post-exploit flow, showing how the attacker swapped USDC and WBTC into WETH before depositing the consolidated funds into Railgun for obfuscation.

## 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`

Decoded trace call showing Vault initialization taken place

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`).

Transaction log showing Mint function being called by Exploiter on Vault

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

Trace call shows Exploiter deploying Malicious contract

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.

uniswapV3SwapCallBack function is being called, and Malicious contract, which is being called by Token A contract passes all security checks due to transient storage vulnerability

USDC being transferred to the main exploiter wallet

Trace call shows using uniswapV3CallBack function, Exploiter drained USDC, wBTC and wETH.

### 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.

Token Transfer from Transcation Decoder shows Exploiter used Odos and ParaSwap to convert wBTC and USDC into ETH

## 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.

Cohort Analysis of the Victim and Exploiter Addresses

### 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.

On-chain message sent by SIR to Exploiter. **Tx. hash: `0x0ffcbb86700e0ebb5ee0c3fd46b81c943a5027cc68738cbb17d364f893f31018`**

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**](https://www.blockscope.co/) 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**](https://in.linkedin.com/in/tushar-tiwari-1380271b7)**,** Analyst @ [**Blockscope**](https://www.blockscope.co/) For more information, please reach out to us at ****

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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://research.blockscope.co/sir-protocol-exploit/sir-protocol-exploit-analyzing-the-transient-storage-vulnerability.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.