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
2 Likes
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?
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.
- 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?
Can someone clarify: Can a user perform an ERC20.approve during validateUserOp?
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?
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.
1 Like
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)
alas, no.
That requires modifying storage associated with another entity, that isn’t the account itself
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.
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?
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)
1 Like