ERC-4337 Version v0.9
Deployment
WARNING! Always verify the EntryPoint deployment address and code hash with the official security audit report before updating. The EntryPoint is a privileged singleton contract that controls the Accounts and Paymasters.
EntryPoint v0.9
0x433709009B8330FDa32311DF1C2AFA402eD8D009
SenderCreator v0.9
0x0A630a99Df908A81115A3022927Be82f9299987e
Summary
1. Compatibility
This version is ABI-compatible with v0.8 and v0.7, and does not require changes in Accounts and Paymasters, unless they want to use any of the new features.
All changes in this version are made without breaking changes to the EntryPoint ABI.
The bundlers need to be aware of the new features in order to join the v0.9 EntryPoint UserOp mempool.
2. Enable parallelizable Paymaster signing with paymasterSignature field.
Previously, the entire paymasterAndData field was included in the userOpHash, forcing users to wait for it to be ready.
When using a signature-based Paymaster service, this created a noticeable and unnecessary delay for the users between taking action and seeing the confirmation UI.
Now, you can use the paymasterSignature parameter to pass the data to your Paymaster even after the UserOperation is signed by the Wallet.
See the documentation for this feature for more details: https://docs.erc4337.io/paymasters/paymaster-signature.html
3. Enable specifying the UserOperation validity range using block numbers.
Previously, the validAfter and validUntil parameters could only specify the timestamps.
However, in some cases the actual smart contracts, dapps or protocols being used rely on block numbers to specify validity ranges for some actions, and this prevented the efficient use of UserOperation’s validity range in those dapps.
Now, setting the highest bit of both validAfter and validUntil parameters indicates to bundlers and the EntryPoint that these values specify the UserOperation’s validity range using block numbers.
4. Ignore the initCode without reverting if the Account already exists.
Enable use of a two-dimensional nonce in UserOperations with initCode.
Previously, the initCode parameter was only allowed to be present in the UserOperation that performs the deployment of the Account.
However, in practice this prevented the undeployed Accounts from using the two-dimensional nonce feature, as only one of the parallel UserOperations could succeed and the rest would revert.
Now, the initCode will be silently ignored if the sender Account already exists, and the UserOperation will execute as usual.
This emits the IgnoredInitCode event for the purpose of observability and debugging.
WARNING: Previously, a contract could make an assumption that if a UserOperation has nonzero initCode, then it's the first UserOperation seen by the account. This assumption is no longer correct. If your Account contracts’ code relies on the old behaviour of the initCode field, this change may affect the security of your Account. As long as your Account does not currently have any logic specific for this case, it is safe to update it.
5. Enable querying the current UserOperation hash during execution.
We have identified a number of use-cases where a third-party contract may benefit from knowing the current UserOperation's userOpHash value.
In order to expose this value, we have added the getCurrentUserOpHash function to the EntryPoint contract.
Note: This function is only available during the execution frame.
6. Better error messages.
Some error messages in the contracts were improved with additional parameters added.
Note: Most error structures remain unchanged in this version of the EntryPoint contract. However, we intend to improve error handling and debugging in ERC-4337 in the future. The FailedOp and AAxx error format may change in a future revision of the ERC-4337.
7. Emit the address of the initialized EIP-7702 Account implementation delegation target.
We have added the EIP7702AccountInitialized event to expose the EIP-7702 delegation target.
8. Make BasePaymaster accept the owner as a parameter instead of using msg.sender
Previously, the msg.sender was hardcoded to become the owner of the BasePaymaster contract upon deployment.
However, this poses a problem when deploying a Paymaster using any kind of a factory contract. With this version, the owner parameter becomes an explicit part of the constructor.