Decoding: Vitalik’s EIP-7702
There’s been a lot of hot discussion around Vitalik Buterin et al.’s EIP-7702. What’s it all about?
Understanding the Foundations
First, let’s see how we got here. To do that, we need to understand the basics of three other proposals that EIP-7702 builds on:
All of these proposals have the same goal in mind: Account Abstraction
What is Account Abstraction?
It’s a major upgrade to how Ethereum wallets work. Before, you had “Externally Owned Accounts” (EOAs) — basic user accounts with basic functionality managed by a private key.
But EOAs can’t do much and they are at risk of a single point of failure: the private key. Account abstraction solves this by allowing you to use smart contracts to manage wallet functions, enabling myriad possible feature enhancements for wallets.
For example, take wallet security. With EOAs, wallet security is singularly focused on securing the private key. Smart wallets open the door to enabling multisig wallets, social recovery mechanisms, and customizable rules like transaction limits, time-locked transactions, and whitelisting.
Adoption and Challenges
ERC-4337 went live on the mainnet in March 2023. Since then, ~4.3 million smart wallets have been created, primarily on Polygon.
While the initial adoption looks promising, if we remove Polygon, we’re left with almost nothing. Why aren’t we seeing more adoption on other chains?
The issue stems from the fact that:
- There’s no way to “convert” an EOA to a smart wallet.
- There’s no native support for dApps to connect to smart wallets.
- As such, it’s still more practical for people to keep using EOAs through wallet extensions like MetaMask today.
Proposed Solutions: EIP-3074 and ERC-5003
Enter EIP-3074
EIP-3074 tries to solve the issue by giving an EOA the ability to temporarily delegate control over it to a smart wallet. But, to do this, it introduces new opcodes that authorize smart contracts to perform operations on behalf of the EOA.
The result is that transactions executed by the authorized smart wallet come from your existing EOA, not a brand-new contract that doesn’t have your assets and account history. It also means you could effectively convert your EOA into a smart wallet, temporarily.
But it also means that EOAs would have the power to delegate full control to smart contracts. What if users accidentally delegate to a malicious smart contract and lose everything? It would be like handing over your private keys to the creator of the smart contract.
The other issue is that 3074 only allows temporarily delegation to a smart contract. After a single transaction, the delegation authorization is no longer valid. In other words, the EOA is just an EOA again after a single transaction.
But the goal is to migrate users permanently from EOAs to smart wallets.
Enter ERC-5003
5003 introduces another new opcode that allows for the revocation of the private key associated with the EOA authorizing smart contract control under 3074. 5003 eliminates the dependency on the original private key and therefore allows an EOA to be “fully” converted into a smart wallet. It means people can transition their existing EOAs to smart wallets without needing to abandon those accounts or transfer their assets.
The main issue with 3074 + 5003 is that they aren’t very compatible with ERC-4337 and all the account abstraction work that has been built on it so far. Some of the Ethereum community is concerned about the development of two account abstraction ecosystems.
Vitalik et al. (2024): EIP-7702
That brings us to the hot topic of Vitalik’s contribution: EIP-7702
In short, EIP-7702 makes 3074 leaner and compatible with 4337. This means less likelihood of dividing the account abstraction ecosystem, as well as better performance and lower gas costs.
How does it do this?
7702 introduces a new transaction type that accepts contract code and a signature field.
At the start of the transaction, the contract code of the signer is set to some contract code that could literally be existing ERC-4337 code. At the end of the transaction, the contract code field is set back to empty.
The elegance of this solution is that it achieves the same temporary conversion of EOA to smart wallet that 3074 does, without requiring new opcodes (note: no hard fork). Then, to achieve the permanent conversion from EOA to smart wallet that 5003 achieves, “just add a flag to not set the code back to empty at the end.”
Long story short, EIP-7702 proposes a lean solution to smart wallet migration that can both avoid a hard fork and keep the existing 4337-based account abstraction ecosystem unified.
Learn more about Inception Capital at our website & by following us on X @_inceptioncap
Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice, or investment recommendations. This post reflects the current opinions of the authors and does not necessarily reflect the opinions of Inception Capital, its affiliates, or individuals associated with Inception Capital. The opinions reflected herein are subject to change without being updated.
