[4337] Determine Whether or Not 4337 Support Multiple CREATE2 Calls From a 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

It may be the case the ERC-4337 allows a staked factory to execute multiple CREATE2s, then we should use that approach instead (as it would be the simplest and not require any additional contract work). To evaluate this, potentially reach out to:

• Pimlico
• Alchemy

Alternatives

• [4337] Evaluate Singleton Signers + Staked Factory #148
• [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]

From browsing the reference bundler source, it looks like the CREATE2 limitation is regardless of the staking (although I may be misinterpreting the code):

https://github.com/eth-infinitism/bundler/blob/436f12241b06397989fd7a522af0deca0d46ac09/packages/validation-manager/src/TracerResultParser.ts#L259

Gathering experimental results...

[nlordell]

Indeed the reference bundler does not support this. Even a staked factory would error with:

factory with too many CREATE2

This is inline with the specification, which just mentions that:

When staked, an entity is also allowed to use its own associated storage, in addition to sender’s associated storage.

So staking only applies to storage access rules, but not to banned op-code rules.