Title: EIP_7702__Set_EOA_account_code
Category: EIPs

Author: 0xkvn
Date: 2024-06-26T12:53:34.165Z

SamWilsn:

How do you envision dapps communicating 7702-style authorization tuples to the Ledger? I think the only standard interface being discussed right now (bear in mind that I’ve been out of the loop for a while ) is EIP-5792 . Ledger would need to pick the bytecode to use anyway, so no different than a whitelist.


Sorry @SamWilsn for the late answer !
Yeah we’re not really discussing the whitelist here, it will have to be one either way, you’re right.
The point about the whitelist was actually to say that having it would already limit the possibilities on our side to a point where the options offered by signing bytecode directly (where you could be tempted to slightly modify an existing implementation in order to include an “in code” signer without relying on initilization and/or storage for example) would be more or less identical for the end user with our limitations.
At the end of the day, since we won’t be able to handle customizable bytecode — or at least, not many of them and/or not complex ones — it would then become a single option to sign an 1167 proxy code containing a whitelisted implementation address VS signing an implementation address, so not much to gain I guess.
In terms of dapp communication, that’s actually the point of the proposal we made. We don’t really think it should be a dapp decision to make this kind of “transformation” to an account. That seems like a wallet responsibility to us, where a wallet could provide a simple UX of “upgrading an account to AA of brand X/Y/Z”, signing that thing once, initializing the contract in the same type 4 transaction containing the authorization (revoking the short lived message at the same time).
And now every dapp and wallet can detect that behavior by looking at the storage slot mentioned, knowing what kind of implementation it’s dealing with.
In terms of device communication, we would have a specific new entrypoint where you’d be providing a derivation path and an implementation address, and the device would display a something like “Do you want to upgrade your 0xabc account to an X/Y/Z (based on the whitelist) smart account ?”. Pretty simple.
Obviously that can actually be triggered by anyone, dapps included, that’s why the limit to 1 active implementation per account matters, so that even if its activated or changed by anyone, any wallet can react accordingly by reading the storage slot. You wouldn’t get “used” to sign this message regularly just because Wallet 1 has the authorization, while Wallet 2 don’t, or because a DApp made you do it in their own context, and your wallets don’t know about it.

Author: rmeissner
Date: 2024-06-26T15:03:29.545Z

Just leaving here one of the ideas that came from the AA breakout room today (kudos to @SamWilsn):
Building on top of the persisted 7702 version it could be useful to allow selfdestruct inside 7702 accounts. This way it is possible to have accounts that are only valid temporarily and then clean up themselves.
Would be interesting to get more opinions on this.

Author: 0xkvn
Date: 2024-06-26T15:17:34.882Z

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.

Author: rmeissner
Date: 2024-06-26T19:05:38.114Z

0xkvn:

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  )

Author: jochem-brouwer
Date: 2024-07-01T07:53:28.495Z

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

Author: mattstam
Date: 2024-07-09T20:02:41.517Z

julrach:

The Otim team is almost done with the 7702 Reth implementation and is working on all necessary base case contract reference implementations in parallel. They are built with the current spec in mind (hence contract_address ). We will be posting about this all soonTM.


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.

Author: julrach
Date: 2024-07-09T23:15:27.836Z

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.

Author: mattstam
Date: 2024-07-10T01:00:51.573Z

Thanks!
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.

Author: jflatow
Date: 2024-07-12T06:16:48.335Z

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?

Author: mds1
Date: 2024-08-20T13:39:36.791Z

nlordell:

We’ve cooked up some clever ideas on making 7702 work with Nick’s method (by encoding context in the r value of the signature)


@nlordell Can you expand on how this works? My understanding is the latest version of 7702 (signing an address) does not support deterministic deployments with nicks method, but perhaps you found an approach to enable that?

Author: nlordell
Date: 2024-08-21T05:43:10.366Z

mds1:

My understanding is the latest version of 7702 (signing an address) does not support deterministic deployments with nicks method, but perhaps you found an approach to enable that?


TBH, I haven’t been following this EIP super closely anymore (it felt like it was getting overhauled every week ), so I don’t know if my comment still applies. It was made in an older iteration of the EIP when the expectation for wallets was to sign two messages for turning an EOA into an initialized smart account (one for the EIP-7702 authorization, and one for the initialization). This, for obvious reasons, made using Nick’s method with EIP-7702 more difficult (since you can only get one signature despite needing two), and a work around by encoding initialization context in r was a possible solution. I don’t know how this idea applies to the current iteration of the EIP.

Author: etan-status
Date: 2024-08-29T10:06:41.824Z

github.com/ethereum/EIPs








Update EIP-7702: Change `MAGIC` from `0x05` to `0x1a`


master ← etan-status:sc-magic



          opened 10:04AM - 29 Aug 24 UTC




            etan-status
          



+4
-4






Ethereum signatures are scoped by signing domain to ensure that when data of dif…ferent types happens to encode as same byte representation that the resulting hash being signed does not collide across domains. This is typically done by prefixing the data with the domain constant before signing it. The following signing domain constants are defined:

- 0x00: Unused for signing, but represents Homestead tx on JSON-RPC
- 0x01: EIP-2930 transaction
- 0x02: EIP-1559 transaction
- 0x03: EIP-4844 transaction
- 0x04: EIP-7702 transaction
- 0x05: EIP-7702 authorization
- 0x19: EIP-191 signed data
- 0x80-0xfe: Homestead transaction
- 0xff: Reserved by EIP-2718

EIP-2718 aliases transaction types to a subset of the signing domains:

- 0x00 represents a tx but is not used for signing.
- 0x01-0x04 represent a tx and are used for signing.
- 0x05 and 0x19 do not represent a tx but are used for signing.
- 0x80-0xfe represent as 0x00 on JSON-RPC but are used for signing.
- 0xff is reserved and neither represents a tx nor is used for signing.

To improve simplicity as future transaction types are introduced, it may be desirable to group related constants together.

For that reason, it is proposed to change the signing domain used for EIP-7702 authorization from `0x05` to `0x1a`. Rationale:

- This allows a future transaction type to use type 0x05 sequentially.
- If transaction types ever enumerate through 0x18, there is already the problem of 0x19 being in use. Therefore, assigning 0x1a to be used for EIP-7702 authorizations does not introduce additional problems beyond what already will have to be dealt with.
- If a new signature algorithm is introduced, one may still do so by setting the upper bits in the signing domain, e.g., 0x40 or 0x20 are still left untouched if 0x1a is assigned. This is an advantage over, e.g., assigning 0x20 to EIP-7702 authorization signatures.






Have made a proposal here to change the signature domain for authorization signatures from 0x05 to 0x1a.
JSON-RPC should probably also expose the authorization type, so that JSON-RPC client implementations can verify that they are computing the authority based on the correct signature algorithm.

Author: etan-status
Date: 2024-08-29T10:25:05.375Z

github.com/ethereum/EIPs








Update EIP-7702: Restrict chain_id to chain's id or zero


master ← rakita:eip7702_chainid1



          opened 12:14PM - 28 Aug 24 UTC




            rakita
          



+1
-1






As we already checking if `y_parity` and `s` values additionally adding a check …for correct `chain_id` seems logical.

This would make the EIP-7702 transaction invalid if it is not zero (chain agnostic) or has chain_id different from the Ethereum-s chain_id.

Would propose that this change is added after `devnet-3` to not disrupt testing/developing efforts.






Also, regarding ChainId=0 meaning chain-agnostic, that special semantics need to be defined somewhere more broadly. Currently, ChainId=0 is not reserved afaik (but also not practically in use, see EIP-2294: Explicit bound to Chain ID - #18 by xinbenlv)

Author: radek
Date: 2024-09-02T12:19:18.692Z

What if we propose a generic way to “etching” the runtime code? (address would be only based on hash of such code).
That would replace the need for Nick’s method for many cases (non governed registries, factories, …). And allow to re-deploy such contracts to new chains by anyone.

Author: adhusson
Date: 2024-09-02T14:15:58.592Z

In the context of developing the next operation batching contracts for Morpho, the following issues reduce the utility of this EIP in its current version.
No ability to restore a delegation without re-signing
If a user signs a delegation to a Morpho-specific operations batcher (which is then able to do delegatecalls and receive arbitrary callbacks), it will remove the delegation to their existing account contract. The user will then need to re-sign the original delegation. This will discourage many users from using an app batching method based on EIP-7702.
Any update that allows multiple delegations to coexist and be used independently would make EIP-7702 usable in this context.
No ability to sign delegations using e.g. secp256r1
Developments such as EIP-7212 mean that in the future, users will be able to sign operations on devices that will not hold an Ethereum private key at all. Those users will be completely unable to use EIP-7702.
An update that either adds secp256r1 or that generalizes signing would make EIP-7702 cover more usecases.
Generally speaking, if this EIP is too constrained, most apps will have to work for compatibility with a huge variety of “permanent” account contract types, each with their own API, feature sets, etc. If it is general enough, apps will be more able to use this uniform interface to replace their users’ code.

Author: frangio
Date: 2024-09-02T15:00:55.440Z

Directly delegating to an app-specific batcher is indeed not a good use of this EIP. Not only because of the UX issue you described, but because wallets will only allow a few select templates for security reasons and a dapp will not be able to prompt users to delegate to a custom template.
Delegation will be used by wallets to add general-purpose capabilities to EOAs, including batching.



 adhusson:

if this EIP is too constrained, most apps will have to work for compatibility with a huge variety of “permanent” account contract types, each with their own API, feature sets, etc.


This is an application-layer standardization problem that we need to work on. See EIP-5792 for the best attempt so far.
This also addresses secp256r1. EIP-7212 enables smart contract accounts with secp256r1 authorization. These accounts should offer the same set of general-purpose capabilities through EIP-5792.

Author: adhusson
Date: 2024-09-02T17:14:05.116Z

Thank you for your response. EIP-5792 helps with making a standard for batches of calls, but 2 important features are not addressed:

Delegatecalls for complex interactions, such as slippage checks.
Callback registration for protocols where control flow is based on controlling conditions before and after the user interaction, such as Morpho and Uniswap v4.

If EIP-7702 improves multiple delegations and signing generality, apps will be able to directly manage delegatecalls & callbacks with a single interface.
On security:



 frangio:

wallets will only allow a few select templates for security reasons





 frangio:

Delegation will be used by wallets to add general-purpose capabilities to EOAs


Could you say more about this? Signing a code delegation to a bad app or signing a call batch to a bad app could both result in complete loss of funds now or later, and the risk distinction between each scenario is nuanced enough to question preventing apps from routinely using delegation.

Author: frangio
Date: 2024-09-02T18:41:19.547Z

adhusson:


Delegatecalls for complex interactions, such as slippage checks.
Callback registration for protocols where control flow is based on controlling conditions before and after the user interaction, such as Morpho and Uniswap v4.



Some of these requirements should be implemented as further ERC-5792 capabilities and standardized in a follow-up ERC, and if that’s not possible we should look at improving ERC-5792 itself. Others may be more appropriately addressed with a different smart contract design for these protocols.
Can you share an example of such callbacks?



 adhusson:

Signing a code delegation to a bad app or signing a call batch to a bad app could both result in complete loss of funds now or later


Authorizing a bad contract to act on your behalf is very different from calling a bad contract. But a bad dapp could request a batch of calls that steals all of the wallet’s assets. I think the difference comes down to how easy it is for a wallet to detect and report a risky signature. If you want to detect whether a code delegation is risky you need static analysis to understand all possible behaviors of that code. If you want to detect whether a batch of calls is risky you “just” have to simulate the batch execution.

Author: adhusson
Date: 2024-09-03T13:43:25.519Z

Can you share an example of such callbacks?

Yes, here are 2 cases:

Morpho callbacks. For instance one can leverage upon supplying collateral without looping and without a flashloan as illustrated in this snippet.
Uniswap v4 Flash Accounting which wraps potentially unsafe pool-modifying operations in a callback so that the pool can verify that everything balances out afterwards. This also saves gas by writing intermediate token transfer to transient storage.

In each case the callback is a way to run arbitrary user-defined operations followed by a final operation / check by the protocol.

Author: nlordell
Date: 2024-09-12T12:00:25.510Z

I was reading the latest draft of this EIP and this statement caught my eye:

A neat byproduct of this is that by combining EIP-7702 and CREATE2 it will be possible to commit to deploy specific bytecode to an address without committing to any fee market parameters. This solves the long standing issue of universal cross-chain contract deployment.

AFAIU this isn’t solved since you sign an address with the 7702 message, so you can only universally deploy if a universal deployment contract already exists, so you have a chicken and egg problem. Am I missing something obvious? Is this statement left over from previous iterations of this EIP where you signed code or a code hash and should be removed?

Author: winsvega
Date: 2024-09-14T12:57:54.524Z

is 7702 set code basically equivalent to putting DELEGATECALL(dest) into authorized account?
also it looks like this eip allows EOA accounts to mimic some external code and send transactions on it’s behalf at the same time. which was prohibited before. can it break some smart contract logic potentially?

Author: mrnerdhair
Date: 2024-09-15T22:38:00.289Z

A few observations:

The current text of the EIP specifies that chain_id be signed over, but not that it actually be checked. It would be useful to explicitly specify this behavior and define its semantics; i.e. is chain_id == 0  allowed?
It looks like there’s no way to use this EIP to unset a delegation designator on an EOA after it’s been set. It could perhaps be set to delegate to the null address, but it doesn’t seem useful a null delegation to be stored as a distinct state from a vanilla pre-delegation EOA. Is this intentional? Is the idea here that you’d need to delegate to a contract containing just the SELFDESTRUCT opcode to reset the designator?
What happens if there’s a collision between an EOA and contract address as contemplated by EIP-3607 and the contract executes the SELFDESTRUCT opcode? By clearing the contract’s code, wouldn’t this allow the contract to be effectively redeployed via this EIP’s delegation scheme?
One disadvantage of this transaction-based approach vs EIP-3704’s opcode-based scheme is that delegation transactions must be sent in via EOAs, and can’t be “batched” themselves. With EIP-3704, a contract wallet could calculate unlimited free sub-addresses which unconditionally delegate to it using Nick’s method. With this EIP the same approach is technically possible, but to sweep funds sent to such an address a contract would need to leverage an outside transaction sponsorship market to broadcast a delegation transaction which adds extra complexity and effectively prevents atomicity of such an operation. Does anyone have thoughts on how to re-enable this usecase?

Author: matt
Date: 2024-09-17T16:37:54.279Z

mrnerdhair:

The current text of the EIP specifies that chain_id be signed over, but not that it actually be checked.


It’s bullet 1) in behavior section.



 mrnerdhair:

It looks like there’s no way to use this EIP to unset a delegation designator on an EOA after it’s been set. It could perhaps be set to delegate to the null address, but it doesn’t seem useful a null delegation to be stored as a distinct state from a vanilla pre-delegation EOA. Is this intentional? Is the idea here that you’d need to delegate to a contract containing just the SELFDESTRUCT opcode to reset the designator?


The idea is that you can delegate to an empty account if you want to “remove” your delegation. I haven’t been convinced of a reason to add additional mechanisms to the EIP to truly clear the delegation.



 mrnerdhair:

What happens if there’s a collision between an EOA and contract address as contemplated by EIP-3607 and the contract executes the SELFDESTRUCT opcode? By clearing the contract’s code, wouldn’t this allow the contract to be effectively redeployed via this EIP’s delegation scheme?


SELFDESTRUCT only works for contracts created during the transaction, so I’m not really sure how this would be an issue?



 mrnerdhair:

One disadvantage of this transaction-based approach vs EIP-3704’s opcode-based scheme is that delegation transactions must be sent in via EOAs, and can’t be “batched” themselves.


Delegations can definitely be batched, not sure why you believe otherwise? The 7702 tx object has a list field for authorization tuples.

Author: mrnerdhair
Date: 2024-09-17T17:12:11.030Z

lolwhoops


I’m more worried about the “denormalization” associated with creating two distinct states of undelegated EOA and the future pitfalls that might result in. I’d argue that setting a delegation and then unsetting it should leave an EOA in a state indistinguishable from never having delegated at all. For example, what should EXTCODESIZE return for an EOA delegated to an EOA delegated to an empty account? 0, or 23? (For that matter, what should EXTCODECOPY return?)


Thanks, I missed that EIP-6780 was a thing, which also addresses my previous question about delegation-to-SELFDESTRUCT.


I described this poorly, apologies. I mean that with EIP-3704 a contract could, for example, calculate a new address ecrecover(keccak256(MAGIC || 0 || 0 || contractAddress || salt), 0, 0xdeadbeef..., 0xdeadbeef...), AUTH for it, and then AUTHCALL into it, all within a single method call. With EIP-7702, delegations can only be set via a transaction initiated by an EOA, so the contract will need to calculate the authorization tuple and then somehow ask someone nicely to  include it in a TX before it can get on with its business. This would force contracts to break up otherwise-atomic operations and leverage an external market set up with economic incentives for TX builders to include authorization tuples for delegations that contracts need set. That’s not impossible, but it’s certainly a PITA,

Author: frangio
Date: 2024-09-17T17:20:12.588Z

Yes indeed current 7702 does not solve universal cross-chain contract deployment. 
This proposal would fix that:



 wjmelements:

Yet another way to do this could be to sign the code_hash, but specify the code_address in the transaction, so that nodes don’t have to index code by hash.


Was it considered? If so is there a reason why it was rejected?
It would be really good to finally solve this issue.

Author: mrnerdhair
Date: 2024-09-17T17:31:10.353Z

I’m not thinking specifically about deterministic cross-chain contract addresses; I’m thinking more in terms of a single contract wallet with siloed sub-accounts for security purposes. Like it or not, the address is the fundamental security principal, and the ability for contract wallets to easily spin up alternate addresses for interaction with various dApps or protocols would be a pretty killer feature.
(Also could be useful for privacy purposes! ZKPs would allow a contract wallet to manage separate pools of funds for separate people, while keeping the records of the who controls what off-chain.)

