EIP-7702: Set EOA account code

[matt]

The delegations cannot cause a tx to revert, nor does a tx revert cause the delegations to revert. So there is no need to send 7702 txs without calldata.

This isn’t to say that determining if a delegation was successful is fool proof, because since delegations don’t cause tx reverts, their inclusion in a block isn’t a testament to their validity. That needs to be determined separately or the RPC can return the outcome.

I think doing so at the RPC is reasonable. Clients can compute the result of the delegations on the fly fairly cheaply so it seems fair to lump into some of the other computations we already do.

[shoenseiwaso]

Can someone suggest a reliable route for calling an EIP-7702 account once deployed? I deployed a custom EIP-7702 wallet several days ago, but have been unable to find a way to call it successfully.

Here’s the EIP-7702 transaction on Sepolia: 0xa2cef1760b5b9222e5b9b6453f446054fceb12ff12e0e8dc1f4c9d5671bd2a41

Here’s the “minimal” EIP-7702 wallet address: 0x4fed4cb93b2d7b2773b22a4897febe1e6cc6e0d9#code

Note that it has some helper functions to allow for easier manual testing.

I have tried sending transactions from a custom go-ethereum v1.15.7 program directly to a publicnode[.]com RPC endpoint, but it does not work. eth_getCode returns no code at the address (whereas I would have expected the EIP-7702 “pointer” code there), and calling smart contract functions through the address also does not work.

Any ideas/suggestions?

[codebyMoh]

For Contract as per I understand,

• The contract code only exists during the processing of the transaction.
• eth_getCode after the transaction returns 0x because there’s no persistent contract code stored at the address.
• Think of it like an ephemeral proxy for one transaction.

[shoenseiwaso]

Thanks for the explanation.

So any time you want to execute an EIP-7702 transaction, you:

• Pass the EIP-7702 transaction information (authorization to perform the action, contract to delegate to)
• In the “regular” part of the transaction, do whatever it is you were going to do

Does this make sense?

[fulldecent]

In the EIP, the motivation section does not justify the major change that this EIP proposes.

It says “There is a lot of interest in adding short-term functionality improvements to EOAs” but then it goes on to simply list example after example of things that can be done today already with smart wallets.

---

For this reason alone, the EIP should be reverted to draft status.

[matt]

What motivation would make sense to you? I think people desiring certain functionality is certainly motivation for said functionality.

[nicszerman]

EIP‑7702 breaks on‑chain provenance needed for regulated assets

Executive Summary Traditional‑finance (TradFi) tokens rely on always knowing which wallet authorised each state‑changing call. EIP‑7702 breaks this: the signing wallet (the authorizer) no longer surfaces via tx.origin, rendering Ethereum incompatible with regulated assets. Adding one VM‑level field—tx.authorizer—would restore that information without touching existing contracts or privacy, especially when tokens move atomically through pooled contracts (e.g., Uniswap → Morpho). Call to Actio…

[peersky]

For ERC7744, is this check to validate whether caller is 7702 is correct?

        uint256 containerCodeLength;
        assembly {
            containerCodeLength := extcodesize(container)
        }
        bool is7702 = containerCodeLength == 23;

Is there any better way to identify that caller is delegated EOA?

[matt]

To be more specific you might want to check the prefix 0xef0100 also, because it’s possible we have more types of 23 byte indicators.

[peersky]

How do we do it? Use EXTCODECOPY and compare first three bytes?

Seems to require alot of operations for a single check:

function isCalledByDelegateEOA() internal view returns (bool) {
    bytes3 prefix;
    assembly {
        let size := extcodesize(caller())
        if gt(size, 2) { // Ensure the caller has at least 3 bytes of code
            extcodecopy(caller(), 0, mload(0x40), 3) // Copy first 3 bytes to memory
            prefix := mload(0x40) // Load the 3 bytes from memory
        }
    }
    return prefix == bytes3(0xef0100);
}

[frangio]

