Safe 4337 Signer Launchpad

[nlordell]

Related to #149, follow-up to #182

This PR provides another approach to Safe initialization to accommodate for custom signers that are deployed along with the Safe. See #182 for more context.

This launchpad implementation is very specific to custom signers and introduces a new IUniqueSignerFactory interface that must be implemented to work with it. The name “unique” signer is not great, but named this way since for a given factory and some “signer data”, a ISignatureVerifier implementation will correspond to a unique address. In the example of P-256 and WebAuthn signers, this means a P-256 public key will correspond to a unique on-chain address with an ISignatureVerifier implementation.

This implementation works by tying the Safe address to the signerFactory, signerData and Safe setup parameters. This means a couple of things:

1. The Safe address is unique for a specific initial configuration (owner, singleton, fallback, modules, etc.); the same property holds for the existing SafeProxyFactory
2. Unlike Launchpad Contract for ERC-4337-Compatible Initialisation #182, the Safe address is not tied to the first user operation (in fact, the user operation is signed with the same owner as the Safe will use!)

sequenceDiagram
    actor B as Bundler
    participant E as EntryPoint
    participant F as SafeProxyFactory
    participant P as SafeProxy (Account)
    participant L as SafeSignerLaunchpad
    participant S as Safe (Singleton)
    participant M as Safe4337Module
    participant U as IUniqueSignerFactory
    participant A as Signer
    actor T as Target

    B  ->> +E: handleOps([userOp])
    E  ->> +F: CALL(userOp.initCode[:20])
    F  ->>  P: CREATE2
    F  ->>  P: setup(initHash)
    P  ->>  L: setup(initHash)
    note over L: SSTORE(initHash)
    F -->> -E: ok

    E  ->> +P: validateUserOp(userOp)
    P  ->> +L: validateUserOp(userOp)
    note over L: require(getInitHash(userOp) == initHash)
    L  ->> +U: isValidSignatureForSigner(operationData, signature, signerData)
    U -->> -L: magic
    L -->> -P: validationData
    P -->> -E: validationData

    E  ->> +P: initializeThenUserOp<br>(singleton, signerFactory, signerData, ...setupParams, callData)
    P  ->>  L: initializeThenUserOp(…)
    note over L: SafeStorage.singleton = singleton
    L  ->> +U: createSigner(signerData)
    U  ->>  A: CREATE2
    U -->> -L: owner
    L  ->>  S: setup([owner], 1, ...setupParams)
    note over S: standard Safe setup
    L  ->>  P: DELEGATECALL(callData)
    P  ->>  S: DELEGATECALL(callData)
    S  ->>  M: execUserOp(…)
    M  ->>  P: executeFromModule(…)
    P  ->>  S: executeFromModule(…)
    S  ->>  T: Ether
    P -->> -E: ok

Loading

Implementation Notes

Currently, the implementation only supports a single signer, but can be changed to support multiple (by turning signerFactory and signerData into arrays).

Downsides

The downsides of this implementation over #182 is that it is a solution very specific to deploying Safes with custom signing schemes that require additional contract deployments and not a general solution to complex Safe setups in the context of ERC-4337.

[mmv08]

I like the PR

[coveralls]

Pull Request Test Coverage Report for Build 7193084547

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 7180707836:	0.0%
Covered Lines:	33
Relevant Lines:	33

---

💛 - Coveralls