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.

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.

1 Like
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: