Vitalik Buterin has recently proposed the EIP-7702, which could potentially be one of the most significant changes in the history of Ethereum. This article will introduce the working principles of the new proposal and everything you need to know to implement it.
Firstly, the EIP-7702 proposal is surprisingly short, which has caused some confusion among people who are unsure of how it works. To understand 7702, we must first understand three other proposals mentioned in it: EIP-4337, EIP-3074, and EIP-5003.
Let’s start with the common goal of all these proposals, which is “account abstraction.” Ethereum’s EOA (Externally Owned Accounts) are problematic as they are risky and have limited functionality. Account abstraction allows users to use smart contracts as accounts to add more functionality and security to address this issue.
EIP-4337 was launched on the mainnet in March 2023, allowing smart contracts to be written like accounts, enabling them to verify and execute transactions. This has improved the user experience significantly. EIP-4337 has gained widespread adoption, mainly led by Polygon, and there has been increased activity from Base in recent months.
The latest innovation related to EIP-4337 comes from the Coinbase ecosystem and Coinbase Smart Wallet, which provides an excellent user experience based on biometric technology. I demonstrated this in a small presentation at ETH Global Sydney last weekend.
However, EIP-4337 has some issues. The main problem is that most EIP-4337 smart contract accounts are controlled by a single EOA signer. This is due to the strange intermediate solution of not being able to “convert” a user’s EOA into a smart contract account. This is mainly because Web3 applications lack native support for connecting to smart contract accounts, and most people still use EOAs through plugins like MetaMask.
This brings us to our next proposal, EIP-3074. This proposal aims to give EOAs more power by allowing them to delegate control of their EOAs to smart contracts. It outlines two new opcodes: AUTH, which allows EOAs to authorize a smart contract to act on their behalf, and AUTHCALL, which allows authorized smart contracts to execute transactions on behalf of EOAs.
A common concern with EIP-3074 is what happens if someone creates a malicious contract and the user delegates to them. Delegating to a malicious contract could result in the user’s wallet being emptied. The solution to this problem is for wallet service providers to not allow users to authorize any contracts. They could maintain a whitelist of smart contracts that users can delegate authorization to and not display any contracts outside of this list.
One key point about delegating with EIP-3074 is that the delegation is not permanent. “An EOA’s single transaction causes the nonce to increment, which invalidates any outstanding authorizations.” Essentially, the delegation becomes invalid after the user makes a new transaction.
Now, let’s move on to EIP-5003. The goal of this proposal is not to give EOAs more power. After all, the purpose of these proposals is to move users from EOAs to smart contract accounts. So why add functionality to EOAs? This leads us to EIP-5003, which adds a new opcode called “AUTHUSURP” to be deployed at the EIP-3074 authorization address.
The difference between EIP-3074 and EIP-5003 is that EIP-3074 is temporary delegation, which can be revoked, while EIP-5003 is a permanent migration from EOA to a smart contract account. One concern with EIP-3074 + EIP-5003 is that it is not very compatible with the current account abstraction scheme through EIP-4337. Some in the Ethereum community are worried that it might create two separate code ecosystems for these two types of account abstractions.
This brings us to Vitalik Buterin’s proposal today, EIP-7702. He proposes to modify EIP-3074 to make it more concise and compatible with EIP-4337, so that we don’t end up with two separate account abstraction ecosystems. EIP-5003 is seen as the next step for permanent migration.
EIP-7702 introduces a new transaction type that accepts both contract_code and signature fields. When the transaction is executed, it sets the contract code of the signer’s account to the provided contract_code. At the end of the transaction, it resets the code to empty. Like EIP-3074, it achieves temporary delegation of EOA to smart contracts. However, EIP-7702 does not introduce new opcodes but defines the functions to be called: AUTH calls “verify” and AUTHCALL calls “execute.”
One of the great things about this proposal is that it is highly compatible with all the account abstraction work done so far for EIP-4337. “The contract code that users need to sign can actually be existing EIP-4337 wallet code.”
Once this change is implemented, existing EOAs can execute any smart contract code. With additional EIPs, EOAs can also permanently upgrade to run specific code. Over time, this could completely change the way we interact with Web3 applications.
