Ethereum smart wallet mode panic, unpacked

This is a segment from the 0xResearch newsletter. To read full editions, subscribe.

---

A Solidity developer friend of mine reached out on Signal the other day in a tizzy. “I can’t believe this,” he wrote. “How did Ethereum developers let this happen?”

He was referring to a recent article worrying about Ethereum’s Pectra upgrade — specifically EIP-7702 — and its supposed ability to let hackers “drain wallets with just an offchain signature.” The piece has been bandied about on X/Twitter, it seems, though not by people I follow. Fears were clearly being stoked in some circles that a new transaction type quietly enabled attackers to seize control of wallets without an onchain transaction or even a user’s knowledge.

But like many things in crypto, the reality is both more nuanced — and less dramatic.

Ethereum’s recent Pectra upgrade, activated on May 7, introduced a powerful mechanism that enables externally owned accounts (EOAs) to temporarily act like smart accounts. But the rollout has been accompanied by breathless claims that it exposes users to some insane new risk.

Those headlines are misleading. While EIP-7702 could introduce a new attack surface for phishing, it doesn’t bypass wallet signatures or allow unauthorized access per se. Instead, it signs a special message for the temporary superpowers. But if that message falls into the wrong hands, someone else could take control — as if handing over a private key to your wallet for a single session.

Sounds dangerous, and it can be, but only if a user is tricked into signing a malicious delegation. It’s not a protocol failure, but something for wallet software publishers to take account of.

Security researchers and wallets responded proactively to 7702. For example, alongside support for the feature, Ambire and Trust Wallet released patches or warnings. Wallets that don’t yet support 7702 are not suddenly made insecure. But confusion spread with viral tweets claiming EIP-7702 made hardware wallets “no longer safe,” for example.

Will Hennessy, a product manager at Alchemy, strongly pushed back on that narrative:

“It’s a non-issue for end users,” he told Blockworks. “No wallet supports signing arbitrary delegations, nor is there a wallet RPC for a dapp to request an arbitrary delegation signature.”

He’s right…today. Mainstream wallets like MetaMask and Ledger don’t expose a method for signing EIP-7702 authorization tuples — the term for the one-time-use permission slip, signed by the wallet owner.

But that’s beginning to change. Embedded wallet SDKs — including Alchemy’s own Account Kit — already include a method called signAuthorization that creates valid EIP-7702 signatures. These products can bypass the EIP-1193 standard entirely by bundling their own provider. As wallets begin to natively support smart accounts, this functionality will likely spread.

“The article describes signing a message with a wallet from a malicious website,” Hennessy added, “but it is not possible for any website to request an EIP-7702 delegation signature from an external wallet.”

Keep an eye on this threat vector. Just as existing standards have been exploited in “blind signing” attacks, the same could happen with EIP-7702 if wallet UX isn’t explicit about what the user is delegating and to whom.

TL;DR — the criticism of 7702 as an “auto-drain” threat is exaggerated. There is no magical backdoor, and attackers still need your signature. But the phishing risk is there if wallets don’t clearly show the contract, nonce and scope of a delegation.

So, don’t sign opaque 32-byte hex strings, people. Favor wallets that flag EIP-7702 requests and simulate the delegated contract. Pectra opens the door to powerful smart account features, but remember, with great power…

---

Get the news in your inbox. Explore Blockworks newsletters:

• The Breakdown: Decoding crypto and the markets. Daily.
• 0xResearch: Alpha in your inbox. Think like an analyst.