Thrown together in 22 minutes by Vitalik before an all core developers call, EIP-7702 immediately became part of Ethereum lore, and it’s currently heralded as the the preferred path forward for enabling smart account functionality on EOAs.
This enthusiasm goes beyond discussion: given tooling and testnet support courtesy of the kind people at Ithaca and wevm, folks are hacking on possibilities and only yesterday Ithaca announced their Porto smart account, based on EIP-7702, collaborating with Privy on the demo.
The benefit of this availability is that even out-of-shape smart contract developers can have a go. So I thought I’d take EIP-7702 out for a spin: site, source code.
The first thing you will notice about the Greeter is that this isn’t necessarily a good use of EIP-7702: it allows you to leave a welcoming message in your account. But it does help surface what is actually happening.
Getting into the gritty details, when you click "Activate 7702":
- Your wallet signs an authorization of the Greeter contract implementation address
- Your wallet signs a "setGreeting" message of "Hello, world"
- These are combined into a "type 4" transaction with a
setGreetingfunction call to your wallet's own address, which is passed to the sequencer for processing (7702-enabled transactions are always sponsored by the sequencer on OdysseyTestnet). - When the transaction is processed, your wallet's code is set to the Greeter implementation contract, then the contract call is executed, setting the greeting to "Hello, world".
Your EOA now has code, which points to the Greeter implementation contract, and as a result you can call the setGreeting function. You can scroll down the Greeter page to see that your EOA has data in its storage slots, which changes as you update the greeting (and your EOA also emits logs). That is all new and kind of weird!
You can turn the code bit off, if you revoke your delegation, but even when you do, the data stays in storage. More on that later…
Now if you go to “Batches”, that’s more of a “useful” implementation.
First you'll need to "Create New Wallet". When you click “Drop”, the new wallet is 7702-enabled with a multi calling smart contract, which means that one signed message is enough to call a faucet, mint some FreeTokens, approve FreeTokens to buy BuyableTokens, and then buy BuyableTokens, all in one transaction. Then you can Move them all to another account, again in one transaction. And your transactions are sponsored by the OdysseyTestnet sequencer. Smart accounts!
That all seems pretty simple, but building these examples surfaced some nuances for me.
When your EOA is a smart account, it behaves like a smart account. That means you need a fallback or receive function or your EOA will not be able to receive ETH, for example.
Specifically, it is an upgradeable smart account, so you need to think about upgradeability. The dumb Greeter example demonstrated that storage persists even with revocation, which means that, like upgradeable smart contracts, you need to think about compatibility if your EOA changes its delegation contract. In our examples, turning a Greeter smart account into a Batching smart account leaves the Greeting string where the Batching account nonce is (in the first storage slot). This can lead to some unexpected behaviour, so standards and best practices such as the recently announced Porto will be important.
7702 also changes what is and isn't feasible in Solidity, which can surprise robot assistants - Cursor kept telling me that address(this) couldn’t sign a message, for example, because normally smart contracts don't have a signing key. Another example where LLMs can trip over, on the edge.
Tools and testnets are great, but other folks need to get on board too, from wallets to block explorers to analytics platforms. JSON-RPC wallet signing of authorisations is currently not supported, for example. Block explorers need to be able to surface what’s going on in these new transaction types, and to be able to parse the resulting transactions and state changes. Tools and apps which rely on the existence of code to characterise accounts as EOAs or contracts will no longer be able to do so. And dapp developers will need to make changes to make the most of these new EOA capabilities. I am sure that other things will be broken, or need changing to support the new world.
EIP-7702 delegation is also potentially a new attack vector - one signature in the wrong place could theoretically enable a delegation to a malicious drainer contract. Once again UX and security are often at odds with one another!
Finally, it is interesting to see how this changes what have been inviolable facts on Ethereum. EOAs can now run code. Smart accounts can have their own signing keys. And now some smart accounts can never be truly ownerless (was that private key really lost forever?)
Overall EIP-7702 is definitely a pretty elegant manoeuvre out of Ethereum’s EOA cul-de-sac, but the devil is always in the detail. I learned a bit about what the devil is up to in there, and I hope you did too.
Thanks again to Ithaca for the testnet and wevm for the headstart, and to Austin Griffith for jamming through it with me. And if you are building on EIP-7702 I would love to hear about it at @azacharyf on Twitter.