# EIP-7702

## Overview

The EIP-7702 introduces the change of the ethereum's EOA operation. It allows for the EOA to act like a CA, with the actual storage and code on it. With this update, user can freely give the EOA a fuction and call it like a CA, but only in the user's TX itself. It is made to support the AA wallet(SCW) to use the same address of the owner's EOA address, which results to fully acheive the "CA wallet".

#### The basic format of the newly introduced TX type

The EIP-7702 is the update which adds the TX type to the Ethereum core. During this transaction, the EOA gets a contract code, which is called as a EOA account code. The TransactionType of the new TX is specified as 0x04, and the TransactionPayload's RLP serialization format is like this:

```
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
```

chain\_id: The chain Id of the chain.\
nonce: The contract's nonce \
max\_priority\_fee\_per\_gas, max\_fee\_per\_gas: values for the gas calculation. check the EIP-1559\
gas\_limit: The gas limit for the TX can spend \
destination: The address for the TX to integrate\
value: The ETH balance to send\
data: The calldata of the TX\
access\_list: The list of addresses and storage keys that the transaction plans to access\
authorization\_list: The list of code authorizations that will be executed in the context of EOA signature\_y\_parity, signature\_r, signature\_s: The sign of the TX.

You can see the access\_list and the authorization\_list. It is newly added in the new TX type:

`access_list`:

* List of account addresses and storage keys that the transaction will access
* Format: `[[address, [storage_key1, storage_key2, ...]], ...]`
* Pre-declare to optimize gas costs. If the TX access the storage specified above, the gas cost of the access would be diminished.
* Follows EIP-2930 structure

`authorization_list`:

* List of code authorizations that EOA will execute
* Format: `[[chain_id, address, nonce, y_parity, r, s], ...]`
* Each tuple contains authorization information for delegated contract code
* Requires at least one authorization
* Specifies code to be executed in EOA's context. It allows the EOA to call multiple times at one TX. (do you know the solidity dev framework 'foundry'? It is quite similar to the 'forge script')

CF) The original TX format is like this:

```
[nonce, gasPrice, gasLimit, to, value, data, v, r, s]
```

#### How does EOA gets an contract code?

The EIP-7702 does not only introduces new types of the TX, it also introduces the ability for a EOA to act as an CA(only for the TX runtime). The EOA now has a 'delegation designation', which is a pointer of an existing contract. If the 0x04 type TX are called, the user's EOA turns into a CA with a code of the delegation designation contract, and has it's own storage. The EOA's storage remains permanently if the user does not modifies it. (Yes, now the EOA has it's own storage)

## Integration with the ERC-4337 and the Paymaster

The new types of the EOA's idea made the Account Abstraction more stable. Now users don't need to use the deployed account apart from the EOA, while integrating successfully with the ERC-4337, and also the ERC-6900. The user can simply use the EOA address as a deployed AA wallet, while changing the config values to the pointed delegation designation contract.(The logic contract that the EOA uses). If the owner of the contract is pointed by the user, the AA wallet rekt vulnerability would be very diminished. This means that the danger using the ERC-4337 would be decreased too. 

<figure><img src="/files/oXwm4IHotma2byPS0eeI" alt=""><figcaption></figcaption></figure>

But with this EIP changes, the pay for the gas fee is still an issue. The EIP-7702 con't solve the gas abstraction problem, so the paymaster is still needed for the gas payment by proxy. (as the same reason, the bundler and the SCW factory are still needed on order to use the Account abstrction.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://paymasterdocs.gitbook.io/paymasterdocs/resources/integrating-with-further-eips/eip-7702.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.