EIP-7702 Explained: How it Works and Everything You Need to Know

TL;DR

• EIP-7702 is a proposal co-authored by Vitalik Buterin, proposing a new transaction type that adds a contract_code field for the corresponding EOA. 
• It was created in response to the heavily debated EIP-3074, which allows externally owned accounts (EOAs) to authorize smart contracts to make transaction calls on its behalf and revoke the authorization whenever they wish. This conflicts with the Account Abstraction roadmap where all Ethereum wallets should eventually be smart contract accounts. With EIP-3074, the users can be divided as to whether to permanently move to smart contract wallets or just keep using their EOAs with EIP-3074. 
• To solve the problem, EIP-7702 enables EOAs to temporarily set a smart contract code for the wallet that is executable only during the transaction.
• This allows EOAs to enjoy account abstraction features like gas sponsorships, batch transactions, and custom logic for executing transactions without having to delegate the transaction control to smart contracts or completely leaving the EOA to migrate to a smart account.

The Account Abstraction (AA) roadmap is a vision for Ethereum's future development that aims to unify the treatment of different types of accounts within the Ethereum ecosystem. Currently, Ethereum distinguishes between two main types of accounts: externally owned accounts (EOAs) and smart contract accounts. EOAs are controlled by private keys and can hold Ether (ETH) but cannot execute code. Contract accounts, on the other hand, can execute code when triggered by a transaction signed by an EOA.

The endgame for account abstraction is eventually eliminating this distinction by allowing all accounts to execute code. This means that EOAs, traditionally used for simple transactions, will either migrate to becoming a smart account, delegate their transaction control to a smart contract, or somehow gain the ability to execute smart contract code just like native smart accounts. This transition is not easy, accounting for the multitude of nuances of the EVM architecture.

Previous Proposals for Adapting EOAs to Account Abstraction

Various proposals have been made to solve the account abstraction problem for EOAs. One of them is EIP-5003 which aims to permanently migrate wallets to a smart contract account using a new opcode, AUTHUSURP. However, the permanence of EIP-5003 can make users hesitate to migrate, as can some unresolved issues like the interoperability of the wallet.

Another proposal known as EIP-3074 is providing a way for EOAs to temporarily delegate their transactions to a smart account through the opcodes AUTH and AUTHCALL. This practically creates a middle way for EOA users who are keen on trying out AA features without overcommitting to the contract they want to use. 

EIP-3074 has been tentatively added to the next upgrade, but it has been debated by the community because some aspects of it don’t align with the bigger account abstraction plan. For instance, in a world where all wallets are already smart contracts, the AUTH and AUTHCALL opcodes will be a technical burden that eventually no one uses yet all chains and applications building on top of Ethereum will have to keep supporting.

Another problem with EIP-3074 is over-enshrining EOA wallets. Because it allows people to easily authorize a smart contract to call transactions on its behalf and revoke the authorization for the contract whenever desired, its misalignment with ERC–4337 raises concerns from the community.

The Birth of EIP-7702

To resolve this conflict of alignment with the broader account abstraction plan, Vitalik formulated a quick resolution that creates a new transaction type instead of introducing new opcodes in the EVM.

EIP-7702 allows EOAs to temporarily function as a smart contract account by adding a contract_code field along with the other details of the transaction. So the smart contract code is set for the EOA only within the context of the transaction. In the background, you’ll have an array that consists of two important details:

1. The contract_code that is added to the signing address before the transaction begins and removed after the transaction ends
2. The signature where the contract_code will be deployed temporarily

A sample transaction payload in EIP-7702 would look like:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

By adding contract_code to the signature address, an EOA can be associated with the contract. The client can loop over this array to find the EOA address for each signature. Then, it sets the code of this EOA to the provided contract code. At the end of the transaction, the code of the EOAs is simply removed. This kind of transaction also does not require the EOA to be the tx.origin, allowing for seamless integration with ERC-4337.

Advantages of EIP-7702

1. Backward and Forward Compatible with ERC-4337

