Title: ERC_7562__Account_Abstraction_Validation_Scope_Rul
Category: ERCs

Author: dror
Date: 2023-11-18T15:57:04.301Z

This is a discussion for ERC-7562 - Add ERC: Account Abstraction Validation Scope Rules by drortirosh · Pull Request #105 · ethereum/ERCs · GitHub
This is an extraction of the Account-Abstraction validation rules out of ERC-4337 itself

Author: Hugo0
Date: 2024-03-25T15:09:55.249Z

Could I get some clarification on how that affects a userop that e.g. calls a contract that only releases funds after a certain block.timestamp? Does this check just get ignored during validation, but still gets run during execution? or does the userop just get dropped?

Author: dror
Date: 2024-03-25T20:15:32.934Z

The validation rules are not checked on-chain.
They are used by bundlers to protect against denial of service attacks: someone who submits a large # of UserOps that go into the mempool, but later fail validation, and thus just waste CPU of bundlers, without ever paying gas fees.
Also, the validation rules only apply to the validation phase. Since once validation is done, the account agreed to pay the gas fees.
The execution is free to do whatever it wants.

Author: frangio
Date: 2024-06-27T16:40:31.029Z

If the entity (paymaster, factory) is staked, then it is also allowed:

[STO-033] Read-only access to any storage in non-entity contract.




Can someone clarify for me: does this mean that the entity is allowed access, or that any contract is allowed access?

Author: matthiasgeihs
Date: 2024-07-04T09:09:33.041Z

Can someone clarify: Can a user perform an ERC20.approve during validateUserOp?

Author: matthiasgeihs
Date: 2024-07-04T09:26:17.977Z

And is eth-infinitism’s TokenPaymaster.sol compliant with ERC-7562?
In other words, does calling ERC20.safeTransferFrom(token, userOp.sender, address(this), tokenAmount) during validatePaymasterUserOp conflict with ERC-7562?

Author: dror
Date: 2024-07-14T13:17:33.252Z

frangio:

Can someone clarify for me: does this mean that the entity is allowed access, or that any contract is allowed access?


The validation checks are done by validation phase: factory , account (validateUserOp) and paymaster (validatePaymasterUserOp), by whatever inner call.
That means that a staked paymaster is allowed to call a contract that in turn performs any “read” operation in its storage (e.g. check whatever config, balance, proxy call to implementation, etc)
Care should be taken, though. This paymaster must carefuly verify that the external contract it uses can’t cause the paymaster itself to get throttled:
e.g.: If I use a token that uses a proxy  (e.g. USDC), at any point in time the owners of the token may change the proxy “implementation” pointer, and cause all pending payments to be rejected, and thus the paymaster gets throttled.
However, probably the damage to the token itself would be much larger, and thus a paymaster can safely assume that any implementation change will have all existing pending transfers valid.
Another, more subtle example: if a paymaster uses an oracle, and someone manages to make a large # of UserOps that “barely fit” the needed gas price just before the token’s price drops, it might cause all those UserOps to get reverted, and the paymaster gets throttled or even banned.

Author: dror
Date: 2024-07-14T13:21:11.476Z

matthiasgeihs:

And is eth-infinitism’s TokenPaymaster.sol compliant with ERC-7562?
In other words, does calling ERC20.safeTransferFrom(token, userOp.sender, address(this), tokenAmount) during validatePaymasterUserOp conflict with ERC-7562?


Yes, the paymaster is compliant, as long as it is staked.
A staked entity is allowed to access the account’s as well as its own “assocated storage”, and thus move balance from the account to itself.
(Note that it can’t move balance to another account, since its a storage not associated with the account (or paymaster). It can’t mint/burn either, since that would change the “totalSupply” of the token, which again, isn’t associated with a specific address)

Author: dror
Date: 2024-07-14T13:23:01.422Z

matthiasgeihs:

Can someone clarify: Can a user perform an ERC20.approve during validateUserOp?


alas, no.
That requires modifying storage associated with another entity, that isn’t the account itself

Author: andysim3d
Date: 2024-08-15T17:58:47.392Z

A question of test_rule[[STO-022]unstaked][paymaster][account_reference_storage_init_code][drop1] - I take a look at EIPS/eip-7562#storage-rules but STO-022 only mentioned Access to associated storage of the account in an external (non-entity) contract is allowed if there is an initcode and the factory contract is staked. not very sure why unstaked paymaster will cause a dropped UO in this scenario.

Author: emrah23
Date: 2024-11-08T18:29:32.036Z

Could I get some clarification on when opsSeen variable is incremented for both canonical mempool and alt-mempool. The definition is:
opsSeen: a per-entity counter tracking how many times a unique, valid UserOperation referencing this entity was received by the bundler. This includes UserOperations received via incoming RPC calls or through a P2P mempool protocol.
Does that mean if the paymaster is having some violation, such as storage, the UserOperation is considered invalid, and expected to be dropped by Bundler. But does that mean opsSeen for paymaster is not incremented?