Author: frangio
Date: 2024-09-17T17:36:05.279Z

Sorry, my post was unrelated, I want to discuss deterministic addresses separately.

Author: dror
Date: 2024-09-19T16:57:06.553Z

I think we’re missing some cost issue in EIP-7702:
Currently, there are 2 possible costs per authorization entry:

PER_EMPTY_ACCOUNT_COST (25000) - the cost a new authorization struct,  making an EOA a delegate the first time (equivalent to the gas cost of one storage slot change and one new storage cell)
PER_AUTH_BASE_COST (2500)- the cost of specifying a do-nothing authorization, with the same delegate, or with wrong signature/nonce (which covers roughly the ecrecover)

However, there is a 3rd case:
3. The cost of changing an existing account to a new delegate value.
AFAIK, the last case currently costs 2500, since the delegate already exists, and thus it is underpriced (it has to cause 2 slot changes, one for nonce and one for code (prefix+address).

Author: AyushBherwani1998
Date: 2024-09-22T02:27:44.784Z

Hey, I was going through the EIP. Since authorization doesn’t have a way to allow granular control, wondering how we could authorize the specific permissions to the wallets.

Author: mrnerdhair
Date: 2024-09-22T02:31:38.847Z

The concept of specific permissions is an application-layer one and must be handled by whatever contract an EOA delegates to.

Author: wjmelements
Date: 2024-09-23T22:23:46.911Z

I like the 0xef01 designator pattern. I would like for the pattern to be available to all outside of eip-7702 transactions; it should be permissible to CREATE them, but they are currently banned by EIP-3541: Reject new contract code starting with the 0xEF byte

Author: etan-status
Date: 2024-09-26T16:35:06.605Z

As proposed, users can include authorizations with malformed ECDSA signatures (invalid y_parity/r/s values) that are not valid on any chain even in theory.
While authorizations may not be relevant to the current chain (chain_id mismatch), I don’t see why they should allow for arbitrary data storage (256bit chain_id, 20byte address, 64bit nonce, 256bit y_parity, 256bit r, 256bit s; total 156 bytes) using a separate pricing model from those actually intended for data storage. By checking the signature for validity (as in, it at least in theory belongs to some address on some chain), the use case of including a couple extra authorizations for other chains still allows exotic bridge scenarios but at the very least limits the possible wasted storage.
Is there a reason why invalid authorization signatures don’t make the transaction invalid?

Author: matt
Date: 2024-09-26T18:00:08.897Z

mrnerdhair:

For example, what should EXTCODESIZE return for an EOA delegated to an EOA delegated to an empty account? 0, or 23? (For that matter, what should EXTCODECOPY return?)


These things are all well specified in the EIP. Delegating to an empty account will make the account indistinguishable from one that has been delegated to for intents and purposes.



 mrnerdhair:

so the contract will need to calculate the authorization tuple and then somehow ask someone nicely to include it in a TX before it can get on with its business


I think you may be misunderstanding the purpose of 7702. It’s to allow users to delegate to a smart contract wallet and then perform smart contract wallet operations like batching calls, etc. Other use cases, like synthetic accounts from contracts, are not a focus. Once a user has delegated their account, it effectively behaves like a smart contract wallet and they can install custom modules to address any further needs they have.



 mrnerdhair:

I’m thinking more in terms of a single contract wallet with siloed sub-accounts for security purposes.


To do something like this you would delegate the EOA master account to a smart contract wallet and that smart contract would just deploy subaccounts that are controlled completely by the master account.



 dror:

Currently, there are 2 possible costs per authorization entry:


The second case is intended to be the cost of updating the account for the delegation. What should the true cost of this be? Open to modifying it, but I don’t think we need a third case. Submitting invalid do-nothing updates can just cost the same as a valid update.



 etan-status:

Is there a reason why invalid authorization signatures don’t make the transaction invalid?


The idea is to make transaction validity as simple as possible to verify. I don’t see a reason overcomplicate it so long as the data isn’t cheaper to shuttle inside an invalid 7702 auth.

Author: etan-status
Date: 2024-09-26T19:48:20.700Z

The idea is to make transaction validity as simple as possible to verify

Could there at the very least be a check on y_parity to only allow [0, 1]? Right now, that field is documented to support any uint256, and limiting the range of y_parity is trivial, even if one wants to avoid the full ecrecover cost in this spec.
Or, at the very least, to a uint8…

Author: mrnerdhair
Date: 2024-09-27T01:01:56.471Z

matt:

These things are all well specified in the EIP. Delegating to an empty account will make the account indistinguishable from one that has been delegated to for intents and purposes.


No, it wouldn’t, at least not by the current language in the EIP:

For example, EXTCODESIZE would return the size of the code pointed to by address instead of 23 which would represent the delegation designation. CALL would similarly load the code from address and execute it in the context of authority.
In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain.

EXTCODECOPY on a delegate A to another delegate B would therefore perform a code lookup for A, recognize the delegation designator, and perform a second lookup for B. It would then not follow the second delegation, returning the raw contents of the delegation designator at B and allowing observation of B’s delegation target address.



 matt:

Other use cases, like synthetic accounts from contracts, are not a focus.


I understand that EIP-7702 was not authored to support this use case specifically, but it is intended to replace EIP-3074. That EIP, though probably not written with this usecase in mind, does support it, and so it’s a relevant point of comparison between the two.



 matt:

To do something like this you would delegate the EOA master account to a smart contract wallet and that smart contract would just deploy subaccounts that are controlled completely by the master account.


Deploying a ERC-1167 proxy costs ~65k gas upfront and slightly increases the gas cost of each subsequent call. Using EIP-7702 to set a delegate using a deterministic signature will cost ~25k gas upfront and add no additional overhead to each transaction. This seems like it would instantly become the new meta for proxy deployment, and it would be beneficial to consider how automation of authorizations will be handled upfront. The economic incentives mean that it will happen on its own eventually, but IMHO it would be better for the whole ecosystem to specify a standard mechanism rather than deferring to (yet another) bolted-on transaction-submission marketplace.

Author: mrnerdhair
Date: 2024-09-27T01:07:08.657Z

Wouldn’t an authorization with an invalid signature just not store anything? The TX itself doesn’t have to be invalid, it just won’t mutate state. Or are you talking about the cost to fullnodes of archiving the raw TX rather than on-chain state? (And if so, how would this be different than a TX with a lot of calldata that reverts with OOG?)

Author: matt
Date: 2024-09-27T12:24:58.640Z

mrnerdhair:




 matt:

These things are all well specified in the EIP. Delegating to an empty account will make the account indistinguishable from one that has been delegated to for intents and purposes.


No, it wouldn’t, at least not by the current language in the EIP:

For example, EXTCODESIZE would return the size of the code pointed to by address instead of 23 which would represent the delegation designation. CALL would similarly load the code from address and execute it in the context of authority.
In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain.

EXTCODECOPY on a delegate A to another delegate B would therefore perform a code lookup for A, recognize the delegation designator, and perform a second lookup for B. It would then not follow the second delegation, returning the raw contents of the delegation designator at B and allowing observation of B’s delegation target address.


Delegating to B isn’t an empty delegation though. You would need to delegate to a known empty + unknown address like 0x0.



 mrnerdhair:

I understand that EIP-7702 was not authored to support this use case specifically, but it is intended to replace EIP-3074. That EIP, though probably not written with this usecase in mind, does support it, and so it’s a relevant point of comparison between the two.


It isn’t intended to perfectly replace 3074. The exact complaint about the feature you are mentioning is that it creates a new account for flow separate from the AA flow that has been in development. We can’t have everything and this was the compromise made with the AA community.



 mrnerdhair:

Deploying a ERC-1167 proxy costs ~65k gas upfront and slightly increases the gas cost of each subsequent call. Using EIP-7702 to set a delegate using a deterministic signature will cost ~25k gas upfront and add no additional overhead to each transaction. This seems like it would instantly become the new meta for proxy deployment, and it would be beneficial to consider how automation of authorizations will be handled upfront. The economic incentives mean that it will happen on its own eventually, but IMHO it would be better for the whole ecosystem to specify a standard mechanism rather than deferring to (yet another) bolted-on transaction-submission marketplace.


If the cost is out-of-whack maybe we can adjust to bring it more in line. I have wondered if we could add a CREATE3 which would allow us to deploy this “protocol proxy”. My main concern is applications using this format to deploy contracts used by many people. This will circumvent the original goal of 3607.

Author: etan-status
Date: 2024-09-27T12:44:38.548Z

Yeah, I’m worried about providing incentives to abuse it. A legitimate authorization has a chain_id < ~2^52, a y_parity value of 0/1 and fills the rest. An illegatimate data storage may use the full 2x 256 bits for chain_id / y_parity, and so on.
The difference to calldata is that calldata is still paid for, at its intended rate, even if it reverts. While a legitimate authorization requires less storage than an illegitimate one, but is charged the same price as a smaller, legitimate authorization.
I can see lightclient’s argument that indeed, an invalid signature should indeed not make the entire tx be invalid – it should at least be possible to charge for the ecrecovers involved in validating it. But I’d like to see chain_id limited to uint64, and y_parity to 0/1 or at least uint8 so that the illegitimate use case does not offer more data storage than a legitimate authorization.

Author: matt
Date: 2024-09-27T15:10:30.477Z

etan-status:

The difference to calldata is that calldata is still paid for


IMO the key is that the cost for an auth is greater than the cost of calldata, otherwise we risk the free DA as you mentioned.
It seems like there is overwhelming demand to limit the chain id and y_parity. I can accept that limit them to uint64 and uint8.

Author: mrnerdhair
Date: 2024-09-28T23:17:40.586Z

matt:

Delegating to B isn’t an empty delegation though. You would need to delegate to a known empty + unknown address like 0x0.


If Bob has an EOA and Alice deploys an EOA and delegates to Bob, Charlie can run EXTCODECOPY on Alice’s account and get back the contents of Bob’s code. If Bob’s not delegated at all, Charlie gets a zero-length result. If Bob instead delegates to 0x0, Charlie gets 0xef0100000000000000000000000000000000000000000000000000. In fact, one could write a contract that used this as an access-control measure – which probably means someone will, thinking that an EOA that’s never delegated is more secure or some such – and that fact could discourage users from taking the “irreversible” step of delegating in the first place.



 matt:

If the cost is out-of-whack maybe we can adjust to bring it more in line. I have wondered if we could add a CREATE3 which would allow us to deploy this “protocol proxy”. My main concern is applications using this format to deploy contracts used by many people. This will circumvent the original goal of 3607.


Hey, I’m not against cheaper costs here – IMO everyone would benefit from an optimization for the minimal proxy use-case, and it makes sense that it would be cheaper as a delegation mechanism like this would be much cheaper for nodes to process than actually executing the ERC-1167 bytecode. Your point about 3607 is well-taken. I expect that a majority of contract authors would happily take that security tradeoff for the gas savings, so it’s worth considering how to avoid presenting them with the choice.
(It’s also worth pointing out the EIP-3702 doesn’t have this issue, but only because it doesn’t enable this usecase.)

There’s an argument to be made that we should intentionally break the proxy usecase to maintain EIP-3607 protection. I don’t think it’s a good argument, though; I’ve tried to think of what modifications to this EIP could be made to prevent it from being used to deploy proxies, and all of them have significant undesirable impacts.

Raise PER_EMPTY_ACCOUNT_COST to match the gas cost of deploying an ERC-1167 proxy.

This would effectively make opening an AA account several times more expensive than it should be just to discourage people who aren’t even in target users from shooting their own feet on a regular basis, which seems like a perverse set of incentives. The current 25,000 gas cost is in the ballpark of the 21,000 base gas for making a transaction; one can easily justify the small marginal cost of opening a contract-wallet AA account instead of a regular one. I don’t have the exact numbers in front of me but a minimal proxy contract ~3 times that much; raising the cost to prevent the use of EOAs as cheap proxies would have to also raise the barrier to AA by several times.

Prohibit delegations from EOAs with a nonce equal to 0. This would indirectly require at least two signatures to be made by an EOA’s keypair, preventing the use of an EOA derived via the deterministic signature method.

Not only would this cause a gas-sponsorship chicken-and-egg problem, since you’d have to get ETH into the EOA to pay for the initial nonce-bumping TX before you could set delegation to an AA contract wallet with a sponsored gas arrangement, I’m not sure it would even actually prevent the deployment of proxies via EOA delegates. One could, after all, create a “burner” keypair for deployment and then throw it away, as long as you could convince your users that you’d actually thrown it away. That is, of course, impossible to actually prove – but I can totally see a dApp glossing over that point to users who aren’t savvy enough to recognize the security issue in order to gain a competitive advantage due to their greater gas efficiency. (And then, once that gets normalized, someone will hold onto the “ephemeral” EOA keys and do a rugpull.)

Require set code transactions to contain two different signatures.

This is the best I could think of to avoid the first problem from point #2 (gas sponsorship), but it doesn’t avoid the second and would not only require a second ecrecover but increase the TX storage costs for fullnodes to boot.

If it’s inevitable that 7702 will be used to deploy proxies, perhaps we could add a mechanism to allow that usecase to maintain 3607 protection. That could be as simple as introducing a special type of delegation designator that’s not allowed to be updated by a set code transaction. Perhaps this could be paired with an exception to EIP-3541 allowing direct creation of contracts with delegation designators, or some new opcode like CREATE3, or maybe a modification to the authorization format to add a flag to enable immutability; in any case, it should be no more expensive than deploying a proxy via deterministic signature without the 3607 protection immutability provides.

Author: rdvorkin
Date: 2024-10-01T15:58:50.731Z

Reading through the EIP, I noticed that sweeping becomes much more expensive with EIP-7702 compared to EIP-3074. The main issue is the PER_EMPTY_ACCOUNT_COST which is added for every address swept, adding significant gas costs if sweeping lots of wallets.
Any thoughts about this?

Author: matt
Date: 2024-10-01T18:40:21.020Z

mrnerdhair:

If Bob has an EOA and Alice deploys an EOA and delegates to Bob, Charlie can run EXTCODECOPY on Alice’s account and get back the contents of Bob’s code. If Bob’s not delegated at all, Charlie gets a zero-length result. If Bob instead delegates to 0x0, Charlie gets 0xef0100000000000000000000000000000000000000000000000000. In fact, one could write a contract that used this as an access-control measure – which probably means someone will, thinking that an EOA that’s never delegated is more secure or some such – and that fact could discourage users from taking the “irreversible” step of delegating in the first place.


This is still an extremely contrived example. If people want to “reverse” their delegation then can delegate to 0x0. If a contract wants to detect this, they will either need an external service to submit a delegation to the EOA in question to get that link like you described, or they need to prove against the state root.
Since delegating to a zero address doesn’t let an EOA do anything special and doesn’t change the fact that post-Prague they can delegate to a non-zero address at any moment, I don’t see an issue with how it is currently specified.



 rdvorkin:

Reading through the EIP, I noticed that sweeping becomes much more expensive with EIP-7702 compared to EIP-3074. The main issue is the PER_EMPTY_ACCOUNT_COST which is added for every address swept, adding significant gas costs if sweeping lots of wallets.
Any thoughts about this?


This is only paid if the account does not exist in the trie, otherwise the cost is 2,500.

Author: rdvorkin
Date: 2024-10-02T10:27:20.693Z

Yes it’s paid only if the account does not exist in the trie, however this will usually be the case when sweeping tokens from deposit addresses. User submits tokens to the address, the address is not added to the trie, therefore sweeping those tokens will include the cost of PER_EMPTY_ACCOUNT_COST.

Author: mrnerdhair
Date: 2024-10-02T16:59:34.386Z

matt:

This is still an extremely contrived example. If people want to “reverse” their delegation then can delegate to 0x0. If a contract wants to detect this, they will either need an external service to submit a delegation to the EOA in question to get that link like you described, or they need to prove against the state root.
Since delegating to a zero address doesn’t let an EOA do anything special and doesn’t change the fact that post-Prague they can delegate to a non-zero address at any moment, I don’t see an issue with how it is currently specified.


Security is all about finding contrived examples. It’s always easier to recognize that an implicit assumption can be broken before someone comes up with a useful reason to break it.
In this case, the original rationale for not including a mechanism to remove a delegation was the implicit assumption that a delegation to 0x0 would be indistinguishable on-chain from having no delegation at all. That indistinguishability property doesn’t hold. To be clear, we’re now talking about using a new, different rationale to justify omitting such a mechanism – not “it confers an attacker no possible advantage”, but “it confers an attacker no useful advantage.”
I think that’s a dangerous rationale, even if it does end up being a technically sound analysis of the presently-contemplated system, because future upgrades tend to make things better and more useful. For example, you just said that the difference between the two states (never-delegated and delegated to 0x0) is negligible because introspecting it requires setting up an external service to submit a delegation transaction, but that’s a specific pain point I brought up previously. The rationale for not specifying a way for a contract to set a delegation without an external transaction submitter was merely that such a mechanism was out of scope for this EIP, not that its absence was necessary to justify the omission of a true undelegation mechanism.
Besides, omitting a round-trip undelegation mechanism from this EIP actually doesn’t make the system simpler – it just socializes the complexity to future maintainers. Imagine, for example, that there’s some other delegation standard we want to implement in the future. (Obviously, we’re using 0xef0100 as a prefix rather than simply 0xef here for a reason!) But because this EIP fails to specify a way to get back to a canonical “not delegated” state, we force any future work which might want to use the 0xef prefix for EOAs for something else to handle upgrades from the “delegated-to-nothing” state as well as the “blank-code” state. That adds sharp edges I’d really prefer that future EIP authors not have to avoid.
I’ll admit that I don’t understand yet why the “obvious” solution – special-casing delegations to 0x0 as blanking an account’s code – wasn’t included from the start, which makes me worried that I’ve missed some attack vector that approach might enable or other obvious downside. But I do think it’s just poor design to build a switch that you can nominally turn on and off, where turning it off puts you into a different state than before turning it on.



 matt:

This is only paid if the account does not exist in the trie, otherwise the cost is 2,500.


(Note that this puts a 2500-gas upper limit on the cost to introspect an account’s delegation designator. You could easily set a delegation designator for an address with a well-known private key in the same transaction you tried to do the introspection, and you’d have an atomic operation.)

Author: frangio
Date: 2024-10-03T13:42:10.216Z

Another reason we might want to be able to fully remove delegation is that a delegation to 0x0 increases many costs of using one’s account, since the EVM will try to fetch code from 0x0 costing an additional COLD_ACCOUNT_READ_COST. This applies to receiving ETH and receiving NFTs (which uses EXTCODESIZE).

Author: nathanglb
Date: 2024-10-04T18:18:22.327Z

Isn’t anyone worried that EIP-7702 introduces a major phishing risk in conjunction with 1271 signature verification?
Example:
NFT Trading Protocol Verifies ECDSA Signature for order approval.  When ECDSA verification fails and code length > 0, protocol falls back to 1271 isValidSignatureNow check.  This pattern is probably common in many protocols.
In scenario above, using 7702, you could phish a signature that attaches malicious contract code to the NFT holder, submit fake order data with a sale price of 0 eth, and then return MAGIC from isValidSignatureNow to authorize the zero-value order.
There will probably be many such cases.

Author: nathanglb
Date: 2024-10-04T19:06:54.361Z

Another phishing vector that doesn’t involve protocols at all:

Drainer phishes as many signatures as possible to attach unverified, malicious code to their EOA. For the sake of argument, say they are able to harvest hundreds of such approvals because nobody checks to see if the attached code is verified. And even if it is verified, nobody reads the code anyway.
Drainer executs a drain transaction on a smart contract they have deployed. The 7702 special tx includes dozens of phished victims at once.
drain loops over the supplied victim addresses, calling drainAssets on the malicious code that has been attached to victims’ accounts. It searches for valuable assets like ETH/WETH/USDC/etc and valuable NFTs, calling transfer to the attacker on everything it can find that is considered valuable.

The only thing that can prevent this is tokens that implement Limit Break’s ERC20-C/ERC721-C/ERC1155-C with security levels set to block OTC.

Author: 0xth0mas
Date: 2024-10-04T19:19:09.088Z

Look, the people that get phished for their entire net worth are just going to have to take one for the team as this new technology advances and appropriate safeguards are put in place after thorough post-mortem analysis.

Author: wjmelements
Date: 2024-10-04T20:05:53.100Z

There are already many phishing vectors. Users should know what they are signing and that’s the wallet’s responsibility. These signatures don’t resemble other signatures so older wallet software won’t be prone to this unless they were already prone to much worse attacks (such as eth_sign: What is 'eth sign' and why is it a risk? | MetaMask Help Center 🦊♥️).
Wallet security is hard and at first it will be hard to support this feature safely. However, the feature is good and so technology will improve to support it.

Author: 0xth0mas
Date: 2024-10-04T20:19:15.773Z

Most of the current phishing vectors revolve around signing EIP712 signatures that are semi-readable, rely on open approvals, don’t risk native funds, and are generally easy to simulate the potential impact of signing.
This EIP has the potential to drain all valuable assets, including native funds, with a far less readable signature that is harder to simulate. I would not be surprised to see wallets take a highly centralized approach to what contracts are allowed to be signed. It will be a step backward for security and decentralization while being pushed towards the finish line at a remarkable pace.
If there’s a significant enough security incident will we end up with ETCV2?

Author: nathanglb
Date: 2024-10-04T20:29:04.494Z

“User’s should know what they are signing”.
I completely agree - that’s why I love EOAs and self-sovereign wallets.  Account Abstraction is about onboarding people that don’t understand crypto/wallets at all.  You can’t expect them to know/understand what they are signing if the only way to onboard them is to hide the Web3 wallet from them altogether.

Author: mrnerdhair
Date: 2024-10-05T01:24:56.481Z

If you phish a signature for a delegate authorization, all bets are off. It has root. You don’t need clever protocol shenanigans at that point.
You could, of course, also have just phished a signature for a transaction which called transfer directly; the only difference here is that it lets you batch TXes, which is frankly a feature and not a bug. I’m looking forward to there being a simple and cheap way to sweep all assets from an address with a compromised key to a new one.

Author: peersky
Date: 2024-10-07T13:52:26.002Z

Do I understand correct, that in result of this eip:

solidity address(EOA).codehash will return one-time code hash value during the transaction?

Was there analysis of consequences for existing address.codehash users (github finds some)?


There will be no means to identify within EVM runtime that addresses bytecode is temporarly set?

Im guessing answer is in these lines

The delegation designation uses the banned opcode 0xef from EIP-3541 to designate the code has a special purpose. This designator requires all code retrieving operations to follow the address pointer to fill the account’s observable code. The following instructions are impacted: EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, CALL, CALLCODE, STATICCALL, DELEGATECALL.

But perhaps someone can translate to simpler language? Does this formulation meaning is that external contracts will observe EOA as an EOA?
Also thinking if moving ERC7744 to eip could allow one-time deployers to specify codehash instead of sending full bytecode as @wjmelements suggests?



 wjmelements:

I want to suggest code_hash instead. This would be fixed-size and so would not require a large gas payment. The hash refers to the EXTCODEHASH return value for accounts.

Author: peersky
Date: 2024-10-07T14:42:24.883Z

peersky:

Also thinking if moving ERC7744  to eip


added proposal pr for this, just in case: Add EIP: GETCONTRACT opcode by peersky · Pull Request #8935 · ethereum/EIPs · GitHub

Author: matt
Date: 2024-10-07T21:49:02.113Z

frangio:

Another reason we might want to be able to fully remove delegation is that a delegation to 0x0 increases many costs of using one’s account, since the EVM will try to fetch code from 0x0 costing an additional COLD_ACCOUNT_READ_COST. This applies to receiving ETH and receiving NFTs (which uses EXTCODESIZE).


This is a more compelling perspective.



 peersky:


solidity address(EOA).codehash will return one-time code hash value during the transaction?



This shouldn’t be the case since the codehash is determined by the account’s delegation. It can change, but it isn’t a “one-time”.



 peersky:

But perhaps someone can translate to simpler language? Does this formulation meaning is that external contracts will observe EOA as an EOA?


As long as the account is not delegated or is delegated to an empty account, contracts will observe it as an EOA.

Author: peersky
Date: 2024-10-08T03:20:00.183Z

I elaborated github query today morning
To validate my concern, I spent some time digging in and discovered a repo which I think would become vulnerable in result and is deployed on Ethereum:
https://etherscan.io/address/0x0000000000b1827b4959F2805E4b480D8799FCbB#code
Their public method originate internally calls _callCustody that reverts based on user-provided custodian field, which is being checked via extcodehash.
With 7702, adversary could temporary delegate to make it look like he is valid custodian, inside originate the transferSpentItems method would send assets to adversaries EOA.
I found some more later:

here is another repo using similar pattern
and one more

Author: frangio
Date: 2024-10-08T03:40:23.918Z

Yes that’s interesting.
Basically contracts could so far assume that codehash would be a reliable indicator of the behavior of an account. Unless the behavior was that of a proxy it could be assumed to be immutable. EIP-7702 changes that by introducing “invisible proxies”.
I think this is a very legitimate security concern.

Author: matt
Date: 2024-10-08T12:15:38.499Z

I don’t really understand this point, can you expand on the issue? IMO until cancun, it was possible to selfdestruct an account and deploy alternative code. So an account having different code isn’t really a new problem.

Author: frangio
Date: 2024-10-08T12:56:08.199Z

I think the difference is that for that to happen the account had to have selfdestruct or delegatecall in its code, so observing codehash (with known preimage) you would know the code could change. Now the code change can be a “surprise” because there is no indicator.
This would be solved making EXTCODE* not follow delegations.

Author: peersky
Date: 2024-10-08T13:48:49.246Z

Wouldn’t it break the 7702 provided functionality itself? E.g Externally called contracts that rely their isContract on hash?

Author: matt
Date: 2024-10-08T14:14:00.149Z

Right, but what exactly is an example where a “surprise” code change would cause harm? In general you either fully trust the code you’re calling into or you don’t trust it at all and must be defensive.

Author: frangio
Date: 2024-10-08T18:19:51.310Z

An example would be a contract that transfers tokens to an account only if its codehash is the known codehash of a timelock, assuming the rules of the timelock will be respected. With EIP-7702 an EOA would be able to masquerade as a timelock and bypass the restrictions.



 matt:

you either fully trust the code you’re calling into or you don’t trust it at all and must be defensive


In the example above you trusted the known code, and you reasoned you could trust the account on the basis of its codehash.
This is a little contrived. In practice the contract would probably deploy the timelocks itself rather than checking the codehash, or it would require a CREATE2 address and validate the entire creation code and parameters.
I searched superficially and wasn’t able to find real world examples that would be vulnerable to this kind of attack. But it doesn’t sound that far-fetched to me.

Author: nathanglb
Date: 2024-10-08T19:53:21.286Z

This is a great find, and highlights why some of us have been concerned about rushing 7702 to production.

Author: nathanglb
Date: 2024-10-08T20:11:04.315Z

Creator Token Standards offers a system to add a validator which can introduce logic gates into transfers, enabling many new use cases.  For flexibility, the reference validator implementation allows creators to whitelist operator code hashes that they trust that are allowed to receive tokens or be operators on tokens.
I don’t think it is that far-fetched to think that masquerading as a whitelisted operator or receiver code hash could lead to a security incident (depending on what the underlying code does).  This protocol is very generic though, so I would say the severity of masquerading as a whitelisted code hash could range from no impact to critical impact.
Fortunately, there is no “Authorizer Codehash” list in this current reference implementation, but had there been an EOA could masquerade as an authorizer and possibly do some damage as well.


github.com


limitbreakinc/creator-token-standards/blob/main/src/utils/CreatorTokenTransferValidator.sol#L1744-L1882

      
          function _validateTransfer(
              function(address,address,uint256) internal view returns(bool) _callerAuthorizedParam,
              address collection, 
              address caller, 
              address from, 
              address to,
              uint256 tokenId
          ) internal view returns (bytes4,uint16) {
              if (caller == address(this)) { 
                  // If the caller is self (Permit-C Processor) it means we have already applied operator validation in the 
                  // _beforeTransferFrom callback.  In this case, the security policy was already applied and the operator
                  // that used the Permit-C processor passed the security policy check and transfer can be safely allowed.
                  return (SELECTOR_NO_ERROR, DEFAULT_TOKEN_TYPE);
              }
          
              CollectionSecurityPolicyV3 storage collectionSecurityPolicy = collectionSecurityPolicies[collection];
          
              uint120 listId = collectionSecurityPolicy.listId;
          
              (uint256 callerConstraints, uint256 receiverConstraints) = 
      
    


  This file has been truncated. show original

Author: matt
Date: 2024-10-08T21:07:14.230Z

frangio:

This is a little contrived. In practice the contract would probably deploy the timelocks itself rather than checking the codehash, or it would require a CREATE2 address and validate the entire creation code and parameters.
I searched superficially and wasn’t able to find real world examples that would be vulnerable to this kind of attack. But it doesn’t sound that far-fetched to me.


Yeah this was is also my initial reaction. I’m open if there are more practical examples, but it doesn’t seem like a major issue. And if you need to be certain about some code, just deploy it yourself.



 nathanglb:

and highlights why some of us have been concerned about rushing 7702 to production.


7702 definitely isn’t being rushed to production . 7702 is going to slightly change how protocol designers need to think about their protocols. It’s possible to come up with contrived protocols that have issues, but there are ways to work around.

Author: nathanglb
Date: 2024-10-08T21:10:58.841Z

What about the example protocol we have in production that I referred to in this post?




EIP-7702: Set EOA account code for one transaction EIPs core


    Creator Token Standards offers a system to add a validator which can introduce logic gates into transfers, enabling many new use cases.  For flexibility, the reference validator implementation allows creators to whitelist operator code hashes that they trust that are allowed to receive tokens or be operators on tokens. 
I don’t think it is that far-fetched to think that masquerading as a whitelisted operator or receiver code hash could lead to a security incident (depending on what the underlyin…
  

It’s not actually contrived.  We added operator code hash whitelisting at the request of token creators, and depending on what gets whitelisted, I could see the possibility of a bad impact.

Author: 0xth0mas
Date: 2024-10-08T21:20:02.113Z

matt:

Yeah this was is also my initial reaction. I’m open if there are more practical examples, but it doesn’t seem like a major issue. And if you need to be certain about some code, just deploy it yourself.


Do you have any links to research that has been done into how EXTCODEHASH is being used in smart contracts and analysis of the potential security implications for ones that are using it? A GitHub search finding even one example likely means there are more out there in the wild.

Author: mitche50
Date: 2024-10-08T21:31:45.634Z

7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.
Defaulting to “I’m open if you can provide a practical example” is not really a legitimate reply. Changing the functionality of an ecosystem which has billions of dollars of funds reliant on immutable code should warrant a deep testing period, public test nets, prepared wallet integration and testing, public knowledge documentation and more. Application developers are barely aware of the implications of this, and previously deployed protocols will need sufficient time to migrate or upgrade code.
This can’t be a “bury our head in the sand and hope nothing bad happens” moment.

Author: nathanglb
Date: 2024-10-08T21:40:16.811Z

I think a reasonable suggestion is to add 2 opcodes.  One opcode that is cheap (2 or 3 gas) to check if 7702 is in play.  The other would be an delegatedextcodehash op code that is the code hash that is attached.  Leave the original extcodehash as is.

Author: WOK
Date: 2024-10-08T21:46:32.710Z

With an impending implementation date of “Early 2025,” when can we expect a test environment? This is a change that has the potential to affect all network participants in a way that is more dramatic than most previous upgrades. The end of 2024 is quickly approaching…

Author: frangio
Date: 2024-10-08T21:51:49.507Z

matt:

I’m open if there are more practical examples, but it doesn’t seem like a major issue.


It’s not major, but if there’s a simple fix I think it’s worth considering.
The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only. I’m undecided whether EXTCODE* opcodes should operate on the full delegation designator, or if they should behave like EOF contracts and act as if the code was just 0xEF01. In either case this would make delegated accounts a lot more like proxies so should be less surprising.

Author: abcoathup
Date: 2024-10-08T23:57:59.549Z

There is a public testnet for Pectra planned to run during Devcon.  This will be a great time to test, experiment and even break functionality if you can.

Author: rdvorkin
Date: 2024-10-09T07:36:02.144Z

Did some gas cost analysis comparing sweeping under 7702 to 3074. You can check out the findings here:
https://hackmd.io/3PsQucEESHSSzXaWNrnDOg
TLDR: Sweeping is 3x more expensive with 7702 than 3074, which impacts end users.
While we’ve moved beyond 3074, I wanted to raise awareness about the cost implications of 7702, which haven’t been discussed much. Is there any potential for cost improvements in this use case, particularly when delegating multiple EOAs to a single contract in a single transaction? Thoughts are welcome.

Author: matt
Date: 2024-10-09T12:35:39.660Z

Cheap sweeping isn’t a goal of 7702.

Author: chfast
Date: 2024-10-09T14:23:23.085Z

You could have used the delegation designator prefix of 0xEF ++ MAGIC, i.e. EF05.

Author: peersky
Date: 2024-10-09T14:24:15.186Z

Point is that if before account could selfdestruct, and leave any assets locked in there hanging, hence worst of what attacker may attempt to do today is cause harm to the protocol by draining it, yet it will not be able to withdraw funds.
Now with this EIP, it’s EOA, which is able to control these assets, and hence it creates legitimate attack vector that pays back to attacker.
I also assume, that’s obvious that there are numerous assertions that will become faulty via isContract, like this ? Such checks, if checking for isContract==true, will result fault assertions that account cannot send auxiliary transaction while it can.

Author: nathanglb
Date: 2024-10-09T17:00:57.163Z

This one might not be as big of a deal, because OZ’s isContract function already had some noteable workarounds like contracts in construction, counterfactual addresses, etc and thus was already unreliable.

Author: dror
Date: 2024-10-14T06:17:09.372Z

I think that eip7702 contract behaves more like an erc1967 than like a real deployed code.
Just like a proxy code, no one expect to rely on the code of the proxy itself, as the owner might change it.
Eip7702 contract is a low level modifiable proxy, and should not attempt to hide it.
That why it should be visible to the EXTCODE* opcodes, and they should use its real 0xEF… code, not the delegated contract.

Author: hiddenintheworld
Date: 2024-10-14T17:18:26.554Z

Flag Triggering:

How does the flag work to make an EOA a permanent smart contract wallet?
Is the flag set during the transaction? Can the same contract_code be reused, or is it one-time(will be dumped afterwards)?
Will users need to sign off on this change explicitly, or could it happen automatically?
@vbuterin @SamWilsn



Expensive Transactions:

Complex contract_code or initcode might need a lot of gas, especially with things like signature checks or calling external contracts.
Could this make transactions too expensive for users with less ETH? Should there be limits on how complicated the code can be to keep costs down?
@dror



Interaction with ERC-4337:

What happens if an EOA temporarily becomes a contract wallet and interacts with EntryPoint contracts in ERC-4337?
If contract_code or initcode reverts in the middle of a transaction, could this cause invalid UserOperations (UserOps)?
Could this lead to issues with how ERC-4337 handles these failures, maybe even causing a denial-of-service (DoS) attack on the AA mempool?
@Ivshti @0xkvn



Unintended Behavior in UserOps:

Reverts in contract_code or initcode could cause a bunch of UserOps to fail, especially if the code checks something like the block timestamp and cancels the operation.
Could this lead to a mass invalidation of UserOps, clogging the AA mempool and causing DoS-like behavior?
Also, what about cross-chain replay attacks if the contract_code is chain-agnostic and can be exploited across different networks?
The only way it works is to ask each bundler to inspect initcode which is extremely inefficient, so we must find a way to work around this.
@yoavw

Author: Ivshti
Date: 2024-10-15T05:32:11.624Z

The basic fix I have in mind is that EXTCODE* opcodes shouldn’t follow delegations, the delegation logic would be used in *CALL opcodes only.

This (EXTCODE* not following delegations) will break EIP-1271/EIP-6492 signatures and has very few upsides.

Author: Ivshti
Date: 2024-10-15T05:43:06.773Z

7702 is absolutely being rushed to production. The EIP was written in 30 minutes in May and is slated for the next production release.

That’s absolutely not what happened, there were multiple iterations, discussions and etc. Most of the concerns and points I’m seeing here in this thread have already been discussed, and most (if not all) of the compromises have been very carefully and deliberately weighted.
As for the attack vector itself, authorizing code hashes sounds like a risky idea from a security perspective in the first place. Analyzing for real-world examples is absolutely the right thing to do - if we bogged down in hypotheticals then it would be even harder to get this to production.

Author: matt
Date: 2024-10-15T12:25:03.793Z

Ivshti:

This (EXTCODE* not following delegations) will break EIP-1271/EIP-6492 signatures and has very few upsides.


Could elaborate on this? AFAIK those EIPs only check for existence of code? e.g. proxies work with them today.

Author: Ivshti
Date: 2024-10-15T13:31:04.020Z

I meant if EXTCODE* doesn’t follow delegations and behaves as if there’s no code for EOAs with a delegation (what @frangio is proposing), EIP-6492 and EIP-1271 will not work.
In the current state of EIP-7702, both EIPs work fantastically thanks to the Delegation Designation.
@matt

Author: frangio
Date: 2024-10-15T13:45:43.102Z

The proposal is not for EXTCODE* to ignore delegations, just to not follow the delegation pointer, so for example EXTCODECOPY would copy the delegation designator itself. IMO this makes delegations less special (just built in proxies) and should be the default spec unless we have really good reasons to do more (like the current spec).

Author: mitche50
Date: 2024-10-16T00:38:55.735Z

It would be nice to have some of these compromises made public. 0xth0mas raised a good point in asking if there has been any links to research on how things like EXTCODEHASH is being used in protocols / security implications. The EIP specifically only mentions msg.sender == tx.origin being broken, but no mention of any real other security threats. There are already concerns regarding EXTCODEHASH raised in here not mentioned in the EIP. Changing expected functionality of existing operations when any number of smart contracts could rely on them for security does not seem like something that should be thrown to the side due to a small group weighting them.
Do we really think a short testnet before including in next hard fork is an appropriate amount of time? To be honest, smart contract wallets exist currently and AA is not a pressing concern to move to production ASAP. AA is a great UX level up, but UX doesn’t matter if protocols are being exploited as a side-effect and users are presented transactions they’re not familiar with.
I don’t mean to be overly passionate about this being rushed, but Ethereum is a base protocol supporting over $40b in protocols, potentially written with assumptions being violated by this EIP. Extreme care should be taken with upgrades like this need to be taken with every opportunity granted to client facing applications to adapt to changes needing to be granted.

Author: wjmelements
Date: 2024-10-16T03:39:57.655Z

matt:

I don’t really understand this point, can you expand on the issue? IMO until cancun, it was possible to selfdestruct an account and deploy alternative code. So an account having different code isn’t really a new problem.


Removing selfdestruct added a security guarantee that the code wouldn’t change. This was part of the rationale for both removing selfdestruct and blocking setcode. This objection is likely the end of this EIP for the same reason.

Author: mrnerdhair
Date: 2024-10-16T06:09:56.777Z

matt:

Cheap sweeping isn’t a goal of 7702.


7702 seems to enable a lot of things that aren’t its express goals. They all need to be analyzed, however. 7702 is a massively powerful tool, so we have to get it right the first time. 7702 will be the only practical way to do EOA transaction batching; it would be unreasonable to assume it won’t be used that way. I submit that as the scope of 7702 is significantly larger than the sum of its goals, we should not use “not a goal” as a justification to ignore considerations as “out of scope” – especially as it seems practically impossible to prevent (or even substantially disadvantage) uses which do not align with the authors’ initial motivations.
The use of 7702 as a general-purpose protocol-level proxy system is another use case which seems inevitable due to economic considerations. Single-shot deterministic signatures can immutably create such a proxy but cannot initialize it, as the only frontrunner-safe way to handle initialization is to submit a TX from the EOA so that the enclosing TX will first bump the EOA’s nonce as a prerequisite to the delegation authorization’s validity and then call an initialization function. This requires two signatures from the same address, and is therefore impossible to do via a deterministic signature.
Paradoxically, this will leave mutable proxies with a security advantage over immutable ones, though at least immutable ones would be guaranteed to start with blank storage!
Another odd case is that an ordinary “safe” initialization transaction, sent from the EOA being delegated, is intercepted and censored. The user might well eventually “cancel” the “failed” TX by using the nonce in a zero-value standard transaction. This would allow the attacker to use the otherwise-invalid authorization to set the delegation themselves, at which point they could call into an uninitialized contract for undefined behavior (undefined, as redelegation could leave arbitrary leftover storage).
A solution to this problem might be for wallets to issue “cancellation” transactions with an extra no-op delegation embedded to double-bump the EOA nonce, ensuring a pending delegation would be invalidated, but that costs extra gas and would require the user to use an updated wallet for safety.
I’d like to see some official way to condition an authorization on the call of an initializer. I don’t know exactly what that would look like, but it would solve both these problems.

Author: holiman
Date: 2024-10-16T12:44:28.743Z

First of all, apologies – this is a long thread, and while I’ve skimmed the recent conversation, I have not read the entire thing. I came here from reviewing the PR in geth, and diving into the EIP itself.
The eip title is, literally “Add a new tx type that sets the code for an EOA during execution”, and the title of this discussion is “EIP-7702: Set EOA account code for one transaction” (emphasis mine). But from the EIP body, and the implementation, I now understand that these changes are permanent/global.
In earlier iterations, this setting of code was temporary - scoped to the transaction. Meaning that whoever who sent the transaction was the one who could to a degree decide what state he wanted to replace. If they control account X, they can decide to temporarily set some code there, and execute code on their own behalf. They could also combine other auths, and “synthesise” the environment which their transaction interacted with.
Change since then seems to be:

make the auth nonce mandatory. Nice for security!
make setting the code global/persistent. This, in my opinion, is a huge change! This totally throws previous guarantees about code immutability out the window, creating new insta-upgradable contracts. Contracts which change from one transaction to the next, without any form of selfdestruct in-between.

Seems to me as if a gigantic change which should be headlined was just silently slipped into the EIP.

Author: matt
Date: 2024-10-16T15:45:07.135Z

holiman:


make setting the code global/persistent. This, in my opinion, is a huge change! This totally throws previous guarantees about code immutability out the window, creating new insta-upgradable contracts. Contracts which change from one transaction to the next, without any form of selfdestruct in-between.

Seems to me as if a gigantic change which should be headlined was just silently slipped into the EIP.


I just updated the EIP description here, so should not have that confusion anymore.
However, I would push back pretty hard on saying this was silently slipped into the EIP. The PR to make the change to the spec was open for a month and was discussed in ACDE 190, 191, 192, in two breakout rooms on the topic (1, 2), and in many more chats on discord and telegram.

Author: ArikG
Date: 2024-10-16T16:12:50.145Z

While I was not supporting the change itself (seeing the value in temporary delegation in some use cases), I do want to support Matt’s latest point - the topic was indeed discussed heavily and eventually the decisions was made to approve this change after extensive debate on the topic as it was considered as the best tradeoff option between multiple concerns.

Author: holiman
Date: 2024-10-16T18:46:31.639Z

matt:

However, I would push back pretty hard on saying this was silently slipped into the EIP


My apologies, it was badly put. It was not silently slipped into it. However, it was such a fundamental change that it’s basically a new EIP, in my opinion.

Author: nathanglb
Date: 2024-10-16T19:59:30.388Z

Imagine I’m somebody with significant amount of crypto assets in my EOA.  I stumble upon a bad site where I accidentally sign a message to permanently upgrade my EOA to a smart contract that does nothing, permanently bricking my EOA and locking my assets away forever.
Editing my reply since I just saw the comment above with the PR.

Author: mrnerdhair
Date: 2024-10-16T20:04:35.208Z

nathanglb:

Did the proposal just change today to make this a permanent migration of an EOA to an SCA?


That was probably just a suboptimal word choice intended to contrast with the previous (incorrect) “during execution” wording. AFAIK no proposal has been made to introduce a way to allow a delegation to be made permanent.

Author: nathanglb
Date: 2024-10-16T20:07:08.147Z

Screenshot 2024-10-16 at 2.06.46 PM1593×538 55.4 KB
I’m not sure - this seems pretty clear?

Author: mrnerdhair
Date: 2024-10-16T20:10:56.829Z

I think it means “permanent” as its used in “permanent residence,” and would perhaps be better described as “persistent.”  Otherwise, the “behavior” section would also have had to have been updated to replace

Verify the code of authority is either empty or already delegated.

with simply

Verify the code of authority is empty.

Author: matt
Date: 2024-10-16T20:16:48.203Z

holiman:

My apologies, it was badly put. It was not silently slipped into it. However, it was such a fundamental change that it’s basically a new EIP, in my opinion.


This is a good point. I feel like we iterated quite a bit from where it started. Probably would have been good to freeze the EIP at some point and create a new number. But that also has some overhead cost to coordinate people around a single spec.



 nathanglb:

I stumble upon a bad site where I accidentally sign a message to permanently upgrade my EOA to a smart contract that does nothing, permanently bricking my EOA and locking my assets away forever.


Random websites can’t request you sign 7702 txs, you would have to set up an entire wallet and give it your seed phrase.
But yes, you can change the delegation designation for you account or even remove it completely. The key retains control of what code lives in its account.

Author: mrnerdhair
Date: 2024-10-16T20:23:50.834Z

matt:

Random websites can’t request you sign 7702 txs, you would have to set up an entire wallet and give it your seed phrase.


It’s not a good idea to make a security argument from the absence of a feature. A standard mechanism for requesting delegation signatures will have to exist at some level and at some point to support hardware wallet users, and I would be flabbergasted if it doesn’t get integrated into the standard web3 api. Sure, wallets will probably have a variety of hoops and huge flashing lights before letting you click the button, but its simply wrong to presume that websites won’t be able to request this type of signature. (And if that were a security-relevant issue, it should be in the EIP with a big fat MUST NOT!)

Author: matt
Date: 2024-10-16T20:50:07.962Z

mrnerdhair:

It’s not a good idea to make a security argument from the absence of a feature. A standard mechanism for requesting delegation signatures will have to exist at some level and at some point to support hardware wallet users, and I would be flabbergasted if it doesn’t get integrated into the standard web3 api. Sure, wallets will probably have a variety of hoops and huge flashing lights before letting you click the button, but its simply wrong to presume that websites won’t be able to request this type of signature. (And if that were a security-relevant issue, it should be in the EIP with a big fat MUST NOT!)


We should make this clearer in the EIP that this is the expectation. It’s a free world and wallets can do what they want, however after considering the possibilities I think wallets will understand that they cannot allow this API in an unrestricted manner to their users. This as been a central piece of the 3074 and 7702 discussion for years.

Author: mrnerdhair
Date: 2024-10-16T21:09:41.470Z

Let me clarify that I don’t take issue with the premise that these signatures are security-critical and that wallets must keep the tightest control over whatever API is used to create these signatures; I just didn’t think the literal words you typed were accurate (that the only way to screw up and make a 7702 signature is to type in your seed phrase because an API for dApps to request one will never exist). I fully support the sentiment that giving someone root will be hard enough that if you screw up it’s your own fault.
Also, I’d like to say that while I’ve been (and will be!) critical of certain aspects of 7702, I’m also very much in favor of it. I want this to happen and I think the ecosystem needs it to happen. It’s potentially dangerous, but I think it can be done right and I want to actively help make sure it is, not by stopping progress but by pitching in to drive it forward.
Thank you for all the work you’ve put into this EIP and the slings and arrows you’ve undoubtedly weathered through the process.

Author: mrnerdhair
Date: 2024-10-16T22:53:17.250Z

I’ve been doing a bunch of analysis of 7702; here’s a summary of the remaining issues I see. I hope it helps.
Delegate Initialization
The Problem
Most contracts need to be initialized. (Even contracts which can correctly handle starting with empty storage won’t be able to rely on that when they’ve been redelegated to.) 7702 currently has a section on the undesirability of initcode which says

the lack of programmability in the decision will force wallets to not sign many authorization tuples and instead focus on signing only a tuple pointing to a configurable proxy.

I don’t get this; even configurable proxies require initialization, which 7702 offers no simple way to ensure. (I really hope this isn’t just a case of me being obtuse.)

It’s correctly stated by 7702’s security considerations section:

To secure the account from an observer front-running the initialization of the delegation with an account they control, smart contract wallet developers must verify the initial calldata to the account for setup purposes be signed by the EOA’s key using ecrecover.

Due to the lack of the ability to atomically call initialization code, however, a contract will need to consider that it may be called in a context where is has not yet been correctly initialized. The only way to detect this state is to use at least one storage slot (a minimal implementation would just contain an “initialized” flag), meaning at lease extra 2103 gas to SLOAD and check the flag on every call. (That’s almost optimally inefficient; almost every call will can be expected to be made while the contract is properly initializated, but will need to pay to check each time.)
Worse, though, the location of this flag is necessarily deterministic. This makes it impossible for a contract author to be certain their initialization code has actually been run, as a user could have previously delegated to a contract which wrote to whatever storage slot is to be used for the flag. We don’t even need to consider the EOA key holder or previous delegation target to be an adversary for this to be an issue! A user could have previously delegated to a legitimate contract which (via bug, oversight, or justifiable exclusion from its own threat model) allowed an unauthenticated caller to set the storage slot that the new delegation target will be using.
It will also tempting for ownable contracts to use the owner != 0x0 as the initialization flag, which would cause problems because the storage slot used for storing an owner value is often the same between contracts. Improving this (not actually making it safe, just disarming the footgun) would require salting the storage slot used for the initialization value with some combination of ADDRESS and CODEHASH (and probably an extra KECCAK256) on every single call.
Best Current Workaround
A user will need to sign two messages to correctly delegate: one 7702 delegation authorization and one covering an initialization payload. This will be a pain for hardware wallet users, and probably leads additional attack surface area; what might happen if the initialization payload signatures and delegation designator signatures can get mixed up? Since a contract can’t rely on storage values before initialization, and can’t access the EOA’s nonce value, the available anti-replay protection for an initialization call is limited to verifying an expiration timestamp in the signed initialization data.
Unfortunately, now we’re stacking workarounds on top of workarounds to fix a fairly fundamental issue, and it would be very very easy to get some of this wrong.
Ironically, one of the only cases where this can be done correctly would be deterministic-signature deployment of a correctly-initialized proxy. The arbitrary data used in the signature fields could be repurposed as a commitment to the calldata of a subsequent initialization function, and such an account can only ever generate one signature, ensuring that no other signed initialization data which can be replayed could ever exist.
Possible Solutions


EOAs submitting their own delegation TX can atomically call a setup function which uses ecrecover to check its calldata. If this is made, by convention, the “correct” way to deploy a certain contract, the contract will never be in a bad state unless the user has, by definition, screwed up. This would avoid the cost of loading and checking an initialization flag after each call, but is incompatible with gas sponsorship, because it only works if the EOA submits the delegation in its own transaction (since the TX itself will bump the nonce value, preventing the delegation from being used by frontrunners).


7702 could define a well-known “initialization flag” slot and guarantee that setting a delegation resets the slot to a known value. An ecrecover-based technique would still be required to authenticate initialization, which would still require two separate signatures for “real” EOAs, and it would still require the overhead of loading & checking an initialization flag on every call. However, this would be a relatively minimal change to the EIP with limited side-effects and would support gas sponsorship. (For bonus points, I could imagine the slot could be marked “warm” after traversing a delegation designator.)


7702 could either always clear the account’s storage when setting a delegation or offer a authorization flag which did so. This would share most of #1’s advantages and disadvantages but would be the smallest possible change to the EIP and also ensure contracts started with a known state and couldn’t e.g. forget to initialize leftover security-critical slots.


As #3, but add an extra bytes32 value as part of the authorization tuple which could be used as (or as a commitment to) initialization data and set the well-known initialization flag slot to the provided value on processing the delegation. This would avoid the need to generate two signatures and avoid an ecrecover cost in the initialization function, but it would not fix the need to load and check the flag for each call.


7702 could define an (optional?) bytes calldata value as part of the authorization tuple and call into the contract with it (if it’s non-empty?) after setting the value. This would avoid the double-signature issue, support gas sponsorship, ensure atomicity of initialization, and avoid the need to check an initialization flag. It would, however, make the gas cost of processing a delegation record variable, make it possible for the call to revert, and generally go against many of the decisions already taken for this EIP.


A second type of delegation designator (say, 0xef0101) could be created which would represent a delegation to an as-yet-uninitialized contract. Such a delegation designator could only be used as the target of a CALL or the destination of a transaction, and only calldata starting with a well-known string (practically, the selector for a well-known initialization function) would be accepted. Such a call would swap the delegation designator from the 0xef0101 to the normal 0xef0100 type. This would avoid the need for contracts to keep track of their initialized/uninitialized state, while remaining compatible with gas sponsorship and suchlike. (Frankly, I’m spitballing on this one; all I can say is it’s less inelegant than some other options.)


Conclusions
I feel that something’s gotta be done because initializing code is such a common usecase. None of these solutions are, however, ideal – hence the braindump. I look forward to someone coming up with a better solution (or even figuring out some convincing argument that it’s not a problem at all).
Re-delegation
A user who wishes to delegate to a contract wallet which is itself upgradable will either be required to accept the extra per-operaton overhead associated with delegating to an 1167-style proxy or the need to break out their EOA key to sign each re-delegation pointing to the new code. Perhaps if we solved this problem by allowing programmatic redelegation we could use it to also solve the initialization issue? A user could initially delegate to a contract that only contained setup code, which could then redelegate to the full contract. (As I understand it, much of the pushback on SETCODE was that we should instead be implementing a first-class protocol proxy mechanism, which is what 7702 effectively is.)
Delegation Introspection
Edit: So if I’d noticed PR #8969 I would have just said I think it’s a good idea and saved everyone reading the next 1k words. Sorry about that.
It’s totally doable
Consider the following arrangement:
A → B → C → D

A is an EOA initialized via deterministic delegation signature to point to B
B is an EOA with a well-known private key which anyone can use to set a delegation from
C is the EOA being introspected for delegation
D is a contract being delegated to by C

A contract interested in verifying the delegation target of C runs EXTCODECOPY on A and receives the contents of the delegation designator at B. It verifies that this designator is points to C, and rejects if it does not, possibly with a error message structured to indicate to someone simulating the transaction which delegation authorization needs to be set. The verifying contract can then use EXTCODECOPY on B to retrieve C’s delegation designator, revealing that C delegates to D.
A 7702 transaction can be built, possibly for submission via a 4337-style transaction submission market, which contains the B → C delegation and thereby ensures that introspection is possible atomically.
Conclusions
Introspection via this mechanism is possible. Therefore, there is technically no need to add an “official” introspection mechanism. Future contracts which really care about checking delegations can technically roll their own introspection machinery independently of this EIP.
Current contracts may, however, be broken without the ability to check a delegation designator. A variety of systems use code hash whitelisting – it’s literally the reason EXTCODEHASH was added! Sure, lots of those systems embed a incorrect assumption that the code they can check was correctly initialized by initcode which they can’t, but it is still possible to set up systems that use EXTCODEHASH as a security mechanism and work correctly.
Take, for example, a DeFi vault which can allocate funds to investment strategies represented by contracts. Each of these contracts’ code is whitelisted, and deployment of a new investment strategy consists of CREATE2-ing a fresh EIP-1167 proxy to an account with the known-good code. (I’ve seen a similar scheme in practice before.) One advantage to this solution is bypassing the problem of cross-chain contract deployment having nondeterministic addresses; the code will be the same on each chain, so a signed whitelist permit can be used on every chain even though the new proxy will point to the code via an address which may be different on each chain.
If the demand for this sort of introspection is inevitable, we must accept (or, not to put too fine a point on it, will be tacitly accepting) one of the following things:


Permanent on-chain storage of the repeated delegations and re-delegations needed for these checks, as well as one of the following:

Increased fragmentation caused by competing implementations of external TX building schemes which support setting 7702 delegations, and the associated loss of decentralization associated with the reliance of a protocol or contract on an possibly limited set of external transaction builders compatible with a fragmented scheme
The added complexity in 4337 (or another new EIP) needed to support setting 7702 delegations via a standard external-TX-building mechanism
The added complexity in 7702 needed to support setting delegations programmatically (which would enabling introspection via this technique but without relying on external TX builders)



The added complexity in 7702 needed to support direct introspection of delegation designators.(Perhaps this could be a new opcode, but it could also be a compromise on the operation of EXTCODESIZE/EXTCODECOPY/EXTCODEHASH for delegation designators).

Author: frangio
Date: 2024-10-17T01:30:01.886Z

mrnerdhair:

the storage slot used for storing an owner value is often the same between contracts


For this and other storage slot reuse concerns, the Solidity team has been working on a way to compile contracts whose storage layout starts at a location other than 0: ethereum/solidity#597
The idea is that different account templates would use non-overlapping storage layouts.
There’s definitely a big risk of screwing things up. I would basically never recommend someone switch from one account implementation to an entirely different one. At least not without first sweeping the entire storage clean…



 mrnerdhair:

extra 2103 gas to SLOAD and check the flag on every call


This is unlikely to cost this much. The flag can probably be packed with other values that need to be accessed to authenticate UserOps.
I’d also say it’s very possible to have account templates that don’t use storage at all. I’d prefer to use those myself. The signing key can be the EOA itself and accessed via address(this), and nonces are handled by the ERC-4337 Entrypoint. Not sure if I’m missing anything else one would put in storage.
It would be nice to atomically bundle an initialization call with the delegation itself though.

Author: mrnerdhair
Date: 2024-10-17T02:23:22.252Z

frangio:

At least not without first sweeping the entire storage clean…


I’m not even sure there’s a practical way to do that on-chain as things stand. Best I can figure, you’d need to redelegate to a stateless slot-wiper contract, enumerate all used storage slots via RPC calls on the client side, build a TX to call into the wiper with the slot keys to clear them, and then redelegate. (That’s a heck of a lot of overhead for (part of) what SELFDESTRUCT used to be able to do for 5000 gas!)
Surely resetting storage (or at least running an initializer of some kind!) is a basic thing that should be possible to keep redelegation from being generally regarded as impractical and unsafe. I can, however, imagine both cases in which storage should be wiped on redelegation (major upgrades, switching wallet “brands”) and cases where it should not (minor updates within the same wallet “brand”).
Maybe the special case of delegation to 0x0, which clears code entirely, should also wipe storage? That would allow a redelegation to be done either directly (keeping storage) or via an intermediate undelegation (wiping storage) and require only a minimal update to the EIP. It wouldn’t be the same thing as atomic initialization, but it would be a significant start!



 frangio:

I’d also say it’s very possible to have account templates that don’t use storage at all.


Can you elaborate on this for me? I can definitely imagine a contract which doesn’t use storage, but the techniques I’m imagining seem like they would imply significant functional limitations.

Author: frangio
Date: 2024-10-17T16:41:48.616Z

A basic EIP-7702 account template that provides batching doesn’t need any storage or initialization. Here’s a possible example.

Author: joeblogg801
Date: 2024-10-19T19:20:08.987Z

I reviewed the spec and have concerns with the following part:

If any of the above steps fail, immediately stop processing that tuple and continue to the next tuple in the list. It will in the case of multiple tuples for the same authority, set the code using the address in the last valid occurrence.
Note that the signer of an authorization tuple may be different than tx.origin of the transaction.
If transaction execution results in failure (any exceptional condition or code reverting), setting delegation designations is not rolled back.

As the transaction originator, I would prefer the transaction to fail earlier if the result of applying the algorithm to authorization tuples does not yield a known good configuration. I should be able to specify what that configuration looks like, and if it’s not met after processing the authorization tuples, the transaction should:
a) Fail, and
b) Revert any changes made to delegated designations.
Here’s a scenario: An attacker signs an authorization to change a delegated designation to a known good contract. They then monitor the network and when the transaction that includes this authorization is sent they quickly send another transaction to switch the delegated designation to a malicious contract. In this case, when processing a transaction that includes an authorization to change delegation to a known good contract the alogirthm will not make a switch (because the nonce will be invalid) and transaction would execute in an environment where the delegated designation points to the malicious contract. As a transaction sender, I don’t want my call to execute under such conditions, with potentially unknown side effects. I’d much rather have the transaction fail early without execution.
To avoid this issue, I propose a simple solution: the transaction originator should be able to specify a set of expected (address, contract_address) pairs before code execution begins. If, after processing the delegation changes, the expected configuration isn’t met, the transaction should fail, preventing any further code execution.

Author: frangio
Date: 2024-10-19T20:12:18.680Z

joeblogg801:

As a transaction sender, I don’t want my call to execute under such conditions, with potentially unknown side effects. I’d much rather have the transaction fail early without execution.


With my pending proposal it’s possible to verify the delegation target of an account before interacting with it, using EXTCODECOPY.



 joeblogg801:

b) Revert any changes made to delegated designations.


