The Ghost in the V4 Hook: How a $7.7 Million 'Safe' Wallet Was Drained Without a Single Broken Key

The user did everything right. Or so they thought.

They held their assets in a Safe multisig, the gold standard of self-custody. They deployed a custom Uniswap V4 LP module, the cutting edge of DeFi automation. They parked funds in Aave, the blue-chip lending protocol. Every layer was a fortress. Every key was cold. Every transaction required multiple signatures.

And yet, on a quiet Tuesday morning in Lisbon—where I was sipping my third espresso, scrolling through on-chain alerts—$7.73 million in rsETH vanished from that wallet. No private key was compromised. No seed phrase was phished. No hardware wallet was lost.

The Safe was safe. The user was simply... outmaneuvered.

I've been tracking these 'combinatorial exploits' for months now. They're the new frontier of DeFi crime—not brute-force attacks on protocol code, but surgical strikes on the seams between protocols. The gaps that appear when modularity becomes complexity, and complexity becomes a weapon.

This is the story of how a public Keeper Multicall, an attacker-controlled HookPool, and a custom LP module created a perfect storm. And why the headline 'Uniswap V4 Hook Used in Attack' is dangerously misleading.

The Context: When Lego Bricks Become Landmines

To understand what happened, you need to understand the architecture of modern DeFi automation.

Safe wallets aren't just multisigs anymore. They're programmable vaults. Users can attach 'modules'—external contracts that execute predefined actions. Need to auto-compound your yield? Attach a module. Want to rebalance your Uniswap positions? Attach a module. The Safe executes the logic; you just sign off on the permissions.

This is powerful. It's also a loaded gun pointed at your own foot if you're not careful.

Uniswap V4, launched in 2025, took this modularity further. 'Hooks' are contracts that execute before or after swaps, enabling dynamic fees, limit orders, custom oracles—essentially turning the DEX into programmable Lego. Brilliant for developers. A nightmare for security auditors trying to map every possible interaction.

Now add 'Keepers'—automated bots that execute strategies on behalf of users. A Keeper Multicall is a function that batches multiple actions into a single transaction. Efficient. Gas-saving. And in this case, publicly callable by anyone.

Here's the critical detail that most reports are glossing over: the attack didn't exploit a bug in Uniswap V4. It exploited a user's assumption that a public function was private.

Based on my audit experience, I've seen this pattern before. Developers often assume that because a function isn't advertised, it won't be found. That's like hiding your house key under the doormat and assuming burglars don't check doormats.

The attack chain, reconstructed from on-chain data, looks like this:

1. The user deployed a custom Uniswap V4 LP module within their Safe. This module was designed to interact with a specific Keeper Multicall for automated rebalancing.
2. The Keeper Multicall was publicly accessible—no whitelist, no access control, no private mempool.
3. An attacker scanned for Safes with this module configuration. They found one.
4. The attacker created a malicious HookPool—a fake Uniswap V4 pool controlled entirely by them.
5. By calling the public Keeper Multicall, the attacker triggered the user's LP module. The module, following its programmed logic, redirected funds to interact with the attacker's HookPool.
6. The malicious Hook executed a reverse operation: it unwrapped the user's aEthrsETH (Aave's interest-bearing rsETH token) back into raw rsETH and transferred it to the attacker.
7. Yoink MEV, an arbitrage bot, extracted the assets in the same block—either as a willing accomplice or an opportunistic vulture.

The entire operation took less than 12 seconds.

The Core Insight: This Wasn't a Hack. It Was a Robbery.

Let me be blunt: the biggest risk in DeFi today isn't protocol vulnerabilities. It's user-assembled automation stacks with no security review and no access controls.

We've spent years auditing smart contracts. We've built tools to detect reentrancy attacks, flash loan exploits, oracle manipulations. But we haven't solved the problem of users cobbling together third-party modules and assuming they're safe.

This attack didn't require a zero-day exploit. It didn't require breaking cryptography. It required finding a wallet where the owner had configured a public execution path and forgotten to lock it down.

Think about that for a moment. The attacker didn't need to be brilliant. They needed to be patient.

