EIP-7702: Set EOA account code

EIPs EIPs core
366

It seems that the authorization nonce is incorrect (0x2 instead of 0x1), so the authorization is a no-op.

1 Like
367

It is difficult to predict the transaction result, as well as to debug SetCode transactions, because invalid authorizations are simply ignored. Would it make sense to implement something similar to eth_estimateGas but for authorizations? E.g. by exposing applyAuthorization function

1 Like
368

EOAs that run code MUST implement the tokenReceived (ERC-223) or onERC721Received function to be able to receive the tokens. This is how it is intended to prevent accidental / wrong deposits.

369

Also, eth_createAccessList doesn’t exclude authorities from valid authorizations, even though they are automatically added to the access list. As a result, the access list must be manually modified to avoid overpaying for unnecessary entries, making access list management more complex.

370

Why is the authorization a no-op when the nonce is incorrect?

371

See the spec:

If any of the above steps fail, immediately stop processing that tuple and continue to the next tuple in the list.

See also geth implementation here.

372

I asked why. What is the rationale?

373

I believe it’s so taking an authorization from transaction A in the mempool and “frontrunning it” with a separate EIP-7702 transaction B doesn’t cause the entire tx A to fail.

1 Like
374

The EOA can still frontrun it, and with different code than the sender was expecting. This griefing vector is going to prevent several “paymaster” designs from working securely. Too bad invalid-nonce’ing the entire transaction is a DoS vector agains the mempool.

375

I believe this was actually considered and was the motivation for ethereum/EIPs#9248.

The relayer/paymaster is able to assert that the delegation is the one that’s expected.

1 Like
376

I am a developer working on EIP-7702 smart account implementation. Our prototype is tested and launched on testnet.

Our goal is to allow users to upgrade their EOA account to try out the smart contract functionalities. But I realize currently there is not a good way to help users upgrade their existing EOA wallet to EIP-7702.

What do you feel about a RPC standard for the EIP-7702 sign_authorization? Basically the app developer and propose the wallet to sign the hash keccak(MAGIC || rlp([chain_id, address, nonce]).

I found an existing proposal on Github: eth_signAuthorization.md ¡ GitHub

377

App developers shouldn’t request user’s to sign specific authorizations. Dapps aren’t trusted like a wallet is. There is basically no way for a user to receive such a request and sign it confidently. There are so many hidden ways this could blow up for the user. Only the user’s wallet should directly have the user sign authorizations.

2 Likes
378

It is indeed pretty hard to verify a proposed EIP-7702 contract, but there are still several ways to achieve this.

  1. Maintaining a list a verified and audited 7702 contracts. Because each contract only needs to be deployed once, it is possible to maintain a limit list of 7702 contracts and just share them across wallets/dapps. This is similar to the EntryPoint contract in ERC-4337 standard.
  2. Allowing wallet owner to determine which 7702 contract they want to use. Based on the non-custodial principle, wallet apps don’t really have the right to block users’ request if the user wants to delegate to a 7702 contract.

EIP-7702 has the potential to extend all EOA wallets to be a unified interface. Besides initiating transaction from the wallet itself, EIP-7702 will allow other users to proactively interact with the EOA wallet like interacting with a smart contract. For example, an EOA wallet can delegate to an OTC-style smart contract and allow others to swap tokens with it at a fixed rate.

To make it possible for wide adoption, such interface and 7702 contract must be simple and extensible. I have a proposal to turn all EOA wallets into an intent-centric interface, which is stateless, non-custodial, and modular:

379

Reading EIP-7702’s Transaction propagation section:

Another alternative would be to expand the EIP-7702 transaction with a list of accounts the caller wishes to “hydrate” during the transaction.

This is not currently part of EIP-7702, so a mass invalidation where a single tx sweeps multiple cod-delegated accounts is currently possible?

380

Hi all, in the process of integrating EIP-7702 into our products, one of the pain points is the inability to efficiently determine the results of both the transaction and the delegation, without going through multiple RPC calls.

We propose a change to the current getTransactionReceipt, to add a list of authorization statuses, so that we are able to determine both results in 1 RPC call.

The hackmd link below shows an expanded discussion, and the corresponding PR to ethereum/execution-apis repository.

381

Isn’t this already possible with eth_getProof? As soon as the nonce is increased and the codeHash is not empty anymore you know that the code delegation was successful. This should work at least for self-sponsored transactions.

In general I think devs should make sure that 7702 txs cannot fail. If not, you end up in this weird situation where the tx has failed, but the delegation is persisted anyways. Which requires to add at least one special case to your business logic.

382

GM

EIP-7702’s ability to let EOAs temporarily act as contracts unlocks novel use cases. However, its inverse effect—granting contracts EOA-like transaction signing—is a paradigm shift requiring scrutiny.

While EOAs gaining smart contract-like behavior is transformative, the reverse—smart contracts wielding EOA-like signing authority—carries profound risks. Imagine widely-adopted, high-value contracts (e.g., WETH, vaults, cross-chain bridges) “autonomously initiating” (signing) transactions—what safeguards exist?.

Core Risks:

  1. Accountability Blur: Contracts wielding EOA-like signing keys could lack clear governance, revocation pathways, or ownership transparency.
  2. Risk Amplification: Contract initiated transactions could magnify systemic risks.

Proposed Safeguard: Sandboxed Delegation

  • Mechanism:

    • Restrict delegated EOAs to ONLY sign transactions that modify/revoke their delegation .

      • Preserve EIP-3607 safeguards—preventing delegated EOAs (contracts) from autonomously initiating transactions.
      • While delegated, the EOA can only modify or revoke delegation.
      • To regain initiating ability, the EOA must first revoke delegation, ensuring clear separation.

    • Pros: Adds friction to misuse while retaining flexibility.

    • Trade-offs: Uncharted territory—UX friction, Pandora’s box.

“With great power comes great responsibility” — a mantra worth embedding into EIP-7702’s adoption.

383

An issue here is that we will still be unable to determine the result of the execution of calldata, since reverted transactions will still consume the nonce.

Although eth_getProof does indicate the success of code delegation, it is tied to chain state at a particular block height, and not towards the transaction itself. As such, we will still need to utilise methods like eth_getTransactionReceipt to detect confirmation, then pull the proofs.

I think its unrealistic to ensure 7702 transactions cannot fail. The attached calldata can be reliant on on-chain state, which does not revert during simulation but fails on-chain.

If the suggestion is to avoid using calldata during 7702 transactions, this would contradict the intent and direction of the EIP itself — which explicitly allows for combining code authorization and execution in one transaction.

384

Tagging this PR before the “Last Call” deadline triggers and it goes final

This migrates the parameter named MAGIC to SET_CODE_TX_MAGIC, aligning with SET_CODE_TX_TYPE and the EELS reference code. No semantics change.

387

I noticed that eip-7702 transactions cannot have blobs. I suspect that should be justified in the EIP Rationale.

1 Like