This opens up a more serious vulnerability where a single delegator can cause an entire batch of delegations to fail. I don’t think that would be the right trade-off.

Author: mrnerdhair
Date: 2024-10-19T20:35:27.034Z

Good catch! I agree with @frangio that #8969 seems a good fit here. (Though I was thinking yesterday that maybe it would be a good idea to leave CODESIZE and CODECOPY transparent and only change the EXT* opcodes?)
It would add a bit of extra gas, but would checking the delegation target via EXTCODECOPY satisfy all the usecases you can think of? There are valid (esp. cross-chain) usecases for not failing on invalid designators, so it would be great if we could keep that functionality.

Author: mrnerdhair
Date: 2024-10-19T20:56:10.605Z

(To expand on those cross-chain usecases, one that comes to mind is that you could synchronize nonces across different chains by signing a series of null delegations with a 0 chainId and incrementing nonces, and then you can follow that up with a single chainId 0 delegation with the subsequent nonce.)

Author: joeblogg801
Date: 2024-10-19T22:26:10.291Z

In case a delegation designator points to another designator, creating a potential chain or loop of designators, clients must retrieve only the first code and then stop following the designator chain.

Just to clarify, does this mean that when invoked, the EVM will attempt to execute 0xef0100 || address, and since 0xef is an invalid opcode, it will consume all the gas specified in the call and fail?

