Into the future with EIP-7702 — Part-2

8 min readSep 23, 2024

Disclaimer: This article aims to provides technical deep dive and future scope of EIP-7702 which was recently proposed by Vitalik Buterin & co-authors of EIP-3074 on 7th May 2024.
To catch up on previous developments for this EIP, check out the part-1 of this series.
Brief knowledge regarding ERC-4337(Account Abstraction/ Smart Contract Wallets), EIP-7579 & EIP-6900 will be helpful.
This article is intended to present the latest enhancements regarding this EIP and Zyfi’s point of view on it.

Quick Recap

Currently, existing EOAs on Ethereum lacks vast functionalities that can improve user experience compared to Smart Account(Smart Contract Wallets) like gas sponsorship, transaction batching, privilege de-escalations etc.

EIP-7702 introduces a new transaction type that allows EOA to have code and behave as smart contracts.

EIP-7702 has been updated quite a lot since the last article. After multiple breakout meetings, the specs for this EIP are finalised which is considered to be the greatest upgrade for EOAs on EVM.

The most game-changing part about the upgrade is that EOA can forever upgrade to smart account in a single signature.

Earlier version:
“Set EOA account code for one transaction”

EIP-7702 is now live on pectra-devnet-3 and soon to be rolled out in the first package of Pectra Hardfork around Feb,2025

EIP-7702 Signature and Transaction

New version of this EIP:
“Set EOA account code and let the code persists until next 7702 transaction.”

Signature:

An EIP-7702 signature requires 4 fields as per below:

EIP-7702 type signature.

(v,r,s) = sign(keccak(MAGIC || rlp([chain_id, address, nonce]))

MAGIC --> TBD. Defines that it's a 7702 type signature.
chain_id --> Either 0 or current_chain_id. If 0, then signature valid for all chain
address --> Smart contract with implementation code.
nonce --> Current valid nonce of the EOA.

The address is the deployed smart account address which the EOA will point to for code delegation. During execution the code will be loaded from this address .
Once the transaction passes, the EOA’s account code is upgraded with something like 0xef0100+{address}. More details on 0xef opcode here.

Interesting thing to note here is that chain_id is allowed to be 0. If chain_id = 0 , it allows signature to be replayed across different chains over same address and same nonce.
This allows new EOAs to upgrade to smart account through-out all EVM-chains in just one signature.

How it works?

EOA signs the above 7702 signature.
Either through relayer or itself sends 7702 transaction as below.
EOA’s code is updated with delegation to the code on the signed address

Transaction:

EIP-7702 transaction has an array called authorization_list that allows to send multiple 7702 signatures in one transaction. And the entire transaction can be broadcasted by a completely different EOA.

Transaction type : 0x04
[
chain_id,
nonce, 
max_priority_fee_per_gas,
max_fee_per_gas, gas_limit, 
destination, 
value, 
data, 
access_list, 
authorization_list, // <== EIP-7702 type signatures
signature_y_parity, 
signature_r, 
signature_s
])

                      // Array of 7702 signature and data
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Thus, multiple EOAs can be converted to smart accounts in one transaction. Only 7702 type signature is required from each EOAs.
No transaction is required from EOA in order to upgrade to smart accounts.
For eg: A relayer service can get 7702 signature and data of 10 EOAs and convert them all smart account in 1 transaction!

The code persists!

In the earlier version of this EIP, an EOA can send a 7702 transaction or signature that converts the EOA into a smart account -> moves forward with the rest of the transaction -> reverts back to EOA. This means EOA’s smart account code do not persists at the end of the transaction.

In this new version of this EIP, once the EOA sends 7702 type transaction or signature, it will be converted to a smart account and the code persists until another 7702 type transaction!

A new form of upgradability:

On EVM, once the code is set to an address, it cannot be changed(unless using selfDestruct and create in same transaction).

With this EIP, EOAs will be able to update their code with another implementation with a single 7702 type transaction.

To upgrade, EOA is required to submit another 7702 type transaction or signature(which will sent in 7702 type transaction through relayer)

Revocability

If an EOA, by mistake signs a EIP-7702 type transaction that could be faulty, then it needs to make another EIP-7702 type transaction to update the code and/or revoke the validity of the signature as it is dependent on the nonce .

Ideally, wallets(Metamask, WalletConnect) won’t allow such 7702 type of transactions. They may allow only one time during initialisation. Thus, safe-gaurding their users to some extend.

It will be interesting to see how wallets manage EIP-7702 requests especially due to the threat of malicious phishing links.

Although, yes, a malicious EIP-7702 signature that delegates to a malicious implementation can drain all your funds in one transaction. Hence, wallets may not allow random Dapps to ask for EIP-7702 type signatures to the users at.

