Why EIP-7702 is Not for the Faint of Heart (or Wallet)

As the cosmic clock ticks ever closer to the Ethereum Pectra upgrade, Alchemy’s Will Hennessy finds himself in a delightful tête-à-tête about why EIP-7702 is about as suitable for beginners as a cat is for a swimming competition. 🐱💦

Ethereum developers, in their infinite wisdom (and perhaps a touch of madness), have announced that the much-anticipated Pectra upgrade will launch on April 8. This update promises to introduce new mechanisms that will boost Ethereum’s transaction processing speed, reduce gas fees, and add smart accounts capable of executing multiple transactions simultaneously—because who doesn’t want their wallet to multitask like a caffeinated octopus? 🐙☕

While the update is set to go live on the mainnet in April, it has already been rolled out on Ethereum’s Holesky testnet, which, like a toddler with a new toy, faced some challenges, including issues with transaction finality and unexpected delays in account abstraction functionality. Who knew blockchain could be so temperamental?

Crypto.news had the pleasure of chatting with Will Hennessy, product manager at Alchemy, to explore whether this upgrade comes with hidden threats lurking in the shadows, and why he believes EIP-7702 is about as suitable for newbies as a rocket ship is for a hamster. 🚀🐹

CN: Ethereum eventually wants every wallet to work like a smart contract, and the 2025 Pectra upgrade (EIP-7702) seems to play a big step in that direction. But wouldn’t that update make it easier for bad actors to disguise malicious smart contracts as regular EOAs?

WH: Ah, the age-old question! EIP-7702 doesn’t actually make it easier to disguise malicious contracts. Here’s the scoop:

The delegation mechanism requires explicit user authorization—nothing happens automatically or without user awareness. The EOA owner must actively choose to delegate control to a smart contract through a specific signature. This delegation is permanent until explicitly revoked, much like that embarrassing tattoo you got in college.

What’s crucial to understand is that the EOA’s private key retains full control and can override smart account behavior. This is actually a safety feature—if a user discovers they’ve delegated to a malicious contract, they can always use their EOA’s private key to revoke the delegation. Think of it as a safety net, but one that’s made of very high-quality silk. 🕸️

This is why we don’t recommend EIP-7702 for new users—it’s better for them to start with pure smart accounts that allow for safer key rotation and multi-sig policies that can’t be bypassed. EIP-7702 is most valuable for upgrading existing EOA wallets that already have assets or history, giving them access to smart contract features in a controlled way. Like giving a toddler a toy that requires batteries—better to be prepared!

For wallet providers, we recommend implementing clear security measures:

Visual indicators when users bypass smart account security—like a neon sign saying, “Danger, Will Robinson!”
Automated reputation checks for delegate contracts—because who wants to invite a shady character to the party?
Chain-specific warnings when delegation states differ across networks—like a GPS that actually works.

So, while EIP-7702 adds new capabilities to EOAs, it includes security considerations in its design and maintains user control through explicit authorization and revocation options. The goal isn’t to make it easier to run arbitrary code—it’s to enable existing wallets to access smart contract features safely, like a well-guarded treasure chest. 🏴‍☠️

CN: Could EIP-7702 lead to an increase in phishing scams, given that EOAs can now execute smart contract logic?

WH: While EIP-7702 adds new functionality to EOAs, it doesn’t inherently increase phishing risk. The key point is that executing smart contract logic still requires explicit authorization from the EOA owner. Think of it like adding account recovery to your email—it adds new functionality but doesn’t make your account more vulnerable. In fact, EIP-7702 can help make wallets more secure by enabling better security features like:

Session keys for limited-time authorizations—because who doesn’t love a good time limit?
Social recovery options—like a safety net made of friends.
More sophisticated transaction validation—because we all need a little sophistication in our lives.
The ability to set spending limits and other safety controls—like a budget, but for your digital wallet.

Users maintain full control through their EOA’s private key, which can override or revoke any delegated functionality. This means if a user identifies malicious behavior, they can immediately revoke access. It’s like having a magic wand that says, “Nope!” when things go awry.

That said, wallet providers need to implement proper security measures:

Clear user interfaces showing when smart contract features are being used—because confusion is the enemy of progress.
Strong verification of delegate contracts—like a bouncer at an exclusive club.
Easy-to-understand delegation management—because no one wants to read a manual thicker than a Tolstoy novel.
Clear warnings when users are taking actions that bypass smart account security—like a flashing red light saying, “Stop!”

Should we expect blockchain providers like Alchemy—or even wallets—to step up with protections against these kinds of attacks?

WH: Yes, security is our absolute top priority. Our smart accounts have been thoroughly audited, and we’ve been securing critical infrastructure for the Ethereum ecosystem for over 7 years. We’ll continue to maintain the same rigorous security standards as we support EIP-7702 adoption. Think of us as the knights in shining armor of the blockchain realm.

We’re already helping apps prepare for this transition with EIP-7702 support in Account Kit, our smart wallet toolkit. It’s like giving them a superhero cape for the upcoming battle!

CN: Why has it taken Ethereum so long to bring account abstraction to life?

WH: The journey to account abstraction in Ethereum has been methodical for a good reason. Modifying how accounts work at the protocol level requires extreme care since it affects every user and application on the network. It’s like trying to change the engine of a car while it’s still driving down the highway!

Early attempts at account abstraction proposed more radical changes to Ethereum’s core architecture. These proposals would have required major modifications to the Ethereum Virtual Machine itself, which carried significant technical risk and implementation complexity. Think of it as trying to change the rules of chess while everyone is still playing.

Instead, the ecosystem took a stepwise approach. First came ERC-4337, which enabled smart contract accounts—essentially working around the need for deep protocol changes. This let the community test and refine account abstraction concepts in production, like a dress rehearsal before the big show.

Now with EIP-7702, we’re seeing a more elegant solution that builds on those learnings. Rather than completely restructuring how accounts work, it enables EOAs to delegate capabilities to smart contracts while maintaining backwards compatibility. This preserves the security properties users trust while unlocking new functionality. It’s like upgrading your old flip phone to a smartphone without losing your contacts!

Each step has required extensive testing, security audits, and community consensus. When you’re dealing with a network securing hundreds of billions in value, this measured approach to fundamental change is crucial. The goal has been to expand wallet capabilities without compromising Ethereum’s core security and reliability. It’s like walking a tightrope while juggling flaming torches—definitely not for the faint of heart!

What we’re seeing now isn’t just account abstraction finally arriving—it’s account abstraction done right, informed by years of research, testing, and real-world experience. And that, dear reader, is something worth celebrating! 🎉

2025-02-27 16:10

Read More