@peersky

        let size := extcodesize(caller())
        if gt(size, 2) { // Ensure the caller has at least 3 bytes of code

You don’t need this part.

[fulldecent]

The motivation as currently written explains that people want better access to make transactions. That’s great. They can use [Gnosis] Safe Wallet!

All of the remaining words in the proposal are describing big changes with no necessity.

---

In general, for engineering projects I think it is best practice to do work only after a need is identified (and other signoffs are achieved). Therefore it would be inappropriate to continue working on this EIP and writing a motivation after the work is done.

Write the motivation first!

[matt]

That’s why we wrote the motivation first

“Users” in this instance is overwhelmingly EOA users. Gnosis safe is an option, but despite being available for many years, safe users only account for a small portion of total accounts.

[fulldecent]

The motivation section I am reading says it wants to add

• Batching …
• Sponsorship …
• Privilege de-escalation …

Each one of those is possible with Safe.

The only other complaint it mentions is:

UX improvements across applications

And of course… the solution is to update those applications.

---

So in other words, the problem is that applications are not using Safe, then please update the applications to use Safe.

There is no other actionable work in the EIP motivation section. This is already a solved problem. And therefore this EIP should be reverted to draft status without further consideration.

[matt]

Have you seen the updated version of the EIP? It explains clearly why the improvements are focused on EOAs.

Despite great advances in the smart contract wallet ecosystem, EOAs have held back broad adoption of UX improvements across applications. This EIP therefore focuses on adding short-term functionality improvements to EOAs which will allow UX improvements to permeate through the entire application stack. Three particular features this EIP is designed around are

[wjmelements]

@fulldecent

Each one of those is possible with Safe.

What isn’t possible is SETCODE. In comparison to DELEGATECALL + SLOAD, these proxies have no gas overhead. One problem with this is that this superior upgrade pattern is only available to EOAs. This will lead to protocols using EOAs for their upgrade mechanism. Therefore I hope that some variant of SETCODE will become available to all accounts in the future.

@fulldecent

And therefore this EIP should be reverted to draft status without further consideration.

The EIP is already live in the testnets and is included in the mainnet hard fork next week. Therefore it will be Final soon.

[poojaranjan]

PEEPanEIP-7702: Set Code for EOAs with Anders Kristiansen

EIP-7702: Set Code for EOAs with Anders Kristiansen | PEEPanEIP#148 #pectra

[shoenseiwaso]

@codebyMoh

For Contract as per I understand,

• The contract code only exists during the processing of the transaction.
• eth_getCode after the transaction returns 0x because there’s no persistent contract code stored at the address.
• Think of it like an ephemeral proxy for one transaction.

After further experimentation and re-reading of the EIP, this is not the case, at least as far as the standard was implemented. The contract code does persist until set to something different, or to the zero address to effectively un-set it. Getting the code at the EOA address does return the authorization list details (e.g. 0xef01003cca915ff5efff7be8d8e37eeba5e9577f9ca8db).

It turns out I had a nonce error in my earlier transaction, so the authorization list was never set, which is why I was getting no code returned.

Also, just for fun, I ended up writing what might be the dumbest EIP-7702 smart wallet: NoMoreGasMoney.sol

[invocamanman]

I’m unsure if this was mentioned earlier, but I would add in the EIP, in a specific way, how selfdestruct interacts with the SET EOA account code.

Intuitively, I could think that a eip-7702 transaction that has an empty authority, counts as a contract creation, and therefore, if in the same transaction is excuted a selfdestruct on that account, It will be compliant with EIP-6780 and the contract code should be deleted

As I check on the Geth client, as far as I’m aware, this is not the case. The code is not accounted as .newContract, and therefore it cannot be deleted.

I could agree to both ways to proceed, but in order to avoid possible client collision, I would explicitly add the behavior of this case in the EIP.

[wjmelements]

If a code reading instruction accesses a cold account during the resolution of delegated code, add an additional EIP-2929 COLD_ACCOUNT_READ_COST cost of 2600 gas to the normal cost and add the account to accessed_addresses . Otherwise, assess a WARM_STORAGE_READ_COST cost of 100 .

This seems to suggest that each CODESIZE and CODECOPY operation adds another 100 gas. That’s not great for copying strings. Are those the applicable "code reading instruction"s, since EXTCODESIZE and EXTCODECOPY do not resolve to the implementation? Or is it a remnant of an earlier specification where EXTCODESIZE and EXTCODECOPY resolved to the implementation?