EIP-7702: Set EOA account code for one transaction

One point that I think hasn’t been answered in the breakout session:
What should be the behavior of those delegated accounts in the context of type < 4 transactions ? Should they behave like EOAs then ?
I think @adietrichs proposed something we also mentioned which would answer the question I guess by having this list of “activated” addresses in the type 4 transaction, in a similar form as access list.
That would only allow type 4 transactions with an address added to the activated list to use that delegation, having a pretty predictable mechanism. The only other predictable behavior would be to always use the delegation with any transaction type I guess.

That would be how I understand the updated proposal. The alternative is what you mention as the proposal from Ansgar:

  • Only type 4 transaction can active code at an EOA address
  • Only code can be activated that has been set prior
    Not sure if this would imply that there are multiple flow (or even another tx type :thinking: )

I have asked on Discord but will re-post it here to get some more awareness. The situation is:

(1) setup sender account C with enough funds
(2) setup code account B with code PUSH1 PUSH1 SSTORE STOP 600160015500
(3) sign auth msg from account A to put code in account A from account B
(4) send tx from C → A with auth list to set A code to B

If I change the tx to send value, then the storage does not get deleted. If I send 0 value, the account gets deleted. This is per EIP-161. This thus means that in order to set storage on an account, it should be prefunded or it should already have existed before (nonce nonzero). The test can be found here ethereumjs-monorepo/packages/vm/test/api/EIPs/eip-7702.spec.ts at 09108c5b27554af9126a0b3174a7f333c2e9b3b3 · ethereumjs/ethereumjs-monorepo · GitHub

The discord message link to the topic is here: Discord

Any update on this? It would be great to have a contract reference implementation so we can get a better idea of how this all works E2E.

We finished an initial iteration and have passed off the work to the Reth team to clean things up and make it client-ready code: feat: eip-7702 by onbjerg · Pull Request #9214 · paradigmxyz/reth · GitHub.

The spec is changing a lot but we can definitely show off a reference implementation once we get the rubber stamp on the 7702 spec.

1 Like


It might be a good idea to start a reference implementation even before a spec is finalized, otherwise it’s hard to tell if the spec is actually ergonomic / needs adjustment.

I see much progress has been made on the EIP, including addressing this issue.

I have a few more questions, if anyone can answer:

  • Under the Security Considerations > Secure Delegation section there are a number of things suggested that “delegate contracts should be wary of and require a signature over from the account’s authority”: nonce, value, gas and target / calldata. What are the dangerous scenarios envisioned here? Doesn’t the EIP now require authorization over the nonce and thus prevent replay inherently? Is it to mean that in general 2+ signatures will be required from owners in order to interact safely with contracts?
  • Is the correct interpretation of that in an EIP-7702 tx, the value will be sent to destination and data invoked on it, after the code for each authority has been set, and that by setting destination to be one of the authorities, the value will be sent to it and the data executed on the delegate contract? Is it also correct that now it is possible to clear the code for an authority within the same tx by providing a second signature for address(0) with nonce + 1?