The rsETH angle is also worth examining. Kelp DAO's liquid restaking token has been one of the more successful LRTs in the market. Its value proposition is simple: stake ETH, get rsETH, use rsETH in DeFi while still earning staking rewards. Beautiful in theory. Complicated in practice.

When you deposit rsETH into Aave, you receive aEthrsETH. This is a claim token—proof that you deposited. Normally, you can't extract the underlying rsETH without going through Aave's withdrawal process. But if a malicous module has approval to interact with your aTokens, it can potentially bypass those safeguards.

The Contrarian Angle: Why Uniswap V4 Is the Victim Here, Not the Villain

I need to push back hard on the emerging narrative that this is a 'Uniswap V4 problem.'

It's not.

Uniswap V4's Hook architecture is neutral. It's a tool. A hammer can build a house or break a window. The hammer isn't at fault.

The attack used V4, but it didn't exploit V4. The malicious HookPool was created by the attacker. The vulnerable module was created by the user (or a third-party they trusted). The public Keeper Multicall was misconfigured.

If we blame Uniswap V4 for this, we might as well blame Ethereum for having a blockchain.

What's actually happening is a collision between two competing philosophies in DeFi:

Philosophy 1: Maximize Composability. Every protocol should be a Lego brick. Users should be free to combine them however they want. Innovation comes from permissionless experimentation.

Philosophy 2: Minimize Attack Surface. Every integration is a potential vulnerability. Permissions should be explicit. Defaults should be restrictive. Complexity is the enemy.

Uniswap V4 embodies Philosophy 1. Safe embodies Philosophy 1. Aave embodies Philosophy 1. And this user got wrecked because they followed the ethos the entire industry preaches.

Here's the uncomfortable truth: the 'modular DeFi' narrative that VCs love and developers celebrate is creating a security nightmare that nobody is pricing in.

When you combine protocols, you don't just add their functionalities. You multiply their attack surfaces. A Safe module that interacts with a Uniswap V4 Hook that executes through a Keeper Multicall that touches Aave—that's four layers of trust assumptions, all of which must hold simultaneously.

One weak link, and the whole chain collapses.

And the dirty secret? Most users have no idea what modules are attached to their Safe. They don't audit the hooks they interact with. They don't check if their Keeper is using a public or private mempool.

We've created a system where the barrier to entry is low, but the barrier to safety is impossibly high.

The Takeaway: What Comes Next

This attack is a warning shot.

The attacker demonstrated a repeatable methodology. Scan for misconfigured Safes. Identify public Keeper functions. Create malicious hooks. Extract value via MEV. The barrier to replicating this is low—no exotic exploit needed, just patience and automation.

I expect we'll see more of these. Not because Uniswap V4 is insecure, but because the industry's obsession with composability has outpaced its commitment to security education.

Here's what I'm watching:

First, the rsETH depeg risk. If the stolen funds hit the market, we might see temporary selling pressure. But 773 million... sorry, $7.73 million—is a rounding error against rsETH's total supply. The real risk is narrative: if this triggers a broader 'LRT composability risk' panic, we could see capital rotation out of restaking protocols.

Second, the Keeper architecture debate. The developers of Keeper Multicall systems need to answer a simple question: why are callable execution functions public by default? This should be opt-in, not opt-out.

Third, the Safe module ecosystem. If this LP module was a third-party tool used by multiple users, we could see more victims emerge. I'm monitoring GitHub repos and deployment patterns to see if this was a one-off or a template.

And finally, the hardest question: does DeFi need a 'modular safety standard'? A rating system for modules? A registry of audited hooks?

These solutions sound bureaucratic and centralized—exactly what DeFi was built to avoid. But the alternative is a landscape where every composable integration is a potential crime scene.

The fork in the road where code met chaos and won is becoming familiar. This attack is a case study in how permissionless innovation creates permissionless exploitation.

The user did everything the industry told them to do. They self-custodied. They used a multisig. They deployed on leading protocols.

And they still lost $7.73 million.

If that doesn't force us to rethink what 'safe' actually means in DeFi, I don't know what will.

The next victim is already being scanned.

Will we be ready?