> ## Documentation Index
> Fetch the complete documentation index at: https://spiceflow-docs.spicenet.io/llms.txt
> Use this file to discover all available pages before exploring further.

# EIP-7702: Account Abstraction via Temporary Delegation

> Technical deep dive into EIP-7702 and how Spice Flow leverages EIP-7702-powered delegation for atomic transaction execution.

## EIP-7702: Temporary Account Delegation

**EIP-7702** is a new and powerful Ethereum Improvement Proposal, which came was first created in May 2024, that allows an *Externally Owned Account (EOA)* (a regular user wallet) to temporarily act as a smart contract on EVM chains. It achieves this by letting a user sign an `authorization` that delegates their account's authority to a specific smart contract implementation.

**Why is this important?**

Instead of a user sending multiple transactions across different chains, they can sign a single **EIP-7702** `authorization` for each chain. This authorization is like giving a one-time permission slip to our system to perform specific actions on that chain. It's powerful because:

* **It's Non-custodial**: The user never gives up control of their private keys. The authorization is a signature, not a key transfer.

* **It's Secure**: The authorization is for a specific contract and is only valid for one chain, minimizing risk.

* **It's atomic**: The user can bundle multiple actions into a single intent, which is then executed as a single transaction on each chain, if all actions are valid, if any action fails, the entire transaction reverts. For example, a user can sign an intent that includes swapping tokens on one chain and bridging assets to another chain. If either action fails, neither action is executed, ensuring the user doesn't end up in a partial state.

* **It Enables Gas Sponsorship**: Because the user delegates execution, a third-party *"solver"* can submit the transaction and pay the gas fees on the user's behalf.

* **It Enables Batching**: A solver can bundle multiple actions into a single on-chain transaction. For example, executing a user's intent *and* paying the user back for their initial deposit.

* **It Allows Privileged Execution**: The contract can perform actions that a regular EOA cannot, such as interacting with other smart contracts, executing complex logic, or even paying gas fees in tokens other than ETH.

* **It's compatible with EIP-4337**: EIP-7702 can be used in conjunction with EIP-4337 (Account Abstraction) to provide a seamless user experience. For example, a user could sign an EIP-7702 authorization that delegates to an EIP-4337 smart contract wallet, allowing for even more complex interactions.

## Some specifications

### Parameters

| Parameter                | Value   |
| ------------------------ | ------- |
| `SET_CODE_TX_TYPE`       | `0x04`  |
| `MAGIC`                  | `0x05`  |
| `PER_AUTH_BASE_COST`     | `12500` |
| `PER_EMPTY_ACCOUNT_COST` | `25000` |

A new **EIP-2718** transaction known as the "set code transaction" is introduced with **EIP-7702**, where the *TransactionType* is set to `0x04` and *TransactionPayload* is the RLP serialization of the following:

```
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], ...]
```

* the fields inside the `rlp` of the outer transaction follow the same semantics as *EIP-4844*.

* The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a *secp256k1* signature over `keccak256(SET_CODE_TX_TYPE || TransactionPayload)`.

* `authorization_list` is a list of authorizations, each containing:
  * `chain_id`: the chain ID where the authorization is valid.
  * `address`: the address of the contract to which authority is being delegated.
  * `nonce`: a unique number to prevent replay attacks.
  * `y_parity`, `r`, `s`: components of the ECDSA signature.

* The authorization\_list is a list of tuples that indicate what code the signer of each tuple desires to execute in the context of their EOA. The transaction is considered invalid if the length of authorization\_list is zero.

## Behavior

The authorization list is processed before the execution of the transaction, but after the sender's nonce is incremented.

For each `[chain_id, address, nonce, y_parity, r, s]` tuple, perform the following:

1. Verify the chain ID is 0 or the ID of the current chain.
2. Verify the `nonce` is less than `2**64 - 1`.
3. Let `authority = ecrecover(msg, y_parity, r, s)`.
   * Where `msg = keccak(MAGIC || rlp([chain_id, address, nonce]))`.
   * Verify `s` is less than or equal to `secp256k1n/2`, as specified in EIP-2.
4. Add `authority` to `accessed_addresses`, as defined in EIP-2929.
5. Verify the code of `authority` is empty or already delegated.
6. Verify the nonce of `authority` is equal to `nonce`.
7. Add `PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST` gas to the global refund counter if `authority` is not empty.
8. Set the code of `authority` to be `0xef0100 || address`. This is a delegation indicator.
   * If `address` is `0x0000000000000000000000000000000000000000`, do not write the delegation indicator. Clear the account’s code by resetting the account’s code hash to the empty code hash `0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`.
9. Increase the nonce of `authority` by one.

In case, any step fails, the processing of that tuple is halted immediately, and skipped to the next tuple in the authorization list.

Note, if transaction execution results in failure (e.g. any exceptional condition or code reverting), the processed delegation indicators is not rolled back.

***

### Sources

* [https://eip7702.io/](https://eip7702.io/)
* [https://eips.ethereum.org/EIPS/eip-7702](https://eips.ethereum.org/EIPS/eip-7702)