Author: dror
Date: 2024-11-20T21:30:07.551Z

emrah23:

opsSeen: a per-entity counter tracking how many times a unique, valid UserOperation referencing this entity was received by the bundler.


The opsSeen is counted only for UserOperations that passes the first validation (when accepted over the rpc or p2p connection) and propagated to other nodes via the mempool.
If the UserOp is dropped in its initial validation (either on storage/opcode validation rule, or a “mere” revert), the opsSeen counters are unaffected.
The bundler protects itself using a connection quota mechanism.
The reputation rules (based on opsSeen/opsIncluded) kick in when the UserOperation fails when it is about to be included in a bundle. At this point, it already passed the above first validation and was propagated to all other bundlers on the p2p network (which means, many bundlers will try to include it in a bundle - and fail, since validation failures are not propagated in the mempool)

Author: colinlyguo
Date: 2025-01-08T16:07:17.178Z

A small question regarding the rule: [AUTH-010] A UserOperation may only contain a single EIP-7702 authorization tuple.
for userop, they cannot have an authorization tuple if I understand correctly. So does the rule mean the bundle transaction can only have one authorization tuple?
another question is about the rules of “The need for 2nd validation before submitting a block”, I think to perform ERC-7562 validation, it seems that getting the bundle transaction’s trace is unavoidable. Would this introduce expensive overhead of block proposer’s mempool?

Author: dror
Date: 2025-01-15T00:39:21.786Z

for userop, they cannot have an authorization tuple if I understand correctly. So does the rule mean the bundle transaction can only have one authorization tuple?

A UserOperation can include an eip7702 tuple - the account itself can be an eip-7702 account (that is, and EOA that gets an account code)
A bundler that handles such UserOperations, can submit a bundle that  includes multiple authorization tuples, for all the UserOperations in the bundle that require it.

The need for 2nd validation before submitting a block

Yes, a bundler is required to perform a 2nd validation against all UserOperations before creating a bundle, since from the time they were submitted until the current time, the account state might differ, and some UserOperations might be invalid.
Currently bundlers are not “block proposers”, but external entities that generate a bundle transaction out of UserOperations from the UserOperations mempool.
You can compare the work of such a bundler to a “searcher”, that submits a set of transactions to the block proposer, in order to collect MEV.

Author: colinlyguo
Date: 2025-01-15T09:05:53.988Z

Thanks for your reply, that helps me a lot. thus the sequencer is not required to validate during block building.

A bundler that handles such UserOperations, can submit a bundle that includes multiple authorization tuples, for all the UserOperations in the bundle that require it.

(Updated after rethinking): I just want to make sure I understand this correctly: In this context, does this mean that the bundle transaction could potentially be an EIP-7702 transaction that includes the delegations necessary to support UserOperations where the sender is an EOA first-time delegate to code (or change delegation)? If so, would this potentially require a new RPC method (or methods) to be introduced for the bundler to collect and manage these authorizations?

Author: alex-forshtat-tbk
Date: 2025-01-30T14:07:43.545Z

colinlyguo:

Does this mean that the bundle transaction could potentially be an EIP-7702 transaction that includes the delegations necessary to support UserOperations where the sender is an EOA first-time delegate to code (or change delegation)?


Yes, it is expected that most bundle (handleOps) transactions will be EIP-7702 Type-4 transactions.



 colinlyguo:

Would this potentially require a new RPC method (or methods) to be introduced for the bundler to collect and manage these authorizations?


There is only a single new optional field, authorizationTuple, that is added to the existing eth_sendUserOperation API, there seems to be no need to create an entirely new API for that.

Author: colinlyguo
Date: 2025-01-30T16:28:07.182Z

Thanks for the reply, it makes sense and helps a lot.

Author: wminshew
Date: 2025-02-07T07:32:15.975Z

afaict the storage rules prohibit ~most smart accounts from being signers for other smart accounts; can someone help me understand what I might be missing? I feel like these must be expected to work in the endgame but I’m having trouble seeing it atm. Appreciate any help, thank you

Author: alex-forshtat-tbk
Date: 2025-02-20T11:09:18.804Z

wminshew:

the storage rules prohibit ~most smart accounts from being signers for other smart accounts


Having accounts depend on each other as part of the UserOperation validation presents a serious challenge. The “signer” smart account is not an “entity” of the UserOperation, and the system has no ways to track or guarantee its behaviour.
Personally, I think it is technically possible to define a generic “signer” staked entity in a future revision of ERC-7562, and track this generic entity’s reputation based on a set of rules similar to the Paymaster-related rules, but so far there was no major use-case that would make this change urgent.



 wminshew:

I feel like these must be expected to work in the endgame but I’m having trouble seeing it atm.


It may be a strong requirement if multi-smart-account-multisigs become popular, but in many cases the “sender” smart account can also just store the keys of the “signer” smart contract in its own internal storage, use these credentials during the validation phase in accordance to ERC-7562 rules, and maybe even, during the execution phase, check with the “signer” contract that these keys are still valid.