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.

At the time of writing, this EIP is currently in it’s draft stage, meaning certain aspects of this EIP are subject to change over time which might differ from this article in future.

Brief knowledge regarding ERC-4337(Account Abstraction/ Smart Contract Wallets), EIP-3074 & EIP-5003 will be helpful.

Many thanks to Sam Wilson , one of the co-authors of EIP-7702 & 3074, for the review.

Motivation for EIP-7702

Currently, existing EOAs on Ethereum lacks vast functionalities that can improve user experience compared to Smart Account(Smart Contract Wallets) as listed below:

• Gas sponsorship - EOAs need ETH to make any transaction.

• Transaction batching - Batch multiple transactions into single transaction- i.e. (approve + swap) in one transaction.

• Account recovery, inheritance - A way to recover your account if private keys are lost or the owner has passed away.

• Privilege de-escalation - Only 1% of ETH is allowed to spend in a day.

• 2 factor authorisation, biometric based signing.

• Other functionalities in a smart account

The end goal of Ethereum is RIP-7560 - Native Account Abstraction and ERC-4337 - Account abstraction through alt mempools emboldens this goal further. This EIP provides a way to empower existing EOAs simultaneously ensuring forward compatibility with future goals.

What is EIP-7702?

EIP-7702: Set EOA account code for one transactionAdd a new tx type that sets the code for an EOA durong one transaction execution

This EIP introduces a new transaction type that allows externally-owned accounts(EOAs) to have smart contract code for one transaction.

Simply put, during the execution of this type of transaction an EOA will act as smart contract/smart wallet and after the execution of the transaction it becomes original EOA with no code.

EOA user wallet signs the contract_code and provides the signature in the transaction. Upon validation of this signature, contract_code is stored in EOA and it will act as a smart contract throughout the transaction. Upon execution of the transaction, code is emptied and EOA again acts as normal account.