Author: joeblogg801
Date: 2024-10-19T23:20:37.488Z

This requires the contract to have a verification code. I feel that a declarative approach is conceptually simpler, where, as a transaction originator, I can specify that certain addresses should have a particular code before execution begins.
Could you explain how reverting any changes made to delegated designations could cause an entire batch of delegations to fail? I assume this might happen if a subsequent transaction relies on authorization nonces already being incremented.
I’m not too concerned about reverting the authorization changes, as long as I can be sure that the transaction executes against the expected delegated designations. Initially, I thought there might be cases where it’s critical for delegated designations to be updated atomically—i.e., either both accounts update their delegated designation, or neither does—otherwise, there’s a potential security risk. However, I realize the current design doesn’t offer protection against this.
If such a vulnerability were to exist, an attacker could simply monitor transactions and unbundle the changes to the delegation designation.
Considering this, is there a security risk in the following scenario? The victim sends a transaction authorizing a change in delegated designation for an address to a particular contract. They also send a second transaction authorizing a change in delegated designation for the same address to another contract. Meanwhile, the attacker listens for these transactions and bundles both authorizations into their own transaction, executing it before the victim’s first transaction.
When the attacker’s transaction is executed, it performs two changes to the delegated designations. As a result, the victim loses the first authorization and cannot change the delegated designation to the first contract. Consequently, the victim is unable to execute their intended actions in the first transaction, which now executes with the delegated designation pointing to the second contract.