Note: Worth to note, modular smart accounts(7579/6900) can evolve in future in such a way that EOA’s don’t feel the necessity to upgrade at all.

Storage Collision?

Now, that an account is allowed upgrade to it’s code and update implementation address, won’t there be a possibility of storage collision between implementations? Especially with smart account wallet implementations?

Yes, the possibility for storage collision increases when shifting from one code implementation to another implementation. In order to solve the issue of storage collision, EIP-7201 — Namespaced Storage Layout

EIP-7201 in post-EIP-7702

According to this EIP, each smart contract implementation should store the data on a particular custom slot that is created through on a particular hash instead of linear slots.

struct MainStorage {
        uint256 x;
        uint256 y;
    }

    // keccak256(abi.encode(uint256(keccak256("example.main")) - 1)) & ~bytes32(uint256(0xff));
    bytes32 private constant MAIN_STORAGE_LOCATION =
        0x183a6125c38840424c4a85fa12bab2ab606c4b6d0e7cc73c0c06ba5300eab500;
    function _getMainStorage() private pure returns (MainStorage storage $) {
        assembly {
            $.slot := MAIN_STORAGE_LOCATION
        }
    }

Thus, in a post EIP-7702 world, smart account implementations will follow EIP-7201 type similar storage layout to avoid storage collision in future.
Many of the current smart wallet implementation are already following such standard.

Interesting research question:
How much storage data will increase for the entire network if EOA’s kept shifting from one wallet implementation to another?

EOA can act as both EOA & Smart Account:

Once converted to smart account, EOA functionality won’t be affected. Meaning, EOA will still be able to initialise normal transactions.

Private key/seed phrases do not become IRRELEVANT!

Instead, one needs to be extra careful while managing private key. A leaked private key would be able to upgrade to a malicious smart account and drain funds in one transaction across chains.

Batching, Sponsorship & Privilege De-escalations

Once, an EOA is converted to smart account, it can perform all types of smart contract functionality.
Especially, with EIP-7579/EIP-6900 type of modular smart accounts, multiple modules like multi-call batching, daily spend limit can be installed/uninstalled at any time.

From Dapps’ point of view:

Once an EOA is converted to smart account, it can still initiate the transaction, thank to seed phrases.
As a Dapp, you would not need to worry whether the EOA is a smart account or not. All functionalities for EOA shall work in your frontend. Wallets like Metamask shall perform normally.
If the Dapp wants to extend functionality for smart account like batching and sponsorship, it may require to shift to ERC-4337 specific UserOps.
No need for user to deploy App specific smart accounts as the current UX scenario for AA.
Use of tx.origin==msg.sender to ensure msg.sender is an EOA becomes obsolete in smart contract. Dapps might need to upgrade their smart contract in this case.
As a Dapp, you would not be able to send a 7702 signature request to the wallet like Metamask etc. due to wallets trying to protect their users.

From Users’ point of view:

Seed phrase are not going anywhere. If a user has converted the EOA into smart account do not mean that seed phrase/private key are no longer required.
If your seed phrases/private key gets leaked, your EOA is at risk irrespective of whether it’s converted to smart account or not.
As a user, you will have best of both worlds. Normal EOA functionality and smart account functionality, you will still be able to perform normal transaction through metamask.
Super easy account abstraction UX. No need to deploy accounts for each Dapp. One smart account for all.

From Zyfi’s point of view:

As a paymaster provider for major Dapps on ZKsync and other elastic chains, Zyfi is well-positioned to advance these improvements across the entire EVM ecosystem. Core functions like batching, sponsorship logic, and paying with any token as gas are core part of Zyfi’s mission.
EIP-7702 opens a portal for Zyfi to provide gas abstraction layer for EOAs at omnichain level. The nuances on how exactly it fits in depends on various speculative factors like wallet implementation, restrictions, community feedback. These factors may become clearer as time passes by.
One of the key factors that supports Zyfi’s multi-chain approach is adoption of EIP-7677 that allows Dapps to choose paymaster logic for smart accounts instead of wallets. Zyfi is closely researching innovative ideas for a cumulative gas abstraction layer.
Zyfi’s unique feature allowing cross-chain intend based sponsorship that allows our partners(especially NFTs) to sponsor gas on other partner Dapps might be available for all other chains!

What does the future looks like:

All EOA’s will be converted to smart account faster than expected.
EOA users can truly enjoy account abstraction with great UX.
7702 + 4337 “supercharged EOAs” mainstreams almost all smart account functionalities. Smart account adoption would be quicker than expected.
Dapps will quickly shift to ERC-4337 type of UserOps structure to support multi-call batching(approve + swap) in one transaction.
Wallet UX and better stimulation would be the need of the hour.