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:

• Align on-chain and off-chain UserOperation hash - PR#245

• Nonce managed by EntryPoint - PR#247

• Prevent recursion of handleOps - PR#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).

Note that we did not introduce these changes because we found a security breach in the contracts or those external tools - but in order to prevent future bugs in such tools. For example, since userOpHash couldn't be trusted to be unique, paymasters had to provide their own uniqueness check (which we added to the VerifyingPaymaster)

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.

We would also like to thank everyone in the developer community who helped us identify, research, and resolve these issues.