Kelp freeze thwarts rsETH theft as “Yoink” MEV bot captures $7.7M

An attacker attempted to drain approximately $7.7 million worth of rsETH from an Ethereum Safe wallet by abusing a custom module tied to the wallet. Instead of successfully exiting with the funds, the operation was interrupted when an MEV bot captured the tokens first, according to blockchain security firm Blockaid.

Blockaid said the exploit used a public “keeper” multicall to route a custom Uniswap v4 liquidity module into an attacker-controlled hooked pool. In that setup, aEthrsETH was unwrapped into rsETH—allowing the attacker to try to take custody of the extracted tokens.

Key takeaways

• Blockaid traced the incident to a custom Uniswap v4 liquidity module connected to a Safe wallet.
• The attacker reportedly targeted rsETH holdings worth about $7.73 million, but an MEV bot intercepted the funds.
• On-chain activity indicates the MEV bot transferred rsETH out before the original exploiter could act.
• Kelp, the rsETH protocol, placed a 24-hour pause on the recipient address as a precaution while stating rsETH remains fully backed.
• Minting, withdrawals, and integrations were reported as continuing normally during the investigation.

From Safe module to attacker-controlled liquidity pool

In its report, Blockaid described a two-stage strategy. First, the attacker leveraged a Safe-related “keeper multicall” as a public execution path. Then, through that multicall, the attacker directed a custom Uniswap v4 liquidity module into a hooked pool created by the attacker.

The key mechanics, per Blockaid, were centered on converting aEthrsETH into rsETH inside the attacker’s pool. This effectively created a route for extracting rsETH from the victim wallet using functionality already wired into the Safe.

Blockaid identified the impacted wallet as belonging to an unidentified Safe user and estimated that roughly $7.73 million in rsETH was taken at the time of its initial reporting.

MEV bot “Yoink” front-runs the exploiter

Rather than letting the exploiter obtain control of the extracted rsETH, the transaction appears to have been front-run by an MEV bot named “Yoink.” MEV bots monitor mempool and transaction patterns to capture opportunities when transactions can be reordered for profit or advantage.

Blockaid said Yoink took the rsETH before the original attacker could secure the funds. Etherscan transaction data linked in Blockaid’s update indicates that Yoink transferred about 18.93 ETH—valued at roughly $46,000 at the time—during the same transaction to an address labeled as a “block builder.”

While this does not by itself clarify the bot’s full profit model, the pattern is consistent with MEV-style routing: the bot captures value in the reordered execution and settles or forwards funds through builder-related infrastructure.

Kelp pauses a receiving address; contracts reportedly safe

After the extraction and interception, the rsETH protocol behind Kelp moved to reduce the risk of further token movement from the implicated destination.

Kelp placed the address that received the funds under a 24-hour pause, temporarily preventing the tokens from being transferred. In an update posted on X, Kelp described the step as a precautionary, wallet-level measure only, adding that its own contracts are safe and that rsETH remains fully backed.

Kelp also said minting, withdrawals, and integrations were continuing normally while it worked with security experts to investigate what happened. In its explanation of the likely attack path, Kelp pointed to the custom module attached to the victim’s Safe as the apparent vector, while stating that Kelp’s core contract layer was unaffected.

What this incident signals for Safe and DeFi modularity

This case underscores how “legitimate” DeFi components can become high-risk when they are wired into wallet automation or custom modules. The exploit did not rely on a claimed vulnerability in Kelp’s contracts; instead, it leveraged a custom Uniswap v4 module and the Safe’s ability to execute preconfigured calls via a public multicall mechanism.

For users and teams operating smart-contract wallets, the lesson is less about any single protocol’s implementation and more about how modules are designed, approved, and monitored. When Safe wallets are configured to route assets through complex strategies—especially ones involving liquidity hooks and public execution helpers—attackers may not need to break contract code. They may only need to steer existing pathways into attacker-controlled counterparty logic.

At the same time, the fact that an MEV bot intercepted the extracted rsETH illustrates another dynamic: even when exploitation succeeds in pulling funds into a usable form, automated market mechanisms can reorder outcomes and reduce the attacker’s ability to complete settlement.

For readers tracking recovery and downstream impacts, the most important immediate variable will be the duration and scope of Kelp’s pause and whether the protocol can identify the remaining movement rights or any other affected addresses. Beyond that, attention will likely shift to what developers and auditors recommend for safely handling custom modules, keeper multicalls, and Uniswap v4 hook integrations in production wallet setups.