An attempted extraction of roughly $7.7 million worth of rsETH from an Ethereum Safe was disrupted after an MEV bot intercepted the transfer. Blockchain security firm Blockaid says the incident began with a malicious custom module attached to the victim wallet, which redirected liquidity into a setup designed to unwrap into rsETH.
According to Blockaid, about $7.73 million in rsETH had been compromised when it reported the attack. However, a separate automated actor captured the tokens first, and the receiving address was then placed under a short 24-hour pause by the rsETH protocol’s operator, Kelp.
Key takeaways
- Blockaid attributes the initial loss to a custom module connected to an Ethereum Safe wallet that was used to route tokens into a malicious Uniswap v4 hooked pool.
- An MEV bot (“Yoink”) front-ran the exploiter and obtained the rsETH before the attacker could control the funds.
- Kelp responded with a 24-hour pause at the receiving address level, while stating rsETH remains fully backed and its core contracts were not impacted.
- Minting, withdrawals, and integrations reportedly continued normally during the investigation.
How the Safe-to-rsETH extraction attempt worked
In its report, Blockaid described an exploitation path that leveraged Ethereum Safe’s module system. The attacker used a public “keeper multicall” to invoke a custom Uniswap v4 liquidity module associated with the victim Safe, steering funds into an attacker-created liquidity environment.
That attacker-controlled pool was configured so that aEthrsETH could be unwrapped into rsETH, effectively converting the routed position into the token the attacker intended to extract. Blockaid identified the affected wallet as a Safe belonging to an unidentified user, and said rsETH losses were on the order of $7.73 million at the time of its initial update.
Blockaid’s post also links the broader incident to a specific on-chain transaction on Etherscan, where the follow-on movement of assets showed how the attempted outflow unfolded.
The MEV bot that changed the outcome
Rather than letting the original exploiter take custody of the rsETH, an MEV bot known as Yoink stepped in first. As described in Blockaid’s account, Yoink monitors blockchain transactions for profitable opportunities, and in this case front-ran the step needed to capture control of the tokens.
Blockaid pointed to Etherscan transaction data showing Yoink transferring approximately 18.93 ETH—roughly $46,000 at the time of the observed conversion—to an address labeled as a “block builder” within the same transaction. While the figures relate to the bot’s subsequent transfer rather than the initial rsETH amount, they illustrate that the MEV opportunity was executed quickly after the exploit transaction entered the mempool.
In practical terms, MEV front-running did not “prevent” the exploit attempt from being constructed; it instead redirected the settlement outcome by capturing the assets before the attacker could complete its intended withdrawal path.
Kelp’s response: a targeted pause, not a protocol shutdown
After the MEV bot intercepted the tokens, Kelp—described as the protocol behind rsETH—placed the address that received the funds under a 24-hour pause. The move was aimed at temporarily preventing transfers from that destination while security experts investigated.
Kelp said the measure was a precaution at the wallet/address level and emphasized that the protocol’s own contracts were not the affected component. In a statement posted on X, Kelp characterized the pause as “a precautionary, wallet-level measure only,” adding that rsETH “remains fully backed.”
Importantly for holders, Kelp also indicated operational continuity: minting, withdrawals, and integrations were continuing normally as the investigation proceeded. The protocol’s messaging suggests that any risk exposure was contained to the exploited Safe/module pathway rather than a systemic contract vulnerability.
What remains uncertain—and what investors should watch
Based on Blockaid’s description and Kelp’s response, the incident centers on an attacker leveraging a custom module connected to a specific Safe, while Kelp asserts its core contracts were not compromised. Even with that reassurance, the episode underscores how Safe module permissions can be a critical control surface: if a malicious module is enabled or if the wallet is tricked into executing a malicious multicall, assets can be routed into nonstandard flows.
With Kelp’s 24-hour pause window now the immediate timeline focal point, the next questions are whether the paused address can be safely recovered, whether further addresses or transactions are linked to the same exploit chain, and whether similar module-based patterns emerge elsewhere. Readers tracking rsETH should also watch for updates from Kelp and security researchers on post-incident analysis and any guidance aimed at Safe/module operators.
Be the first to comment