ERC-4337 Contracts 0.4.0 Release Notes

1. Simulated execution indistinguishable from on-chain execution for contracts (AA-92) EntryPoint security improvement. Previously, the 'simulateExection' was defined as a view call to ‘validateUserOperation’ method with 'from' address set to 'address(0)'. This meant that contracts (Account, Paymaster, Aggregator, Factory) could check if their code is running in a simulation or not and behave differently in simulation and execution. It was also impossible to simulate the target call within the context of account-abstraction call, for instance we could not estimate gas for a call on an undeployed wallet. This is solved by adding a separate 'estimateExecution' method to the EntryPoint.

2. Default SimpleAccount now deployed as an upgradeable proxy (AA-74) While ERC-4337 does not have a "canonical" wallet, we aim to provide the best-practices example as part of the contracts package. SimpleAccount is now deployed as an ERC-1967 Proxy, making accounts both upgradeable and cheaper to deploy out-of-the-box.

3. Use standard proxy factories or Create2Factory for Gnosis Safe deployments (AA-91) Used a non-standard approach previously. Now the only difference in a Gnosis Safe deployed by ERC-4337 is the added ‘Eip4337Manager’ module.

4. Enforce 'verificationGasLimit' and revert with meaningful error messages(AA-85) Previously, the 'verificationGasLimit' was not enforced on-chain.

Note: the following changes were made in version 0.3.1 but were not published

5. Implement optional staking and reputation for all contract types - Accounts, Paymasters, Aggregators, Factories (AA-73) As each contract in the UserOperation's life cycle has an opportunity to revert, causing the Bundler to have wasted the computation resources spent on verification, without a reputation system the Bundlers become susceptible to denial-of-service and sybil attacks. Requiring some stake to be locked first to create a new contract in the ERC-4337 system prevents that and allows the Bundlers to track these contracts' reputation. Note that If a contract does not need to access any storage slots at all it does not need to have a stake.

6. Relax storage rules in opcode banning (AA-67) Previously it was forbidden for contracts to access any external contracts' storage slots. This, however, prevented many important use-cases. For instance, a Paymaster that uses an ERC-20 token to pay for UserOperation gas was not feasible. With this new set of rules, the contracts can access the storage slots that are a mapping of the UserOperation Account address or a 'msg.sender' value. Thanks to zkSync for their contribution. They explain this change here: https://v2-docs.zksync.io/dev/developer-guides/aa.html#extending-eip4337