[4337] Evaluate Singleton Signers + Staked Factory

[nlordell]

Context / issue

The 4337 module currently allows creating a new account (using UserOperation.initCode) and executing an action atomically.

Furthermore, support for additional signing schemes (such as WebAuthn using P256 curve signatures) is already supported by the Safe by creating a dedicated signer contract per owner (in the case of WebAuthn, one contract per public key) implementing the signature validation logic using ERC-1271.

However, ERC-4337 limits the number of CREATE2 calls to 1 when using initCode meaning that for example, it is currently not possible to deploy a Safe using account abstraction with nothing but a WebAuthn signer.

Proposed solution

Implement a singleton isValidSignature implementation that can be shared across multiple Safes. You can, for example, deploy sequential new Signer{salt: n}() for sequential n to allow multiple owners that use this signing strategy. Each signer would keep a mapping(safe => data) for each Safe's data required for signature verification.

The downside is that this would still require a staked factory (because the Signer would access associated storage).

Alternatives

• [4337] Determine Whether or Not 4337 Support Multiple CREATE2 Calls From a Staked Factory #147
• [4337] Launchpad Account Deployer to Work Around 4337 Limitations #149

Outcome

A script similar to runOp where an owner can be deployed with the account as part of the single bundle.

The focus is not to have a useful signer contract, just a process that is supported under 4337.

[nlordell]

#159 shows how to setup a staked factory in a way that works with the reference bundler and allows for associated storage reads in validateUserOp for new accounts.

This can be used with the singleton signer solution proposed in this issue.

[nlordell]

Currently blocked by #160