Author: mrnerdhair
Date: 2024-10-20T00:50:56.313Z

In reverse order:



 joeblogg801:

Meanwhile, the attacker listens for these transactions and bundles both authorizations into their own transaction, executing it before the victim’s first transaction.


If you build a TX with your own delegation authorization embedded, the nonce will bump once for the TX (signed with nonce n) and then a second time for the signature on the delegation designator (signed with nonce n+1). So an attacker couldn’t unbundle the designator and broadcast it themselves, since while they’re frontrunning you the nonce won’t equal n+1. This only works if a TX is submitted via the same EOA that’s delegating, though, meaning they would have to have Ether to cover the gas.



 joeblogg801:

This requires the contract to have a verification code.


I was thinking more along the lines of using a generic “check delegations & dispatch” contract. A transaction submitter could delegate to such a contract and then call into it with require(msg.sender == address(this)) and a series of delegations to check via EXTCODEHASH and the target/value/calldata to use if they succeed. (One possible kink here is that while the submitter can easily ensure their delegation to such a contract is processed before the call, they can’t reset it afterwards without broadcasting another transaction.)

Author: dror
Date: 2024-11-15T04:42:04.901Z

A suggestion for EIP-7702:
Currently, if you’re trying to use EIP-7702 inside a higher level transaction (e.g. use ERC-4337 paymaster to sponsor your EIP-7702 account deployment and execution), you end up signing twice: once for the authlist item (to deploy the EIP-7702 delegate), and then another for the ERC4337’s UserOperation.
The suggestion is add a “hash” value into the authlist, which gets signed along with the delegate, chainid and nonce.
Other than being signed by 7702, it is left unused by it.
But this value can be used by the wrapper transaction (a UserOperation), and thus a single signature can be used both.

Author: SamWilsn
Date: 2024-11-20T16:49:54.056Z

How does this interact with:


Ethereum Improvement Proposals


EIP-7610: Revert creation in case of non-empty storage
Revert contract creation if address already has the non-empty storage





That proposal has the text:

If a contract creation is attempted due to […] any other reason, and the destination address already has […] non-empty storage, then the creation MUST throw as if the first byte in the init code were an invalid opcode.

Arguably, EIP-7702 is a contract creation. As far as I can tell, EIP-7702 doesn’t clear storage. Therefore, if a contract writes to the EOA’s storage and later the EOA’s code is cleared, then no future code can be written to the EOA.
It’s a little fuzzy because 7702 doesn’t run initcode, but rules-as-intended it sounds like the second deployment should fail. If 7702 bypasses 7610, maybe the document should explicitly state it.

Author: SamWilsn
Date: 2024-11-20T16:57:43.017Z

Summoning @holiman and @rjl493456442 for their thoughts.

Author: wjmelements
Date: 2024-11-20T20:15:06.410Z

SamWilsn:

Arguably, EIP-7702 is a contract creation.


It is interesting that you worry about 7610 but not 684. 7610 merely expands 684 to include storage. 7702 breaks from 7610 in the same way it breaks from 684.
Disregarding initcode, neither 7702 nor SETCODE are contract creation. The main distinction between setcode and creation is that only the code is changed. The account already exists; it has balance and nonce. Allowing EOAs to setcode is not a creation therefore. Changing the nonce, the balance, the code, the storage, or any other property of an existing account is not a recreation.

Author: jflatow
Date: 2024-11-24T23:38:13.815Z

Seems like the EIP is still making progress, which is great. I have one specific question about the impacted opcodes and a more general question about the design of the EIP.
Starting with the specific question: the impacted operations are called out specifically: EXTCODESIZE, EXTCODECOPY, EXTCODEHASH, CALL, CALLCODE, STATICCALL, and DELEGATECALL, and examples are given for how the EXTCODESIZE and EXTCODEHASH are affected, but wouldn’t it be better to explicitly specify how each of these are impacted? We wouldn’t want any variation due to room for interpretation. In particular, its not clear to me from reading how should EXTCODECOPY work, though I think it seems to suggest that only the first 2 bytes should be copied (0xef01).
For the more general question about the design, I hope someone can help clarify and point out where my understanding is flawed. But it seems to me that the EIP creates a situation that is very dangerous by default for users and makes it extraordinarily difficult to perform the simple things that users might want to benefit from (e.g. batching or gasless). It seems that since the signature is only over keccak(MAGIC || rlp([chain_id, address, nonce])), there is always a requirement for an additional signature from the user for any particular operation. They are unable to simply sign once a batch of transactions to be executed. Further, delegated contract code would have to add in additional application level signature checks or the like for the EOA to not be completely opening their account up for anyone to access, making the default state appear incredibly dangerous for users (especially those wishing to do simple batch operations with a single signature). Am I missing something here, or is this really how it is designed?

Author: frangio
Date: 2024-11-25T00:04:15.937Z

No, that is how the EIP is designed. A delegation is an extremely sensitive operation. The intent is that wallet providers will develop account code and offer it as a way to upgrade an EOA with features such as batching. Advanced users may manually delegate to trusted code or implement their own, which obviously requires an understanding of the security model.

Author: jflatow
Date: 2024-11-25T03:08:31.465Z

Thanks for clarifying. In that case, I have concerns about the current design. The complexity of building a contract wallet is high and error-prone, and in the best case this design will require a user to perform multiple signatures in order to do simple batching / gasless operations. By its nature, the first signature will require the user to over-provision trust in the contract code being delegated to. If instead the signature included the calldata (and gas, value), and if the authorization list included a boolean for whether or not the delegation should be transient, this would be vastly superior for most use cases, in my opinion. A user could then create single signatures with restricted capabilities without needing to trust/audit a potentially extremely complex contract (and one that by its nature invites many easy-to-produce vulnerabilities). Such a design would also allow that trust to be gained progressively, as wallet implementations build confidence, without requiring all-or-nothing (blind) leaps of faith from users.

Author: ArikG
Date: 2024-11-25T08:29:02.335Z

Is this being actively discussed?
Reducing 2 signatures to 1 signature is a huge value add to the usage of this and should not be ignored. Much better UX with a single signature

Author: SamWilsn
Date: 2024-11-26T15:05:52.555Z

wjmelements:

It is interesting that you worry about 7610 but not 684.


Yeah, I should be worried about 684 as well  I had just read 7610, so it was on my mind at the time.

Author: frangio
Date: 2024-11-29T14:54:32.314Z

dror:

you end up signing twice: once for the authlist item (to deploy the EIP-7702 delegate), and then another for the ERC4337’s UserOperation.


A wallet should be able to implement a UX where this is combined into a single interaction. Does something prevent that?

Author: dror
Date: 2024-12-02T19:23:34.474Z

