Skip to main content

​
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

ParameterValue
SET_CODE_TX_TYPE0x04
MAGIC0x05
PER_AUTH_BASE_COST12500
PER_EMPTY_ACCOUNT_COST25000
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