Extending EIP-4337

To provide DoS protection for the operator, EIP4337 imposes several restrictions on the validation step of the account.

Most of them, especially those regarding the forbidden opcodes, are still relevant. However, several restrictions have been lifted for better UX.

Extending the allowed opcodes

• It is allowed to call/delegateCall/staticcall contracts that were already deployed. Unlike Ethereum, we have no way to edit the code that was deployed or delete the contract via selfdestruct, so we can be sure that the code during the execution of the contract will be the same.

Extending the set of slots that belong to a user

In the original EIP, the validateTransaction step of the AA allows the account to read only the storage slots of its own. However, there are slots that semantically belong to that user but are actually located on another contract’s addresses. A notable example is ERC20 balance.

This limitation provides DDoS safety by ensuring that the slots used for validation by various accounts do not overlap, so there is no need for them to actually belong to the account’s storage.

To enable reading the user's ERC20 balance or allowance on the validation step, the following types of slots will be allowed for an account with address A on the validation step:

1. Slots that belong to address A.
2. Slots A on any other address.
3. Slots of type keccak256(A || X) on any other address. (to cover mapping(address => value), which is usually used for balance in ERC20 tokens).

What could be allowed in the future?

In the future, we might even allow time-bound transactions, e.g. allow checking that block.timestamp <= value if it returned false, etc. This would require deploying a separate library of such trusted methods, but it would greatly increase the capabilities of accounts.