Yes, a wallet could sign multiple signatures at a single “accept” from the user. You could say also the same about signing approve+swap… why shouldn’t a wallet sign them together?
For some wallets (e.g. multisigs) it becomes slightly trickier
Do you think hardware wallet will ever sign two signatures together?
(though admittedly, the last 2 options are niche customers, not the mass-adoption. Those users are usually more technical and security-oriented probably care less about multiple signatures

Author: frangio
Date: 2024-12-03T20:28:27.092Z

dror:

Yes, a wallet could sign multiple signatures at a single “accept” from the user. You could say also the same about signing approve+swap… why shouldn’t a wallet sign them together?


This is true! I do think it should happen. The problem is that the wallet’s RPC interface doesn’t support it, but something like EIP-5792 sendCalls could enable just that, even without batching. In the case of EIP-7702, assuming the (likely?) scenario that there is no RPC method to sign a delegation, the wallet can just handle it all internally and produce the two signatures with a single user interaction. If there was an RPC method so that e.g. Metamask could ask a Ledger to sign a delegation, this method could be designed to produce the two required signatures in one round.



 dror:

For some wallets (e.g. multisigs) it becomes slightly trickier


Not sure if this applies to EIP-7702 since the signer is an EOA.

Author: jflatow
Date: 2024-12-04T01:48:38.294Z

I don’t understand, why rely on some future (weird?) state where wallets can perform 2 signatures at once, instead of designing the EIP to work well with one signature?

Author: frangio
Date: 2024-12-04T03:12:09.408Z

jflatow:

why rely on some future (weird?) state where wallets can perform 2 signatures at once


No wallet currently supports performing EIP-7702 signatures so it’s not like there’s some existing thing we can rely on.
If you think the idea of signing two messages in one user interaction is a bad idea please share the reasons for that. I’m not sure it’s a good idea, I’m just pointing out that it’s a possibility, and that support for delegations will have to built out pretty much from scratch so this kind of thing can be added at this stage.

Author: jflatow
Date: 2024-12-04T04:14:29.953Z

I think signing 2 messages at once is very hard to explain to the user in a way that is also safe. If you make it too easy to sign multiple things at once, that will be abused to trick users into signing things they have no idea about. And to make it safe you need a way to convince the wallet its okay while explaining to the user what they are doing and why. It is far superior in my opinion to map signatures to meaningful interactions for users, there’s no reason to require 2 signatures when 1 would do (and be safer).
Why is it safer? See my message above, but the first signature is generally required to over-provision trust in the current model to the code being delegated to. Followed by a second signature which might be more limited in scope. But because it is independent, who knows if it will even be used. How does the user express that a permission should only be granted transiently? They pretty much can’t with this 2 signature model.

Author: eawosika
Date: 2024-12-04T07:33:28.861Z

https://research.2077.xyz/charting-ethereums-account-abstraction-roadmap-eip-3074-eip-5806-eip-7702

Author: matt
Date: 2024-12-06T01:02:13.987Z

jflatow:

If you make it too easy to sign multiple things at once, that will be abused to trick users into signing things they have no idea about.


The only way this can be abused is if a wallet decides to take advantage of their users. But no protocol can people from that type of threat.
EIP-7702 delegations are unlike other signatures. They deal with the permissions of your account. We’re not proposing to make it easier to sign many arbitrary things at once. Just a particular special case where peculiarities of the protocol necessitate two signatures in conjunction to achieve a single goal.



 jflatow:

How does the user express that a permission should only be granted transiently?


A pretty explicit goal of EIP-7702 is to not support transient operations. This has been discussed a lot over the past year, but essentially: wallets are not transient devices and EIP-7702 is designed to support their proliferation.

Author: matt
Date: 2024-12-06T01:09:29.610Z

jflatow:

I don’t understand, why rely on some future (weird?) state where wallets can perform 2 signatures at once, instead of designing the EIP to work well with one signature?


Also: we had a version that worked nicely for one signature, it was EIP-3074  what we’ve ended up with in EIP-7702 is the result of a lot back and forth with core devs, the community, wallet devs, and more.
It has it’s trade offs, but I don’t think anything fatal.

Author: jflatow
Date: 2024-12-06T04:44:56.823Z

matt:

A pretty explicit goal of EIP-7702 is to not support transient operations. This has been discussed a lot over the past year, but essentially: wallets are not transient devices and EIP-7702 is designed to support their proliferation.


I think this is probably the key point of contention. Why is it an explicit goal of EIP-7702 not to support transient operations? Wallets may not be transient devices, and the design may support the proliferation of wallets, but I don’t see why this has to be the exclusive goal of the EIP. In my opinion, it is at least as valid to also support and open up the features of batching and gasless transactions to applications. I don’t see what’s the point of excluding these use cases which IMHO are lower hanging and safer fruit (for reasons previously stated, but which I am happy to elaborate on, if needed)?

Author: frangio
Date: 2024-12-06T13:37:54.102Z

jflatow:

it is at least as valid to also support and open up the features of batching and gasless transactions to applications


I don’t understand, this is already enabled by this EIP, in combination with others like EIP-5792 and ERC-4337.

Author: jflatow
Date: 2024-12-07T04:04:00.950Z

frangio:

I don’t understand, this is already enabled by this EIP, in combination with others like EIP-5792 and ERC-4337.


Perhaps you could explain to me how a user with an EOA could accomplish a batched/gasless transaction (of restricted scope) coming from an app with one signature using the combination of these EIPs? I don’t really think it is possible (not to mention the fact that ERC-4337 is highly suboptimal in other dimensions)

Author: matt
Date: 2024-12-09T21:41:08.890Z

The dapp would just use the wallet RPC method like EIP-5792 has defined wallet_sendCalls and the wallet would create a signature committing to both calls. It’s wallet defined how that looks / how it gets on chain. ERC-4337’s userOps is one way, but you can implement however you desire.

Author: jflatow
Date: 2024-12-10T20:38:44.145Z

So this still results in multiple signatures on-chain, right?
I guess I’ve asked this elsewhere, but to make sure I understand your vision, it seems that for apps to be able to use this, the idea is to wait for thick wallet implementation of EIP-7702 which includes a contract backend, and then for potential convergence on an app layer protocol, and also adoption by users by whichever few wallets manage to do all this? As opposed to the alternative of making EIP-7702 app friendly/safer (allowing competition/iteration on usage of the standard), and only requiring relatively simple thin wallet implementations to support?

Author: matt
Date: 2024-12-10T20:51:47.339Z

Converting your EOA to a smart contract wallet is a one-time operation which requires a signature. That signature cannot also commit to an operation you wish to perform so you need to also make a signature over that operation. Other than the one-time setup, all operations can be bundled with a single signature.
Because this is give full access of you EOA to the smart contract code, it’s not something that should be exposed to dapps. There should be a module protocol built on top that can reason about permissions.

Author: jflatow
Date: 2024-12-11T04:58:44.878Z

I think this is exactly the problem with the EIP as is. It could be such that you wouldn’t be required to give full access over your EOA to the smart contract, that a single signature in total could be used to perform an operation without compromise, and that would be more secure for users and better for applications being built on Ethereum.

Author: matt
Date: 2024-12-11T15:14:00.347Z

I understand you have an issue with this aspect of the EIP. There were other proposals like what you mentioned and they were discarded in favor of this. At this point, this is what client teams and the community have decided to pursue.

Author: jflatow
Date: 2024-12-11T16:26:47.748Z

I’m trying to understand the reasons for that. The only dimension I can see that this might be better is for wallet implementors to make other parties more beholden to them. I would like to know what I am missing, or why the better/more secure experience for users and applications is being foregone? AFAICT I am not the only one concerned about this so I think its a bit presumptive that you speak for the community, and I think it is reasonable for me to ask at this point at least for the justifications before the community makes a potentially costly mistake. This EIP will have an impact for many years to come.
As far as things that were moved away from, perhaps you mean EIP-3074? If so, I think these properties could still be achieved with something closer to EIP-7702, and its not clear to me where those options have been discussed or what the conclusions were.

Author: matt
Date: 2024-12-11T17:38:55.045Z

If you have a proposal for how to modify 7702, I will be interested to hear it. But please understand, you are only just now engaging in the design discussion of an EIP which has been intensely discussed throughout the entire year. What is in the EIP now is the culmination of many different perspectives and preferences. Everyone has sacrificed something they care about to get this EIP over the line and Prague.
In particular, I have stopped pursing the ability you seem to be describing above: a single signature (for EOAs) to perform an operation without compromise. EIP-3074 did provide this. However, many had concerns about it and felt it would create two tracks of account abstraction. What is demanded is that EOAs and smart contract wallets have as similar an experience as we can provide. This is how we got to 7702.
Even the first version of 7702 was closer to 3074 and probably provided what you desire. However there was fierce arguments about revocation which is why we ultimately decided to enshrine code via the delegation designator.
So - please review this thread and the future of EOA breakout recordings to understand why we have ended up on this design. If you have a proposal for improving 7702, feel free to share it with us.

Author: jflatow
Date: 2024-12-12T07:56:44.299Z

Thanks for the pointer, I will work on catching up on all those sessions. I would just point out that although I’ve been trying to follow the discussion for a while now, its actually quite difficult to participate in the process. I wasn’t aware of these breakout sessions until you just mentioned them, I think its the first time they came up on this thread.
I have been excited about 3074 and 7702 since first hearing about them, and I appreciate the hard work you and others have put in this far (even moreso now as I listen to these calls). I know this has been a long road, but from my perspective if the current proposal is finalized, it will result in a much longer time until apps are able to benefit (if ever), and so even taking a little longer now to fix is still a much better outcome.
I also experienced a bit of a Mandela effect as I did recall when first reading the spec that it seemed to have this property (single signatures, usable by apps), but in recent readings it seemed to have morphed into something else. Now I see that this changed in July. It’s still not clear to me why the EIP was changed not to revert the delegation back at the end of the transaction, but I still have a few more breakout sessions to go, so perhaps it will become clearer when I’m through.
As for how to modify 7702, my naive proposal would be to simply add a boolean transient flag to the authorization tuple that is signed over and determines whether the delegation remains or is cleared after processing each one. I understand now from the breakout sessions that this is also how @vbuterin was thinking about it early on, which reassures me that it may not be a crazy idea.
I would also possibly suggest considering an opaque bytes payload to each tuple, though I understand that may be even more controversial. This would allow the same signature to be included in the calldata itself and encode a potential operation. However, in the context of a transient operation this isn’t really necessary, as the contract being executed can have the assurance that if it is being run, it must be getting actively delegated to by its EOA owner. Having it would certainly increase the design space though, and I don’t recall who said it but I agree that increased design space would be preferable now to allow for potential UX improvements.

Author: matt
Date: 2024-12-12T16:18:45.305Z

I agree that we as core devs don’t do the best job surfacing why every decision has been made. It’s been on my todo list for a while to beef up 7702’s rationale, but haven’t had a chance to do it yet.



 jflatow:

It’s still not clear to me why the EIP was changed not to revert the delegation back at the end of the transaction, but I still have a few more breakout sessions to go, so perhaps it will become clearer when I’m through.


We basically were at an impasse where one side felt that the ephemeral / temporary delegations had to be constrained with a revocation mechanism and I + others felt this significantly nerfed the EIP’s power because you wouldn’t be able to set and forget social recovery schemes.
Also, setting code temporary increases the likelihood of users doing simple batch scripting instead of using smart contract wallet like primitives.
We figured out the at writing the address the user wants to delegate to actually solves revocation pretty nicely because the EOA can just update the code they delegate to at anytime and it let’s users have a delegation permanently if they choose.
We could extend the design to add back some ephemerality or additional  logic for atomically handling EOA calls, but we also need to balance the complexity of the change to the protocol. EIP-7702 is relatively simple to implement at this moment, but once you start adding new ways to instantiate EVM calls the complexity grows quickly. Plus we’re trying to reduce the number of call sites that can instantiate EVM execution because testing each of them every time there is an EVM change to ensure they are initialized correctly is very burdensome.



 jflatow:

As for how to modify 7702, my naive proposal would be to simply add a boolean transient flag to the authorization tuple that is signed over and determines whether the delegation remains or is cleared after processing each one. I understand now from the breakout sessions that this is also how @vbuterin was thinking about it early on, which reassures me that it may not be a crazy idea.


So as I mentioned - this adds the ability for EOAs to do scripting-like tx execution and we’ve actively decided that this detracts from main goal of getting users to use smart contract wallets.



 jflatow:

I would also possibly suggest considering an opaque bytes payload to each tuple, though I understand that may be even more controversial. This would allow the same signature to be included in the calldata itself and encode a potential operation. However, in the context of a transient operation this isn’t really necessary, as the contract being executed can have the assurance that if it is being run, it must be getting actively delegated to by its EOA owner. Having it would certainly increase the design space though, and I don’t recall who said it but I agree that increased design space would be preferable now to allow for potential UX improvements.


This one has been proposed by @dror before. My response has consistently been that this only solves the “dual signature problem”, but in a hacky way. You still need to provide the signature to the system twice - which feels only like a half solution. What you really want is to add an opcode which can read the opaque data / hash from the authorization so it is already authenticated in some way.
–
At the end of the day, some people think the two signatures is a problem and others don’t. Since we didn’t come up with a great solution that allows just one signature, I think what we have is the best thing right now. Maybe we’ll come up with something in the future that can amend the current functionality.
If the current design hinders adoption by dapps, I think they will only be doing work that they probably need to do anyways to properly support smart contract wallets. This is the goal anyways - not minimal integration work by dapps.

Author: jflatow
Date: 2024-12-12T18:08:24.581Z

Thanks for the explanations.



 matt:

We basically were at an impasse where one side felt that the ephemeral / temporary delegations had to be constrained with a revocation mechanism and I + others felt this significantly nerfed the EIP’s power because you wouldn’t be able to set and forget social recovery schemes.


Allowing for either ephemeral or permanent via flag would allow for both. I actually think the current revocation mechanism is not very robust, which is one reason I think having the transient flag is important. Imagine trying to achieve ephemerality with the current system, providing one tuple to set the delegation and another to clear it. A malicious front-runner could drop the second tuple, thus leaving it delegated until another transaction with a single auth tuple is created and used to fix it. Thus this just becomes an anti-pattern people trying to achieve ephemerality will be mistakenly led into because there is no real way to do it. I don’t really see why adding the transient option would necessarily lead to additional call sites for EVM execution.



 matt:

So as I mentioned - this adds the ability for EOAs to do scripting-like tx execution and we’ve actively decided that this detracts from main goal of getting users to use smart contract wallets.


This is the real root issue in my opinion. This is problematic, because the stated motivation of the EIP says:
There is a lot of interest in adding short-term functionality improvements to EOAs, increasing the usability of applications and in some cases allowing improved security.

It goes on to mention the 3 specific applications of batching, sponsorship, and privilege de-escalation.
But none of these are the actual motivation! If they were, I think we would be trying to find the best way to support them. The actual motivation is apparently to get people to permanently migrate to smart contract wallets, and so I think at best the EIP is being presented in a very misleading way.



 matt:

Since we didn’t come up with a great solution that allows just one signature, I think what we have is the best thing right now.


I agree there is something hacky about recovering the same signature twice, but to me its just as hacky (if not worse) to instead require a second different signature to be recovered by the application. I will make a different post about this topic though, since I think its actually the secondary issue here.



 matt:

If the current design hinders adoption by dapps, I think they will only be doing work that they probably need to do anyways to properly support smart contract wallets. This is the goal anyways - not minimal integration work by dapps.


I feel like its being under-estimated how little the current solution provides to dapps that want to achieve the stated goals of this EIP of batching, permissionless, and privilege de-escalation in the short-term. The EIP seems to actually go out of its way to come across as not taking a stance on endgame account abstraction, but that does appear disingenuous at this point.
I expect its going to take many more years, at least, to be able to write an app that portably and reliably gets the benefits the EIP says it is trying to provide. In the current proposal, the bar for implementing a wallet is going to be much higher, and implementations will necessarily have to be much thicker. There will be more temptation to build a (bad) wallet, since that is the only way to control the transactions in the way that applications will want to. Further, there will almost certainly be an explosion in diversity of how this limited set of wallets expose these features to applications, and applications will have to try and build towards all of them to support users (likely therefore supporting each in a worse way). My fear is we are leading to a long-term “wallet wars” situation akin to the browser wars, that is likely to provide net negative value to users.
Again, I appreciate all the hard and thoughtful work you and others have already put into this. But I would be remiss not raise my concerns at this point since I think there’s still an opportunity to avoid that path, even if others have already raised similar concerns/proposals in the past.

Author: matt
Date: 2024-12-12T19:52:07.661Z

jflatow:

Allowing for either ephemeral or permanent via flag would allow for both. I actually think the current revocation mechanism is not very robust, which is one reason I think having the transient flag is important.


Like I said, it is a design goal to not allow users to do tx scripts. So the flag approach doesn’t make much sense to me.



 jflatow:

The EIP seems to actually go out of its way to come across as not taking a stance on endgame account abstraction, but that does appear disingenuous at this point.


Maybe the text of the EIP can be improved, but I do think it is fairly clear about the end state of AA - smart contract wallets. It tries to abstract enough to allow many different visions there to flourish. I think you’re conflating app level standards needed in this end state with what primitives the protocol provides.



 jflatow:

I feel like its being under-estimated how little the current solution provides to dapps that want to achieve the stated goals of this EIP of batching, permissionless, and privilege de-escalation in the short-term. The EIP seems to actually go out of its way to come across as not taking a stance on endgame account abstraction, but that does appear disingenuous at this point.


I disagree. There are many teams who already have projects showcasing the functionality of 7702. You can just see the Ithica experiments. But there are many others.



 jflatow:

Again, I appreciate all the hard and thoughtful work you and others have already put into this. But I would be remiss not raise my concerns at this point since I think there’s still an opportunity to avoid that path, even if others have already raised similar concerns/proposals in the past.


Appreciate your feedback. If you feel strongly about this, the only way to change is find support among wallet teams who will be implementing this. As far as I can tell, there is buy-in for the current version of 7702.

Author: protolambda
Date: 2024-12-12T22:56:38.202Z

In PR Update EIP-7702: updates for devnet4 by lightclient · Pull Request #8929 · ethereum/EIPs · GitHub the chain_id size was limited to uint64. This unnecessarily restricts the chain_id to be a vanity ID, chosen arbitrarily like many EVM chains have today, rather than more like a hash.
In other places in the protocol, a full uint256 chain ID is supported.
A large chain ID like that can be chosen by hashing some state and/or configuration, enabling the idea of a “counter factual chain identity”: a chain instantiation bound to its usage rules. For future more ephemeral chains this is ideal, as a user does not need a central registry to update to attach specific rules or configuration, those can be proven against the chain ID instead.
And this can expand into neat protocols where the user signs transactions in advance, and the chain is only instantiated when certain conditions are met, exactly with the rules and pre-state as committed to by the chain ID.
This can also be a big part of making chain configurations more interoperable and chain-instances more elastic, as there is no need for a central registry to register the chains in a uint64 namespace.
Disclaimer: I did not come up with these chain ID schemes, these things go back as far as 2018 comments on ethresearch sharding threads, likely earlier. @vbuterin might be able to share some history about the general idea.
Can we please revert this chain_id size limit in EIP 7702, and support full uint256 chain IDs in the auth list?

Author: jflatow
Date: 2024-12-12T23:12:06.807Z

matt:

Like I said, it is a design goal to not allow users to do tx scripts. So the flag approach doesn’t make much sense to me.


The fact that this is actually an anti-goal of yours I find very odd.



 matt:

Maybe the text of the EIP can be improved, but I do think it is fairly clear about the end state of AA - smart contract wallets. It tries to abstract enough to allow many different visions there to flourish. I think you’re conflating app level standards needed in this end state with what primitives the protocol provides.


It was many times raised that the migration path this provides is riskier for users and presents barriers to adoption. It also rules out entire classes of experiences without justification, in my opinion.



 matt:

I disagree. There are many teams who already have projects showcasing the functionality of 7702. You can just see the Ithica experiments. But there are many others.


The fact that there are experimental wallets that demonstrate some of this functionality does not invalidate the point that there will be a proliferation of standards and necessary adoption of such (more complex, fragmented) wallets before apps can benefit.



 matt:

Appreciate your feedback. If you feel strongly about this, the only way to change is find support among wallet teams who will be implementing this. As far as I can tell, there is buy-in for the current version of 7702.


I’m not sure why wallet teams are the only voices which matter here. In listening to breakout sessions #5 and #6, it seems there was actually fairly widespread interest in the ephemeral flag. I heard repeatedly comments from @derek, @g11in and a number of others comments along similar lines, that as far as I can tell were never really addressed. I also heard @adietrichs say that ephemeral would be really desirable, if not for the problem of auth tuples being picked up without the user op.
Therefore, I would instead like to focus on a specific concrete proposal to modify the EIP and potentially solve the issues with it:

Add a transient (ephemeral) flag to the authorization tuple: if transient is set, clear the delegation after execution
Have each signature include the calldata in addition to the other fields of the authorization tuple

I believe this would have the following benefits:

Full Compatibility: These updates maintain all existing functionalities, ensuring that those currently satisfied with EIP-7702 face no disruptions
Robust Security: By binding authorizations tightly to transaction data, we protect against misuse and unauthorized transactions
Single Signatures: Supports both current users and newcomers, facilitates broader and more efficient integration, and allows for graceful adoption
Low Implementation Impact: The required changes are minimal and designed for easy integration with the existing system, minimizing development overhead

I would appreciate first and foremost any feedback on the efficacy of the proposal, before dismissing it out of hand due to potential philosophical differences.

Author: SamWilsn
Date: 2024-12-13T01:10:54.017Z

protolambda:

the chain_id size was limited to uint64.


This poses a problem for ERC-7785 if I’m not mistaken.

Author: matt
Date: 2024-12-13T15:15:03.198Z

Please feel free to raise your concerns on ACD and with other developers. I don’t find your arguments sufficient to modifying the current behavior of the EIP.



 protolambda:

Can we please revert this chain_id size limit in EIP 7702, and support full uint256 chain IDs in the auth list?


Thanks for letting us know. I had a feeling there were some people hoping to use this functionality but I didn’t know about the counter factual chain identity proposals when we discussed the size. I’m happy to make this change.

Author: determinism
Date: 2024-12-14T03:47:49.488Z

Hi Matt,
I share the goal of improving user experience and enabling new capabilities on Ethereum. However, I believe the current form of EIP-7702 could have far-reaching structural consequences that undermine the protocol’s decentralized ethos. By placing critical delegation and batching functionalities into the control of wallets, rather than making them available at the protocol-level, the proposal risks recreating the gatekeeper dynamics we have worked so hard to avoid in the transition from web2 to web3. This could stifle open innovation, raise barriers for independent developers, and concentrate power in ways reminiscent of major app stores and browsers in the legacy web.
As an app developer, I want to express my support for the points that @jflatow is raising here.
My Core Concern:
The heart of the issue is that EIP-7702 risks turning wallets into gatekeepers. Instead of offering these capabilities as a neutral, protocol-level primitive accessible to all developers, the current design may effectively hand control over important functionality to a small set of wallet providers. This consolidation of power could mirror the way Apple’s App Store or major web browsers control user access and developer integration, creating incentives for these wallet providers to lock in developers, restrict access, and extract rents.



 matt:

We figured out the at writing the address the user wants to delegate to actually solves revocation pretty nicely because the EOA can just update the code they delegate to at anytime and it let’s users have a delegation permanently if they choose.


You mention that users can update the code they delegate to, ensuring they retain ultimate control. However, it’s unclear what mechanisms guarantee that this remains simple and permissionless in practice. Given strong economic incentives, large wallet providers might have every reason to discourage easy switching or to wrap these capabilities in proprietary contracts. Without a neutral, protocol-level guarantee, we’re left hoping that private actors “promise not to do wrong” rather than being sure they “can’t do wrong.”
When you push the features of this EIP to smart contract wallet developers (features that every app developer wants) you are actually trusting them to govern access fairly and, in the process, are relinquishing control. In the absence of gatekeeping, these features could enable dapps to compete and innovate freely. I think we should consider what’s happened historically when such gatekeeping structures are present.
If we enable “ephemerality” for app developers at the protocol-level they will not be beholden to private actors and/or forced to interact through smart contract wallet interfaces, which is an essential counterbalance. I strongly believe we should pursue a balance of powers and ensure that EIPs do not introduce market structures that recreate systems of leverage that led us to create blockchain in the first place.



 matt:

If the current design hinders adoption by dapps, I think they will only be doing work that they probably need to do anyways to properly support smart contract wallets. This is the goal anyways - not minimal integration work by dapps.


I do not share concerns about the ease of integration for dapps. Rather, I worry that key functionalities—fundamental building blocks of the user experience—will be controlled by wallets rather than directly accessible at the protocol layer. This could create a stratified market where developers who want to offer sophisticated features must integrate with whichever wallet providers dominate. In effect, this reduces the agency of dapp developers and could stifle open competition and experimentation.



 matt:

Like I said, it is a design goal to not allow users to do tx scripts. So the flag approach doesn’t make much sense to me.


One thing I’d like to point out is that EIP-7022 will likely not prevent people from doing this. It’s important to acknowledge that there are teams exploring session keys, scripting, and other advanced capabilities in smart contract wallets. If the community’s endgame is to embrace such complexity, why not do it in a way that preserves Ethereum’s core values—neutrality, openness, and permissionless innovation?



 matt:

Appreciate your feedback. If you feel strongly about this, the only way to change is find support among wallet teams who will be implementing this. As far as I can tell, there is buy-in for the current version of 7702.


As an app developer, I feel strongly about this topic. I think it is important that we hear the voice of the app developer community before creating a change that could have a multi-year impact due to the structural implications of this EIP.
Thank you for considering my perspective and I look forward to discussing this more with the community!

Author: frangio
Date: 2024-12-14T17:46:58.195Z

determinism:

You mention that users can update the code they delegate to, ensuring they retain ultimate control. However, it’s unclear what mechanisms guarantee that this remains simple and permissionless in practice.



Permissionless: I believe this is extremely clear. If a wallet is self-custodial, it’s always possible to remove a delegation or set a new one, without asking for permission from the wallet provider. It only takes one simple on-chain transaction signed by the EOA key, which the user should possess if the wallet is self-custodial. If the user doesn’t possess this key, EIP-7702 is not the reason for their lock-in.
Simple: This may be less clear, as there is quite a bit of technical nuance.

Removing a delegation is maximally simple: one transaction that erases the delegation designator from the account.
Migrating to new account code is on the surface simple, but doing it in a secure way may or may not be simple depending on the way the account has managed the account storage. I’m proposing a new section in the EIP security considerations to explain this, summarized below.

If the account code followed EIP-7702 best practice with respect to storage and used something like EIP-7201 and Solidity’s upcoming layout location feature, the migration is safe to do in one transaction that simply redelegates to the new code.
If the account code did not follow best practice, the migration may not be safe and should be preceded by clearing the account storage. This storage clearing can be implemented by a third-party (i.e., it doesn’t need to be done by the original wallet provider) as a kind of delegation target dedicated to this purpose. Once this is done the new account code can be installed.





Regarding market structure, I’d like to draw an analogy to Ethereum’s application-layer ERC-20 standard versus the built-in token primitives that some other blockchains provide. You could make the same argument against Ethereum’s approach in this case. Paraphrasing from your post:

Instead of offering these capabilities as a neutral, protocol-level primitive accessible to all developers, the current design may effectively hand control over important functionality to a small set of wallet providers asset issuers.

This has not happened. ERC-20 has been successful, as have other application-layer standards. EIP-7702 is following a similar philosophy: minimal but very general features at the protocol layer, complemented by application-layer standards.
We should now be working on those standards and best practices. I suggest looking into EIP-5792 and contributing to its development and adoption.

Author: determinism
Date: 2024-12-14T21:29:42.185Z

frangio:

Permissionless: I believe this is extremely clear. If a wallet is self-custodial, it’s always possible to remove a delegation or set a new one, without asking for permission from the wallet provider. It only takes one simple on-chain transaction signed by the EOA key, which the user should possess if the wallet is self-custodial. If the user doesn’t possess this key, EIP-7702 is not the reason for their lock-in.


I acknowledge that, from a purely technical standpoint, it’s permissionless to change the delegated code with a single transaction. However, my concern is less about the mechanism and more about the practical dynamics that will emerge under the current design of EIP-7702.
In practice, what guarantees that wallet providers will expose the full spectrum of this capability in an accessible way in their UIs? Most users rely on a wallet’s UI rather than directly signing transactions with raw keys. If these wallet interfaces fail to offer a clear and easy path to update or remove delegations, the “permissionless” feature risks becoming moot. It’s similar to how users rarely switch from Chrome to Chromium—they technically could, but the friction and lack of convenient alternatives often discourages it.
Without the ability to include calldata and set an ephemeral flag, I find this very unlikely. This is because, in the current state of the EIP, it is impossible to know what the EIP-7022 transaction will do once signed. In other words, if wallets cannot fully simulate or verify the effects of a 7702 transaction, they may feel compelled to restrict access, effectively gatekeeping a critical piece of functionality. This is my central point of concern: the current EIP design, unintentionally, may encourage a market structure where wallets hold the keys to essential, protocol-level features that should be broadly available.



 frangio:

Simple: This may be less clear, as there is quite a bit of technical nuance.


I actually fully agree with the simplicity of the technical implementation and process. I believe you are correct. Again, I think, due to the lack of a calldata or ephemerality field, that wallet UIs will not allow this.



 frangio:

Regarding market structure, I’d like to draw an analogy to Ethereum’s application-layer ERC-20 standard versus the built-in token primitives that some other blockchains provide. You could make the same argument against Ethereum’s approach in this case. Paraphrasing from your post:


I appreciate the analogy and understand the point you are making here. However, I do think these are two very different standards and capabilities.
In the case of ERC-20, the community was setting a standard interface for fungible tokens at the app layer. It didn’t force developers to rely on a small set of intermediaries to achieve core token-related functionality. In contrast, EIP-7702, as currently specified, risks making fundamental execution capabilities—like batching and code delegation—indirectly dependent on wallet providers’ cooperation. Put another way, ERC-20 didn’t necessitate the need for further standards to emerge on top for developers to access the core functionality of what ERC-20 offered in the first place. In effect, we are creating an upstream dependency to access a down stream protocol-level capability that is EIP-7022, which few other ERCs have done.
A closer analogy might be if delegatecall were only accessible through certain approved proxy contracts. Such a restriction would concentrate power and introduce a form of gatekeeping that is inconsistent with Ethereum’s ethos of open-access primitives.



 frangio:

EIP-7702 is following a similar philosophy: minimal but very general features at the protocol layer, complemented by application-layer standards.


I also totally agree here. In this vein, I really believe we should add the simple flexibility of setting an ephemeral flag and let users sign a specific calldata. This change makes EIP-7022 a more general, protocol layer feature. This also lets the application-layer decide on whether wallets should standardize at the app layer or if apps should have access to this, as well, through complementary developments.
I believe it’s important to involve the app developer community more directly in this discussion. Their perspective is essential because they will ultimately build on top of whatever transaction and account model we standardize. We should not overly rely on a single class of stakeholders—like wallet providers—when deciding how to introduce core protocol capabilities.
Please let me know if any of my points resonate! I look forward to discussing further.



 frangio:

We should now be working on those standards and best practices. I suggest looking into EIP-5792 and contributing to its development and adoption.


I would love to be more involved!

Author: frangio
Date: 2024-12-14T21:57:41.186Z

determinism:

This is because, in the current state of the EIP, it is impossible to know what the EIP-7022 transaction will do once signed.


This isn’t a limitation of the EIP but a consequence of turing completeness. Including calldata and an ephemeral flag doesn’t change that fact. Simulating a transaction doesn’t give you a complete account of what it might do, so even with those additional capabilities to know what an EIP-7702 transaction would do requires an analysis of the contract code that is in general intractable.
Sorry I’m not engaging with all of your points but this concern has already been discussed throughout the year. Many people from different communities have been involved in the process.

Author: determinism
Date: 2024-12-15T01:03:15.472Z

That is a fair point with regard to Turing completeness. However, I do think the point still stands of gating this access behind smart contracts as opposed to letting app-developers more freely leverage the feature set.
Would greatly appreciate how the community has addressed the above questions regarding how realistic we think it is that wallets will allow people to easily switch and issue 7702 transactions? Has this been discussed?
I also think the features above only add flexibility and can power all of the wallet use-cases, in addition to app-level capabilities.

Author: determinism
Date: 2024-12-15T01:12:22.232Z

@frangio one thing I wanted to inquiry about, as well, is how do we aim to allow protocols to have access to these features? That is, programmability within the context of an EOA? Is it expected that all accounts will adopt modular standards that enable protocols to have access to these features?

Author: matt
Date: 2024-12-16T16:52:28.653Z

determinism:

The heart of the issue is that EIP-7702 risks turning wallets into gatekeepers. Instead of offering these capabilities as a neutral, protocol-level primitive accessible to all developers, the current design may effectively hand control over important functionality to a small set of wallet providers. This consolidation of power could mirror the way Apple’s App Store or major web browsers control user access and developer integration, creating incentives for these wallet providers to lock in developers, restrict access, and extract rents.


EOA wallets can gatekeep today but they don’t. They could easily disallow users from using dapps they don’t have partnerships with. They also allow you to export your private key to use elsewhere.
Sorry but 7702 does not worsen the status quo.

Author: troublor
Date: 2024-12-20T04:37:20.527Z

Hey, I was going through this EIP recently and got confused about the impact on the mempool of clients.
As mentioned in the “Security considerations → Transaction propagation”:

With this EIP, it becomes possible to cause transactions from other accounts to become stale. This is due to the fact that once an EOA has delegated to code, that code can be called by anyone at any point in a transaction. It becomes impossible to know if the balance of the account has been sweeped in a static manner.
While there are a few mitigations for this, the authors recommend that clients do not accept more than one pending transaction for any EOA with a non-zero delegation designator. This minimizes the number of transactions that can be invalidated by a single transaction. Another alternative would be to expand the EIP-7702 transaction with a list of accounts the caller wishes to “hydrate” during the transaction.

This EIP makes it impossible for mempool to statically analyze the validity of an incoming transaction because it is unknown whether other pending transactions will decrease the balance of the incoming transaction’s sender.
Mitigation is recommended in the EIP that clients do not accept more than one pending transaction for any EOA with a non-zero delegation designator. However, it is still possible that attackers may leverage lots of different EOAs with non-zero delegation designators to populate the mempool with lots of later-to-be-found invalid transactions at the EVM execution stage.
Mempool is usually of limited capacity. It is possible to overwhelm the mempool with large amounts of malicious, later-to-be-found invalid, transactions and make the client have to discard other valid transactions from the mempool (suppose the malicious transactions have higher priority than other valid ones, by, e.g., priority fee). The client under attack may end up not being able to include sufficient transactions in the proposed block, wasting the block space. This can happen both in a client that serves RPC accepting transactions or receives transactions from other P2P nodes.
I believe making mempool unable to statically verify the validity of transactions is in general an undesired change and opens the gate for DoS attacks. This may have a more severe impact than expected.

Author: colinlyguo
Date: 2024-12-24T10:14:07.234Z

Hey, I was going through this EIP and noticed that the destination field in EIP-7702 seems to serve the same purpose as the to field in other transactions. I’m curious about the rationale behind using a different term (‘destination’)? since it takes a bit of time for me to figure out this field, not sure if it’s a common problem for readers.

Author: nota
Date: 2024-12-25T07:17:21.196Z

About the three use cases of require(msg.sender == tx.origin) checks,

Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal). On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive.

