EIP-7702: Set EOA account code

EIPs EIPs core
388

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.

1 Like
389

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?

390

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.
1 Like
391

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?

1 Like
392

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.

393

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

1 Like
394
1 Like