{"id":80025,"date":"2025-07-11T11:32:54","date_gmt":"2025-07-11T11:32:54","guid":{"rendered":"https:\/\/mycryptomania.com\/?p=80025"},"modified":"2025-07-11T11:32:54","modified_gmt":"2025-07-11T11:32:54","slug":"what-is-eip-7702","status":"publish","type":"post","link":"https:\/\/mycryptomania.com\/?p=80025","title":{"rendered":"What is EIP-7702?"},"content":{"rendered":"

As we know, EOAs can initiate transactions, but smart contracts can\u2019t; EOAs can only do simple transactions, but smart contracts can execute more complex ones. EIP-7702 combines the useful parts of these account types: EOAs can now borrow<\/strong> smart contracts\u2019 code.<\/p>\n

EIP-7702, part of Ethereum\u2019s upcoming Pectra upgrade, introduces a new transaction type (Type 4)<\/strong> that lets EOAs temporarily use the logic of a smart contract, allowing them to act like smart contract\u00a0wallets.<\/p>\n

How Will Wallets Handle EIP-7702?<\/h3>\n

Technically, an EOA can be upgraded to any<\/em> smart contract. However, in practice, wallets are unlikely to permit this freely, as it could introduce serious security risks. It will likely be restricted to their implementation or a limited set of approved smart accounts, as they don\u2019t want to allow users to delegate to a malicious contract that could cause them to lose all their\u00a0funds.<\/p>\n

MetaMask supports EIP-7702 and has a Delegator Contract. Here is an example of a type 4 transaction<\/a> that delegates to that smart contract:<\/p>\n

https:\/\/www.cyfrin.io\/glossary\/eip-7702<\/a><\/p>\n

If we look at the account info, we can see the delegated address:<\/p>\n

Also, when we look at the address<\/a>, we can see that the delegated address\u2019s Public Name Tag is MetaMask: EIP-7702 Delegator<\/strong>:<\/p>\n

Additionally, you can check which wallets support EIP-7702\u00a0<\/strong>here<\/strong><\/a>.<\/strong><\/p>\n

Benefits of\u00a0EIP-7702<\/h3>\n

Before EIP-7702, users had to make at least two transactions for simple transactions, such as swaps or deposits,<\/em> because they had to approve<\/em> them first. It makes users tired because they have to verify the correctness of all transactions and confirm them. They have to click the button for each transaction and check if it is true or not.
EIP-7702 enables multiple transactions to be completed in a single<\/strong> transaction. Due to this, users don\u2019t have to click for each transaction and check it for correctness; they should do this just once<\/em>. They can batch<\/em> multiple transactions into one, such as sending funds to various users, which can save\u00a0gas.It enables sponsorship. For example, someone else can pay for a transaction on behalf of a user, and the user can then pay the sponsor in ERC-20\u00a0tokens.It provides privilege de-escalation, which enables users to delegate limited permissions to sub-keys, rather than granting full access to their account. For example, a sub-key might be allowed to spend only ERC-20 tokens but not ETH, or limit spending to 1% of the total balance per day. This approach enhances security by limiting the actions that delegated keys can\u00a0perform.Users can perform complex operations without<\/em> having to deploy a custom smart contract, which provides savings in\u00a0gas.Because EIP-7702 is an EIP, Ethereum and Ethereum-equivalent L2s will automatically have it. It is not required to have new infrastructure, and it can adapt\u00a0quickly.EIP-7702 can demonstrate to users the benefits of Account Abstraction, thereby helping to facilitate its adoption.Users don\u2019t have to migrate their funds to a newly created account. They can now have a smart account with just a single transaction\u200a\u2014\u200athis makes EIP-7702 more desirable than ERC-4337 for\u00a0users.EIP-7702 provides an EOA that functions like a Smart Account, but it remains an EOA, allowing users to revert it to its original state. However, ERC-4337 accounts are just Smart Accounts.<\/p>\n

Does EIP-7702 Remove the Need For ERC-4337?<\/h3>\n

ERC-4337<\/a> and EIP-7702 are not seen as competitors; EIP-7702 is designed to be forward-compatible with ERC-4337. While EIP-7702 enables smart account functionality, it is not enough for Account Abstraction. Even though it has advantages, it still requires storing private keys or seed phrases<\/strong>, which is not ideal for mainstream adoption, as users can\u2019t keep them safe, and one of the main reasons why we need ERC-4337. So, we still need full Account Abstraction.<\/p>\n

How EIP-7702\u00a0Works?<\/h3>\n

EIP-7702 enables EOAs to act like a smart contract account through a delegation indicator<\/strong>. Previously, EOA\u2019s code field was empty, but now they are storing a delegation indicator (0xef0100 || address) in their code field, where the address points to a smart contract that contains features the user wants to use. Users set the delegation indicator via the setCode transaction:<\/p>\n

https:\/\/decentralizedsecurity.es\/eip-7702-ethereums-next-step-toward-a-more-flexible-account-model<\/a><\/p>\n

To define this relationship, a data structure known as authorizationList is introduced:<\/p>\n

chainId: Specifies the target blockchain network; if set to zero, it means that the transaction can be replayed on all EVM-compatible chains supporting EIP-7702. (But if nonce is different for different networks, it won\u2019t work even if it is zero, and also, the same contract address on different chains may have different implementations, which means that it should be set carefully.)<\/p>\n

address: Address of the smart contract EOA will point to. To delegate to a smart contract, that contract must already<\/strong> be deployed and available on-chain at the time of delegation.<\/p>\n

nonce: Ensures transaction is unique and protects against replay\u00a0attacks.<\/p>\n

signature: Verifies that the EOA has authorized the action by signing\u00a0it.<\/p>\n

The user signs the hash of a message constructed by first concatenating a fixed prefix called MAGIC (0x05) with the RLP encoding of [chain_id, address, nonce], and it looks like this: MAGIC || rlp([chain_id, address,\u00a0nonce]).<\/p>\n

If the address is 0x0000000000000000000000000000000000000000, the delegation indicator is not<\/strong> written because it is clear that the account\u2019s code is resetting to the empty code hash (0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470).<\/p>\n

Additionally, the signer of an authorization tuple may differ from the tx.origin of the transaction, and a setCode transaction must include at least one<\/em> authorization; otherwise, it will be\u00a0invalid.<\/p>\n

When a transaction targets an EOA that has a delegation indicator, the EOA runs the code located at the specified smart contract address as if the code belongs to the EOA itself, similar to the behavior of DELEGATECALL in smart contracts.<\/p>\n

SECURITY CONSIDERATIONS<\/h3>\n

Front-running initialization<\/h3>\n

With this EIP, when delegating to a contract, there is no way to run initcode or initialize storage during the delegation process. This creates a risk: someone could try to front-run and set up the delegation using an account they control. To prevent this, developers should make sure that the initial calldata used for delegation setup is signed by the EOA\u2019s private key. This signature can be verified using ecrecover, ensuring the delegation is only set up by the rightful account owner and with the intended\u00a0values.<\/p>\n

Storage Collision<\/h3>\n

As mentioned earlier, it works like a DELEGATECALL, meaning the smart contract code runs in the EOA\u2019s context and uses the EOA\u2019s storage instead of its own. This is similar to upgradeable smart contracts. Because of this, re-delegating must be done carefully to avoid storage collisions<\/strong>. To prevent such issues, using a standard like ERC-7201 is recommended. If there’s any doubt, it’s best to clear the account\u2019s storage first. While Ethereum doesn’t support this directly, a custom delegate contract can be created specifically to perform this operation. It\u2019s essential to design smart contracts for EIP-7702 carefully, as they can be vulnerable to front-running attacks and storage collisions.<\/p>\n

Transaction Propagation<\/h3>\n

Allowing EOAs to act like smart contracts through delegation introduces new challenges for how transactions are handled and shared across the network. Normally, EOAs can only send value, and nodes can easily check if a transaction is valid just by looking at that EOA\u2019s state. In this setup, one transaction can only invalidate other pending transactions from the same\u00a0account.<\/p>\n

However, with this EIP, delegation allows an EOA\u2019s code to be called by anyone, which means a transaction from one account could unexpectedly affect another. For example, an EOA\u2019s balance might be emptied through delegated code, making it hard for nodes to predict transaction outcomes ahead of\u00a0time.<\/p>\n

To reduce the risk of this happening, it is recommended that clients only allow one pending transaction at a time for any EOA that has a non-zero delegation indicator. This limits the number of transactions that a single one can invalidate.<\/p>\n

Another approach is to extend the EIP-7702 transaction format by including a list of accounts that the caller intends to \u201chydrate\u201d during the transaction. These accounts would act as delegated code only within EIP-7702 transactions that specify them in this list, enabling clients to analyze and understand pending transactions more effectively statically.<\/p>\n

tx.origin After\u00a0EIP-7702<\/h3>\n

tx.origin can no longer be assumed to come from a regular<\/em> EOA, as it may be an EOA executing delegated smart contract code. It means that contracts using checks like require(tx.origin == msg.sender, “Externally owned accounts only”); to make sure it\u2019s a transaction from directly an EOA won\u2019t work anymore because it can be an EOA with a delegation indicator, which means it can execute an intermediary smart contract but can still tx.origin == msg.sender.<\/p>\n

EOA Behavior Changes After\u00a0EIP-7702<\/h3>\n

CALL<\/h3>\n

When a transaction is sent to an EOA and it includes a delegation indicator, it will instead call the delegated smart contract. Prior to EIP-7702, it was assumed that any call to an EOA would succeed, as EOAs could not reject ETH transfers. However, what appears to be a simple ETH transfer to an EOA might now trigger a fallback function in the delegated contract, potentially consuming additional gas or even causing the transaction to\u00a0revert.<\/p>\n

For example, if a smart contract has a code like\u00a0this:<\/p>\n

(bool success, ) = recipient.call{value: amount}(“”);<\/p>\n

It can revert if EOA has a delegation indicator and the smart contract doesn\u2019t have a fallback or receive function.<\/p>\n

EXTCODESIZE<\/h3>\n

Previously, EXTCODESIZE returned 0 for EOAs, but now, it will return 23 (the size of 0xef0100 || address). Checking an address with EXTCODESIZE to determine whether it is an EOA or a smart contract can cause unintended actions. However, CODESIZE will return the size of the code residing at the address. So, during delegated execution, CODESIZE and CODECOPY behave differently from EXTCODESIZE and EXTCODECOPY on the authority contract.<\/p>\n

For more details and a better understanding, some helpful sources are\u00a0here:<\/p>\n

EIP-7702: Ethereum’s Next Step Toward a More Flexible Account Model<\/a>EIP-7702: Set Code for EOAs<\/a>Cyfrin EIP and ERC Glossary: EIP-7702<\/a>Walletbeat – EIP-7702 wallet adoption<\/a>https:\/\/medium.com\/media\/b4b23f60211963acb15ae268a723efb2\/href<\/a>EIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade?<\/a>EIP-7702: How Smart Contract Powers for Existing EOA Wallets<\/a>Will EIP-7702 Affect Your Code?<\/a><\/p>\n

https:\/\/docs.candide.dev\/account-abstraction\/7702\/overview\/<\/a><\/p>\n

What is EIP-7702?<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":"

As we know, EOAs can initiate transactions, but smart contracts can\u2019t; EOAs can only do simple transactions, but smart contracts can execute more complex ones. EIP-7702 combines the useful parts of these account types: EOAs can now borrow smart contracts\u2019 code. EIP-7702, part of Ethereum\u2019s upcoming Pectra upgrade, introduces a new transaction type (Type 4) […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-80025","post","type-post","status-publish","format-standard","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/80025"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=80025"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/80025\/revisions"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=80025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=80025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=80025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}