Compared to the previous 3074, EIP-7702 is more compatible with the account abstraction roadmap and infrastructure in many ways. For instance, there is no need for invoker contracts that may create fragmentation in the ecosystem. The smart contract, instead of being called by invoker contracts, is directly called by the EOAs without any need for authorization or a different address to create the userOp. 

7702 also accounts for the future of ERC-4337 where all EOAs will eventually be smart wallets. It is simple and possible to add functionality for EOAs to be allowed to permanently migrate into smart accounts without breaking any of the 7702 existing code.

2. Easier for dApps to Adopt

Applications that are already using an ERC-4337 infrastructure may consider 3074 to give EOAs the functionality of smart accounts. However, doing so will introduce more complexity into the system.  

Invokers in 3074 can be used by multiple EOAs, and this property of being multi-tenant adds complexity to using the same UserOps from different EOAs. Workarounds are done in order to do it, like creating a nonce manager and putting the EOA addresses into the 2D nonce of the Op. 

But in 7702, the sender of the UserOp can simply be the EOA itself, not needing any workaround with UserOp and keeping the Op structure consistent across EOAs and smart wallets. The UserOp is built on the assumption that the Op comes from the same EOA, and 7702 is aligned with this assumption.

3. Less security risk

Because the contract_code is automatically removed after the execution of the transaction, then unauthorized transactions will be an impossibility in 7702. 

Another issue is when 3074 is used with account abstraction infrastructure, it causes complexity that may lead to vulnerabilities. Because 3074 is multi-tenant, calling AUTH requires accessing the EOA’s nonce and there’s no clear 1:1 association between the EOA and its invoker. You can therefore invalidate multiple UserOps sharing a single authorizer by incrementing the authorizer’s nonce. This won’t happen with EIP-7702 however, because the transaction is associated directly with the EOA rather than the invoker contract.

ERC-3074 transactions can open up new strategies for MEV sandwich attacks. For instance, one can only take out a flashloan for arbitrage because the limit of flashloans is that you have to pay it within the same transaction. But with 3074, you can frontrun a multicall before it gets sent to the invoker contract by extracting the commitment and signature from it and placing it on your own transaction. In EIP-7702, there is no AUTH call to be frontrun because the transaction is sent directly to the application contract.

Disadvantages of EIP-7702

1. New and lacks clarity

Because 7702 is very new, we will likely not see it in the next Ethereum upgrade. The proposal will have to undergo a process of review before we can say that it is indeed secure to implement for wider adoption.

2. Revocations

Unlike 3074, where the user can easily revoke the authorization of the contract, EIP-7702 wallets might not have as much control over revoking the contract_code associated with it. The smart contract code, therefore, needs to be trusted, and protocols don’t have any way to let users revert the smart contracts if any malicious code is detected. There are many ways to allow for this functionality in EIP-7702, but as of now, the proposal doesn’t have any details on revoking the contract code.

3. Chain Agnostic Signatures

Finally, the signature in the proposal is automatically assumed to be reusable in other chains. This can be an advantage, but it may be too inflexible if the user wants to have different implementations on different chains. 

In conclusion, EIP-7702 emerges as a promising solution to the evolving landscape of Ethereum's account abstraction. Unlike its predecessors, this proposal allows EOAs to seamlessly embrace smart contract functionalities within the transaction scope, not only addressing the immediate concerns raised by EIP-3074 but also aligning harmoniously with the overarching vision outlined in ERC-4337. 

However, as with any novel concept, there are areas warranting further scrutiny, such as storage, revocability, and cross-chain flexibility. Nonetheless, EIP-7702 represents a significant step forward in Ethereum's journey towards a more inclusive and versatile ecosystem, poised to empower users and developers alike in shaping the decentralized future.

Found EIP-7702 interesting? Check out our other posts on account abstraction:

What is EIP-3074: A Comprehensive Guide

Gas Abstraction and Creating Multichain AA Wallets

An ultimate guide to Web3 Wallets: Externally Owned Account and Smart Contract Wallet