How are these statistics done? If any, could you kindly share the scripts used to search for smart contracts with these three different use cases? This will be quite helpful for other EVM-compatible chain teams considering implementing this EIP, as they also want to check if this EIP will break smart contracts on their networks.

Author: colinlyguo
Date: 2025-01-03T08:34:04.682Z

About the EXTCODESIZE, EXTCODECOPY, and EXTCODEHASH behaviors, what’s the rationale for not returning the whole delegation? to make EXTCODEHASH consistent, or just keep it simple?

Author: islishude
Date: 2025-01-04T07:24:26.294Z

I have a security concern regarding the use of a zero chainId.
Consider the following scenario:
A signature is created on chainA with nonce=100, chainId=0, and contract=X. The contract X can be deployed on different chains using create2.
If contract X contains security vulnerabilities, the address on every chain will be at risk.
Additionally, the nonce of the address on another chain can be smaller than that on chainA, which exposes this address to forward security risks under the current specification.

Author: julrach
Date: 2025-01-09T21:51:04.816Z

I asked myself recently: if there was any one last thing I’d bring up before the spec shipped, what  would that be?
What I landed on was: changing EXTCODE* back to prefix || delegate.
The proposal to change EXTCODE* behavior from acting on the delegate contract’s bytecode to the EOA’s “delegation designator” was to stop EOAs from “temporarily masquerad[ing] as having a particular codehash, which would break contracts that rely on codehashes as an indicator of possible account behavior” (ref), however having EXTCODE* only act on the delegation prefix 0xef01 seems like an over-correction.
If the purpose of this behavior is to stop EOAs from masquerading as regular contracts, then this would still be solved if EXTCODE* opcodes acted on the full “delegation designator” since no deployed contracts start with the banned opcode 0xef. In other words, legacy protocols that rely on codehashes couldn’t be broken by a delegated EOA if EXTCODE* opcodes act on the entire “delegation designator” because these opcodes would never return normal contract values when called on a delegated EOA.
Meanwhile, it would be incredibly useful to be able to query what delegate contract an EOA is using on-chain to infer account behavior.
Anyways, just my 2 cents!