EOAs are upgraded to `supercharged EOAs’ during the transaction.

EIP-7702 Transaction

As simple as it looks, this EIP will drastically change the UX for EOAs, dapps & wallets. Let us understand how an EIP-7702 transaction would look like:

([ chain_id, 
  nonce, 
  max_priority_fee_per_gas, 
  max_fee_per_gas, 
  gas_limit, 
  destination, 
  data, 
  access_list, 
  [[contract_code, y_parity, r, s], ...], // => New field as per EIP-7702 
  signature_y_parity, 
  signature_r, 
  signature_s 
]) 

As per above transaction format, a new field - array of [contract_code, y_parity(v),r,s] is added.

For each element, the contract_code is the code that will be placed in account of the signer(EOA) provided y_parity(v),r,s ECDSA signature is valid before the execution of transaction starts.

Note: Array allows multiple EOAs to set contract_code in the same transaction.

To secure this transaction in EIP 7702 and ensure the signer is an EOA, the signature works as follow:

ecrecover(keccak(MAGIC + contract_code), y_parity, r, s)
// Signature signed on - hash(MAGIC + contract_code) 
// Magic is a constant number to differentiate EIP-7702 signature type

Below steps will be fulfilled before the transaction execution begins.

Flow for each element - [contract_code,y_parity,r,s]: 
1. Let signer = ecrecover(keccak(MAGIC + contract_code), y_parity, r, s).
2. Verify that the contract code of signer is empty.
3. Set the contract code of signer to contract_code.
4. Add the signer account to accessed_addresses (as defined in EIP-2929.)

Note: Signers of any of the contract_code signatures, and the tx.origin of the transaction, are allowed to be different. i.e. EOA’s are not required to send transaction, only sign the contract_code

At the end of the transaction, the contract_code of each signer(EOA) is set back to empty.

Compatibility with ERC-4337

EIP-7702 is super compatible with ERC-4337 infrastructure. In EIP-7702, user wallets (EOA) signs contract_code which would be an ERC-4337 supportive smart account code.

Dapps creates User Operation(UserOp) with userOp.sender = EOA, might ask for another signature as per smart account code and sends it to the bundler. Bundler validates the user operation and bundles with other userOp to send a EIP-7702 transaction to EntryPoint contract.

UserOp: are pseudo-transaction objects that are used to execute transactions with contract accounts. They are created by Dapps.

Bundlers: are actors that package UserOperations from a mempool and send them to the EntryPoint contract on the blockchain.

EntryPoint: is a smart contract that handles the verification and execution logic for 4337 transactions.

This EntryPoint contract calls EOA for validation and execution. Since contract code is already placed at EOA with smart account code at the beginning of the transaction, it won’t revert and works as a smart account. And at the end of transaction, EOA’s code is emptied.

From User(EOA) perspective

This EIP provides the easiest migration to smart wallet while retaining EOA properties. It adds functionalities like batching transaction, gas abstraction & flexibility (to update to smart contract anytime) that “supercharges” EOA.

Concerns about signing malicious/buggy contract_code significantly increases due to the rise in phishing attacks as:

A single malicious 7702 type signature can drain your entire wallet in a single transaction.

Due to this nature, wallet providers may restrict 7702 type signatures to be initiated randomly by the Dapps or gate-keep what contract_code is being signed upto certain extent. From a developer point of view, EOA’s can always use a script to create 7702 type signatures with their private key.

Nonetheless, utmost caution should be taken while signing such 7702 type signatures.

Note: Normal “sign-in” you see every time you log-in to a dapp is always followed by default "\x19Ethereum Signed Message:\n" message.
While 7702 type signatures are different and can be only initiated by Dapps if wallet allow by providing specific API. 

From Dapps perspective

Due to the dangerous nature of this EIP and phishing attacks in the space, probability of wallets providers like Metamask etc, un-restrictively allowing EIP-7702 type signatures is extremely unlikely.

There is a possibility where instead of Dapps sending contract_code to sign to wallet providers; Dapps may be sending approve + swap transactions requesting batching using EIP-5792 type RPC endpoints(or a new standard perhaps). And wallets may choose to go for 7702 transactions or normal/4337 transactions. Incase of 7702 transactions, may use a standard contract_code maintained by the wallet providers.

The possibility where dapps initiates 7702 signatures by providing contract_code to sign to wallet providers increases security concerns. Wallets may also need to provide in-depth simulation on unknown contract_code as well. Here the gas abstraction layer can be maintained at dapp level rather than wallet level.

We can hope new RPC endpoints like batching transactions, gas abstraction flexibility can be standardised for this in near future.

From Wallets perspective

The main aim of wallets will be to protect its users from phishing attacks as much as possible.

Each wallet may choose different approaches to 7702 signatures. Whether to allow Dapps to initiate 7702 in some sort of restrictive manner like "select pro version"->" "Allow websites to send 7702 tx" -> "manually add website you want to allow 7702 tx” or completely restricting Dapps from initiating such signatures depends on specific wallets.Wallet may also ensure only a certain standardised smart account contract_code is used in 7702 signatures maintained by them. This gatekeeping could eventually result into permissioned innovations to maintain security.

In the end we can expect the competition will get the best out of wallets depending upon the popularity of this EIP and demand of the users.

On-going discussions

While proposing this EIP, Vitalik added 6 variations to be discussed among the community. While there are quite intellectual debates/discussions around these variations; these variations are quite important for the future of this EIP-7702

Gas

1) Should the contract_code instead be a smart contract address?

→ Sign (MAGIC + contract_address)

• In an ideal scenario, the gas cost for each such transaction will be equivalent to deploying contracts which is quite high. It is expected for contract_code to be as small as possible using proxy contracts.

• Although, using contract_address is still cheaper.

Signature Revocability

2) Should the contract_code signature also sign over the chainId?

→ Include chainId in signature i.e. sign (MAGIC + contract_code + chainId )

• Signing chain agnostic signatures allows users to reuse signatures on multiple chains. chainId specific signature check can be implemented on contract side

• Although, security concerns increase when using contract_address instead of contract_code as contract address on different chains may have different codes and malicious actor can re-use those signatures. Signatures used for testing purposes on testnet may also be reusable.

3) Should the contract_code signature also sign over the account’s nonce?

→ Include nonce in signature i.e. sign (Magic + contract_code + nonce)

• The main reason to include nonce in the signature is to mitigate signature replay attacks while also ensuring revocability at protocol level.

• Prevents replay attack - A malicious actor cannot re-use the contract_code signatures.

• Major concerns revolve around user experience as it may require 2 signatures every transaction. One for 7702 contract_code and another for validation in contract_code which will be ERC-4337 compatible.

Contract flexibility & Storage

4) Should SSTORE inside the “temporarily contract-ified EOAs” be prohibited, like it is in EIP-5806?

→ Whether to allow storage of EOA to persist after the transaction.

• Allowing storage to persist can cause storage collisions. Different contract_code may not have the same storage structure.

• Not allowing storage forces EOAs to rely on external storage contracts which can be expensive.

• Not to allow SELFDESTRUCT opcode.

5) Should we just add a flag to NOT set the code back to zero at the end?

→ Option to allow the code to exist after the transaction. Similar to EIP-5003

• This would allow EOA to opt-in whether to keep contract_code or not in the end. This allows flexibility to the EOA and easy migration to smart accounts.

6) Should we have initcode and not just contract_code?

→ Allow constructor code to be executed before the transaction.

• This would allow constructor code in contract_code to initialise the contract. The chief concern is it's unnatural and risky without external calls restrictions.

• Initcode could also prevent griefing/censorship attack from malicious relayer/bundler using old contract_code signature where ERC-721/1155 type fallbacks were not supported causing transaction to revert.

How Zyfi comes into the picture with EIP-7702

As a paymaster provider for major Dapps using native AA on zkSync, 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 already central to Zyfi.

Zyfi is a leading gas abstraction layer on Zksync with a massive 750K paymaster transactions, 113K users & $57K worth of gas sponsorship. Zyfi is one of the pioneers in gas sponsorship by offering innovative paymaster services to Dapps

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, related ERCs that might be required etc. These factors may become clearer as time passes by.

Zyfi, with it’s extensive research, looks forward into the future dominated by EIP-7702.

Future of EIP-7702

• EIP-7702 is likely to be included in next Pectra Fork around late 2024 or early 2025.

• It’s safe to say that EIP-7702+ ERC-4337 infrastructure is a highly probable future for the majority of wallet providers and EOA accounts.

• 7702 + 4337 “supercharged EOAs” streamlines almost all smart account functionalities. Smart account adoption would be quicker than expected.

• Gas sponsorship and paymaster for EOAs will add great features to the Dapps. Expect mainstreaming of gas-less transactions.

Frequently Asked Questions

1. How does this solve the gas sponsorship issue for EOAs?

   Once EOA transforms into a smart account/multicall contract, any bundler/relayer can call this contract with correct calldata. EOA performs this required operation, while gas fees are incurred by relayer/bundler.

2. How bad a malicious EIP-7702 type signature can be?

   A malicious EIP-7702 signature can drain your wallet in a single transaction. It is not even required for the victim to initiate the transaction.

3. How to revoke if I signed a 7702 malicious signature somehow?

   To identify the best way to revoke signatures is currently under discussion. Check the Signature revocability section above in this article.

4. How would signing contract_code work while interacting with Dapps ?

   Dapps may not initiate contract_code 7702 type signing to the wallets. Rather Dapps may send batch-requests using standards like ERC_5792 . And wallets may decide whether to ask for 7702 type signatures or not. Thus protecting users from malicious signatures through gatekeeping.

5. Will wallets allow signing any contract_code or will there be some sort of white-list or one standard contract_code maintained by the wallet?

   As mentioned in the article, it depends upon specific wallets on how they choose to implement and to what extent they want to restrict this for Dapps and users. Hopefully, competitive markets and user demands create a balanced space.

6. Would Dapps be allowed to choose 3rd party gas sponsorship/ custom paymaster?

   That is under speculation as of now, but standards like ERC-7677 intend to provide these capabilities to the Dapps.

7. Is there a future without 4337 compatibility for this EIP?

   Yes, this could be a possibility due to 4337 infrastructure overhead for a simple batching functionality. In that scenario, for contract_code 7702 type signature, wallets/dapps(if allowed) may optionally choose to use simple multi-call contract code instead of smart account code.

   Again, the future is quite speculative in this case as well, as the end goal of Ethereum is native account abstraction. It would be interesting to see how things turn out.

Closing thoughts

The research & development in this space is fast-paced. Information provided in this article might not stand factual in the near future.

Hence, Zyfi aims to provide the latest updates and developments in this area through a series of well-structured articles.

Stay tuned for part 2…