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