Author: crStiv
Date: 2025-01-10T00:05:41.544Z

What precautionary measures could be implemented to mitigate potential attacks related to temporarily assigning code to EOAs, especially in the context of replay attacks or unauthorized access to funds? Would it be possible to introduce additional checks or constraints to enhance the security of this approach?

Author: nathanglb
Date: 2025-01-11T04:43:59.710Z

Hello, I wanted to ask if EIP-7702 specification is finalized yet, or if the debate is ongoing and the spec is still just a draft.  Is this EIP commit hash to be considered the final draft of the EIP behavior?  Is there a firm or estimated release date when EIP-7702 will go live on Ethereum?


github.com/ethereum/EIPs








Update EIP-7702: make chain id u256 (#9143)



        committed 03:27PM - 19 Dec 24 UTC




          lightclient
        



+1
-1






7702: make chain id u256






It looks like there is still debate around EXTCODE* and whether it will be possible for contracts to introspect the delegated code/code hash at all.  For what its worth, my two cents says that it would be beneficial to have the extra optionality of introspection so you could note a known behavior of a specific delegated codehash. I’m not sure what the drawbacks would be to allowing access to that information during a tx execution.

Author: matt
Date: 2025-01-11T14:06:41.327Z

I don’t really anticipate more changes to 7702 at this point, but if the community has a strong belief something should change you’re welcome on ACD to propose it.
Hopefully 7702 (and prague) will be live in a few months.

Author: julrach
Date: 2025-01-16T17:00:16.785Z

As a follow up to this topic of EXTCODE* ’s behavior, @dv3000 and I put together a technical writeup into code introspection, its relationship with EOF, and a simple path forward: [EIP-7702] Making the Case for “Delegation Introspection” - HackMD
We had an overall positive reception at ACD today and from the next steps given, we’ve put together a PR that reflects our proposed changes to the written spec:

github.com/ethereum/EIPs








Update EIP-7702: update `EXTCODE*` opcodes to act on full "delegation designator"


ethereum:master ← otim-xyz:master



          opened 04:38PM - 16 Jan 25 UTC




            dave-carroll7
          



+3
-3






Here are the proposed changes to `EXTCODE*` behavior over concerns brought up in… this [post](https://hackmd.io/@otim/H1Q7yCHDyl) on HackMD. The proposed changes were discussed at ACD (1/16/25) and agreed upon by those present.

Author: Ivshti
Date: 2025-01-29T08:32:39.131Z

gm, turns out Trezor and Ledger don’t currently support signing authorizations, let alone transaction type 4.
Afaik, they don’t have plans to - we at Ambire contacted Trezor recently and it turns out we’re the first team to bring this to their attention.
It would help if more wallet teams here who plan to support EIP-7702 request this feature from Trezor and Ledger, so that they can adequately prioritize this and don’t think it’s a niche EIP.
Furthermore, both teams told us that they’d only implement such a feature if they had an allow-list of audited designator contracts, which is also something we need to work on as a community. Has anyone started working on this?

Author: akshay-rr
Date: 2025-01-30T15:33:15.120Z

Browser wallets like Metamask and Rabby no longer support eth_sign.
Based on the current implementation of signing the raw hash of the authorization object to produce the signature, would a new RPC method be required? For ex. eth_signAuthorization, similar to personal_sign which is purpose built for signing messages based on EIP-191

Author: colinlyguo
Date: 2025-01-31T14:45:45.381Z

A tiny question about the gas accounting of Cost of Delegation section, other fields are quite clear. But for:

storing values in already warm account = 200

My understanding is this part is used to consider the nonce increment when applying an authorization tuple. Is 200 gas based on some rational estimations? Since I cannot find similar gas measuring in historical EIPs (maybe missed), and SSTORE is more expensive than 200 when considering updates from (i) zero values to non-zero values, and (ii) non-zero values to non-zero values, which the cases are similar to account nonce increment.
Combined with other parts, the 12500 gas consumption is quite reasonable, just a clarification question for a non-understood part.
Great thanks in advance!

Author: jochem-brouwer
Date: 2025-02-01T15:20:19.546Z

This should maybe be clarified in the EIP for completeness. The “storing values in already warm account = 200” looks like it is actually storing 2 values. But we are obviously only delegating to one account in this calculation.
The reason is the number of database operations. First, the nonce has to be updated. But then, the code has to be updated. This is done by putting the codeHash (which is thus the hash of the code) in the account. But, we also need a lookup in the DB from hash → code. We thus need 2 writes to the DB in this case, as opposed to other storage write operations like changing balance or increasing the nonce.

Author: colinlyguo
Date: 2025-02-02T13:10:56.004Z

Thanks and it makes sense. So IIUC updating the nonce and codeHash in a warm account costs 2 * 100 gas (looks like updating the 23 bytes code is already considered in 200 * 23 = 4600 gas). Is there any spec about the 100 gas per warm account update, or is it a new and reasonable number?

Author: jochem-brouwer
Date: 2025-02-02T23:41:46.182Z

This 100 is a result from EIP-2929: Gas cost increases for state access opcodes
It’s not directly mentioned in the EIP, but changing a warm storage slot (when this storage is originally non-empty) charges 100 gas. https://www.evm.codes/ has a nice gas cost calculator, try it yourselves for the SSTORE opcode

Author: colinlyguo
Date: 2025-02-03T13:40:06.659Z

yep, that’s exactly what I am confused about, in the spec of EIP-2200:
If current value does not equal new value
  If original value equals current value (this storage slot has not been changed by the current execution context)
    If original value is 0, SSTORE_SET_GAS is deducted.
    Otherwise, SSTORE_RESET_GAS gas is deducted. If new value is 0, add SSTORE_CLEARS_SCHEDULE gas to refund counter.

neither consumes 100 gas: the first case is 20000 gas, and the second is 5000 gas. https://www.evm.codes/ also shows the same results.

Author: jochem-brouwer
Date: 2025-02-03T14:54:29.350Z

I’ll look into this, I’m rather sure there are situations where 100 gas is charged, but I am now getting confused, maybe I’m thinking of a different situation

Author: peersky
Date: 2025-02-13T05:50:36.463Z

Should authorization_list assertion of auth.chain_id not equal null to be added?
AFAIU if not added, this leaves room for cross-chain replay attacks as auth.chain_id is signed by user, and is not inferred from evm.
Alternatively why don’t require strict equivalence to chain_id?


github.com/ethereum/EIPs








Update EIP-7702: change auth.chain_id to be strictly equal current chain id


ethereum:master ← peersky:peersky-patch-1



          opened 05:48AM - 13 Feb 25 UTC




            peersky
          



+2
-2






As far as I understand, current specification leaves room for cross-chain replay… attack if authorization_list chain_id is null. 

Example attack flow:

1. User signs authorization with chain_id=0 on Goerli
2.  Attacker replays same signature on Mainnet:
```
   // Malicious tx on Mainnet
   authorization_list: [
     [0, 0x... (delegate address), ...] 
   ]
```

Author: wjmelements
Date: 2025-02-19T01:08:30.402Z

It’s the base cost for many opcodes, but some of these opcodes have additional costs.
include/ops.h:56:OP(0x31,BALANCE,1,1,G_ACCESS) \
include/ops.h:66:OP(0x3b,EXTCODESIZE,1,1,G_ACCESS) \
include/ops.h:67:OP(0x3c,EXTCODECOPY,4,0,G_ACCESS) \
include/ops.h:70:OP(0x3f,EXTCODEHASH,1,1,G_ACCESS) \
include/ops.h:91:OP(0x54,SLOAD,1,1,G_ACCESS) \
include/ops.h:92:OP(0x55,SSTORE,2,0,G_ACCESS) \
include/ops.h:99:OP(0x5c,TLOAD,1,1,G_ACCESS) \
include/ops.h:100:OP(0x5d,TSTORE,2,0,G_ACCESS) \
include/ops.h:248:OP(0xf1,CALL,7,1,G_ACCESS) \
include/ops.h:249:OP(0xf2,CALLCODE,7,1,G_ACCESS) \
include/ops.h:251:OP(0xf4,DELEGATECALL,6,1,G_ACCESS) \
include/ops.h:252:OP(0xf5,CREATE2,4,1,G_ACCESS) \
include/ops.h:254:OP(0xf7,AUTHCALL,8,1,G_ACCESS) \
include/ops.h:257:OP(0xfa,STATICCALL,6,1,G_ACCESS) \

Author: SamWilsn
Date: 2025-02-20T17:55:37.633Z

Should we introduce a retroactive EIP prohibiting chain id zero? I don’t see anything in EIP-155 that would prevent that ID, though I’m not particularly well versed in client code.

Author: shemnon
Date: 2025-02-23T06:30:11.473Z

I don’t see how we can ban chain id of zero.  All we can do is control mainnet’s chainId and the related testnets.  We can ban chain id of zero just as easily as we can broker conflicts between competing L2s and alt chains fighting over a coveted chain id, which is to say we have no standing and cannot.
To muddy the waters a bit more, while EIP-7702 ascribes special meaning to chain id zero it should be noted that  EIP-155 dose allow chain id of zero to be encoded, and to be distinct from the “no chain id” signatures.  So the jump to “zero means no chain ID checking” is a client and library shorthand that has crept into quasi-standard where language level Option or Optional values were not used or available.

Author: SamWilsn
Date: 2025-02-28T15:43:58.890Z

Yeah, I guess what I mean is more should we publish an informational EIP saying that using a chain id of zero is a Bad Idea™

Author: peersky
Date: 2025-03-01T06:11:46.354Z

As far as my concern goes, this is user signed message, and current specification is simply inaccurate in guidelines for client implementers, who may write their implementations to accept chain id zero in authorization list, without that being formally against protocol specifications.

Author: FXii
Date: 2025-03-03T15:35:18.490Z

Will this EIP interrupt the workflow of EIPs that rely on EXTCODESIZE to identify whether an address is a contract or an EOA like ERC-223 and ERC-7417?

Author: wjmelements
Date: 2025-03-03T23:21:01.975Z

whether an address is a contract or an EOA

eoas can now be contracts

that rely on EXTCODESIZE to identify whether an address is a contract or an EOA

These workflows never detected EOA because they could not distinguish between an EOA and an empty account. The correct way to distinguish an EOA is to verify one of its signatures.

Will this EIP interrupt the workflow of EIPs that rely on EXTCODESIZE

The standard ERC-223 implementation only checks codesize greater than zero. The codesize of an EIP-7702 contract is greater than zero. So for that pattern an EOA will receive the tokenReceived callback.

Author: FXii
Date: 2025-03-04T12:44:18.387Z

But it will make 7702 EOAs with code unable to receive ERC-223 tokens and ERC-721 tokens by default?
@Dexaran any thoughts on this?

Author: frangio
Date: 2025-03-04T15:06:32.744Z

Delegated EOAs, just like smart contract accounts, have to implement any “callback” functions required to receive assets like ERC-721.
Example

Author: Enigmatic331
Date: 2025-03-05T08:50:21.687Z

Looking at this tx on Sepolia: 0xc5b1bd07d5e4772a847571ee7876196873ea1b79f5a4310b0b1a9eee2e4e7e84
Any idea why the eth_getCode is showing “0x”, rather than 0xef01006c344904168ec002631bc05a979422a8ea4dd45a?

Author: thegaram33
Date: 2025-03-06T09:15:27.308Z

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

Author: sashabeton
Date: 2025-03-06T15:35:27.614Z

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

Author: Dexaran
Date: 2025-03-07T11:58:07.059Z

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.

Author: sashabeton
Date: 2025-03-07T11:59:32.288Z

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.

Author: wjmelements
Date: 2025-03-08T06:12:58.222Z

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

Author: thegaram33
Date: 2025-03-08T07:53:02.379Z

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.

Author: wjmelements
Date: 2025-03-08T13:19:25.533Z

I asked why. What is the rationale?

Author: frangio
Date: 2025-03-08T15:14:15.391Z

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.

Author: wjmelements
Date: 2025-03-10T19:11:05.916Z

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.

Author: frangio
Date: 2025-03-11T21:58:08.051Z

wjmelements:

This griefing vector is going to prevent several “paymaster” designs from working securely.


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.

Author: hellohanchen
Date: 2025-03-12T02:23:52.720Z

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

Author: matt
Date: 2025-03-12T14:54:42.747Z

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.

Author: hellohanchen
Date: 2025-03-16T02:03:31.107Z

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

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.
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:



ERC-7806: Minimal intent-centric EOA smart account ERCs


    I am drafting a new ERC that defines interfaces for intent-centric EOA smart account under EIP-7702. 
Abstract
This proposal defines interfaces to build intent-centric smart accounts under EIP-7702, allowing EOA account owners to define their intents of a transaction and let relayers (solvers) to validate and execute the requests. 
For detailed spec and rationales, please refer to the ERC pull request: 

Backwards Compatibility
This EIP shares the same backwards compatibility issue as EIP-7702. …

Author: adhusson
Date: 2025-03-19T15:20:11.414Z

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?

Author: yongqjn
Date: 2025-03-21T09:48:17.780Z

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.



HackMD



Adding Authorization Status to getTransactionReceipt - HackMD
BackgroundEIP-7702 introduces a new transaction type, namely transaction type 4, to set the code of an EOA to a specific address, enabling EOAs to have smart account capabilities.The transaction introduced a new field authorization_list, which allows...

Author: daniellehrner
Date: 2025-03-21T11:02:41.490Z

yongqjn:

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.


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.

Author: 117l11
Date: 2025-03-22T06:34:22.622Z

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:

Accountability Blur: Contracts wielding EOA-like signing keys could lack clear governance, revocation pathways, or ownership transparency.
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.

Author: yongqjn
Date: 2025-03-24T06:40:52.271Z

daniellehrner:

As soon as the nonce is increased and the codeHash is not empty anymore you know that the code delegation was successful.


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.



 daniellehrner:

In general I think devs should make sure that 7702 txs cannot fail.


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.

Author: shemnon
Date: 2025-03-31T22:02:47.877Z

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


github.com/ethereum/EIPs








Update Parameter to be more specific


master ← shemnon:EIP-7702/magic



          opened 09:59PM - 31 Mar 25 UTC




            shemnon
          



+2
-2






Update the `MAGIC` parameter to be specific to `SET_CODE_TX` scope.






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.

Author: wjmelements
Date: 2025-04-07T15:25:45.798Z

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

Author: matt
Date: 2025-04-09T17:23:54.205Z

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.

Author: shoenseiwaso
Date: 2025-04-13T05:29:21.526Z

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?

Author: codebyMoh
Date: 2025-04-14T09:54:59.246Z

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.

Author: shoenseiwaso
Date: 2025-04-14T10:00:25.848Z

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?

Author: fulldecent
Date: 2025-04-18T15:59:46.135Z

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.

Author: matt
Date: 2025-04-20T20:25:47.844Z

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

Author: nicszerman
Date: 2025-04-21T18:54:38.482Z

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…

Author: peersky
Date: 2025-04-23T07:55:22.999Z

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?

Author: matt
Date: 2025-04-23T14:43:41.557Z

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.

Author: peersky
Date: 2025-04-23T21:39:31.573Z

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);
}

Author: frangio
Date: 2025-04-24T14:03:43.938Z

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.

Author: fulldecent
Date: 2025-04-27T00:47:59.168Z

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!

Author: matt
Date: 2025-04-27T23:33:12.193Z

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.

Author: fulldecent
Date: 2025-04-29T00:29:47.117Z

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.

Author: matt
Date: 2025-04-29T03:19:48.138Z

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

Author: wjmelements
Date: 2025-04-29T17:51:46.161Z

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.

Author: poojaranjan
Date: 2025-05-06T02:20:10.335Z

PEEPanEIP-7702: Set Code for EOAs with Anders Kristiansen

Author: shoenseiwaso
Date: 2025-05-09T14:53:01.961Z

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