Release v0.7

ERC-4337 Version 0.7.0

Contract changes:

• Simulation functions removed from deployed EntryPoint.
  The simulation methods are meant for off-chain usage, and always revert on-chain. They’re meant to be used only by bundlers. Due to their limited usability, we moved them to a different contract and allowed bundlers to use different methods (e.g. state overrides parameter in eth_call) to simulate the transactions.
• Added delegateAndRevert() helper in EntryPoint to accommodate nodes without state overrides in eth_call and eth_estimateGas
  This allows validation and gas estimation on networks without “state overrides” parameter
• Added ERC-165 "supportsInterface" to the EntryPoint.
• Added a sample TokenPaymaster.
• Added a 10% penalty charge for unused execution gas limit.
  This change is meant to prevent apps from putting transactions with unnecessarily high gas limits, thereby causing the bundler to pack fewer operations into a bundle, losing potential gain. See a more detailed discussion here.
• Removed paymaster’s second call to postOp.
  The second call to paymaster’s postOp function was deprecated as it wasn’t necessary anymore, and now officially removed.
  Now postOp() is called just once. If it reverts, the account’s callData also reverts, but the paymaster still pays for the cost of the execution.
• Added validatePaymasterUserOp and postOp gas limits.
  These gas limits help both the client to better estimate gas for the user operation, and prevent potential security issues.
• Added “gasPrice” parameter to paymaster’s postOp
  This parameter simplifies the work for a token paymaster, to calculate the charge in different currencies..
• Separated offchain UserOperation and packed UserOperation onchain struct.
  To save calldata when calling without a paymaster and to accommodate the new gas limits added to the onchain struct, we decoupled onchain representation of a UserOperation from the offchain one, similar to the initial eth_sendTransaction rpc request and the eventual encoded transaction that’s put onchain.
  This also aligns the structure of ERC-4337 and the future native EIP-7560
• Removed deprecated DepositPaymaster.
• Removed obsolete gnosis safe modules implementation as it was added here.
• Added a new optional account contract api method executeUserOp().
  This addition allows the account to get the full user operation on execution, instead of the original execution, where the account is called directly with the user operation calldata, without having access to the UserOperation metadata during execution phase.
• Minor bug fixes
• EntryPoint better OOG revert handling in userOp execution.
• Various small fixes in the sample contracts
• Minor gas optimizations

ERC changes:

• Separated validation rules into its own separate doc, instead of having a section in the EIP, clearly marking each validation rule <RULE_TYPE>-<RULE_NUMBER>.
  where RULE_TYPE is one of:
  OP - opcode rules
  COD - code rules
  STO - storage rules
  SREP - staked entity reputation rules
  UREP - unstaked entity reputation rules
  EREP - entity-specific reputation rules
  ALT - alternative mempools rules

• Validation rules changes from 0.6.0:
  OP-013 Banning unassigned opcodes to prevent future vulnerabilities via new opcodes.
  OP-051 Allow calling EXTCODESIZE ISZERO to allow calling depositTo().
  OP-054 Forbidding calls to EntryPoint besides depositTo().
  STO-033 Allowing staked entity reading storage on non-entity contracts.
  This relaxation simplifies and extends the usability of paymasters.
  EREP-020 Staked factory is accountable for account breaking validation rules.
  UREP-* Unstaked reputation rules.
  These rules prevent unstaked paymasters from invalidating many user operations at once.
  ALT-* Alt mempools/canonical mempool interactions rules.
  OP-070 Transient storage rules.

Release v0.6

Following feedback from the community, we have pushed and deployed a new version of the EntryPoint contract, with a few modifications. The latest address is 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

The changes are:

• new userOpHash algorithm (#245)
• nonce managed by EntryPoint (#247)
• prevent recursion of handleOps (#257)

Together, they guarantee that now there is a consistent view of the UserOperation :

• The UserOperation hash is always unique
• Events emitted by the execution of a UserOperation are now uniquely mapped to a UserOperation

This is primarily relevant to external entities (block explorers, wallets, and anyone processing events).

We also asked OpenZeppelin to update the audit to include these changes

The announcement

Effect on Bundlers

If a bundler has an "off-chain" calculation of the hash, it should be updated to the new implementation of the getUserOpHash() helper method in the EntryPoint.

Effect on Wallets

• Existing account contracts can use the new EntryPoint as is, but they can improve their performance by REMOVING the nonce check, as EntryPoint already verifies the nonce uniqueness.
• BaseAccount was updated, so accounts should be recompiled against it.
• the nonce() method was renamed to getNonce(). This is in part for reflecting the new mechanism (it references EntryPoint to read the nonce), but also since in a "[Gnosis] Safe" account we can no longer use the nonce method, as Safe uses nonce for non-AA transactions, and getNonce (and EntryPoint) for AA-based transactions. There is no conflict between the two.
• In order to verify the account is working with a new EntryPoint, it can actively call the entryPoint.getNonce() method (this method is already called from the BaseAccount.
• Wallets should read the next nonce to use in a UserOperation using the getNonce() method, instead of nonce.
• Wallets should also decide if they want to use the "two-dimensional" nonce, by using different values for the key part. (Note that the default GnosisSafeAccount currently enforces sequential nonces, just like a normal safe)

Effect on Block Explorers

Block explorers are not affected directly. They can now safely assume that userOpHash has a unique value.

In conclusion

Even though these changes were not critical, as there were no security implications, we felt that it is better to push such changes now, before wallets get widespread adoption.

version 0.5.0

Account-Abstraction release 0.5.0

This version contains several important changes to the account and entrypoint.
It is also audited by OpenZeppelin (see the audits in the audits folder)

Below are the Major Changes:

Changes to IAccount

• IAccount.validateUserOp changes:
  • removed the "aggregator" parameter.
  • No longer revert on signature error, but report it as a return value.
  • The return value from it is time-range, signature success/failure and (possibly) aggregator.

Changes to Paymaster

• IPaymaster.validateUserOp changes:
  • Like the Account, the return value defines a time-range and signature success/failure
  • Note that in case of signature failure (as in a case of VerifyingPaymaster, it is flagged through return value, and not revert.

Changes to IEntryPoint

• added simulateHandleOp, to simulate a full UserOperation execution (not only validation)
• (and all the API changes required by the above interface changes)

v0.4.0

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