EIP-7702: Set EOA account code

[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?

[wjmelements]

@invocamanman

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.

That’s the correct behavior. SETCODE does not create a new account. This is disambiguated by EIP-6780:

A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract’s new address it is still considered to be a contract creation.

[matt]

You’re right, this is just very confusing. Likely a result of spec thrashing. This should only apply to code executing instructions. I will update the EIP so it is clear.

EIP-7702: Set EOA account code

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 …

[invocamanman]

Thanks for pointing this out ^^
Since this EIP is older than the set EOA one, and it also says:

and other operations that deploy contracts in the future

IMHO, it is ambiguous

[wjmelements]

AuthorizationList SETCODE is not a CREATE series operation because it is not an opcode at all.