SafeECDSASignerLaunchpad has unclear support for multi-owner accounts

[mmv08]

Description

When working on #360, we wanted to add two signers to the newly created Safe account: the user's connected wallet and the created passkey signer. However, this turned out to be non-trivial because SafeECDSASignerLaunchpad has unclear/limited support for multi-owner accounts.

1. There's no straightforward way to specify multiple owners for the Safe configuration.
   When setting up the Safe, the contract hardcodes the signer/threshold parameters, leaving the only option to extend the configuration in the call executed later in the function or the optional delegatecall in the Safe setup phase.
   

   safe-modules/modules/passkey/contracts/4337/SafeECDSASignerLaunchpad.sol

   Lines 228 to 233 in 5a5f7f6

   	{
   	address[] memory owners = new address[](1);
   	owners[0] = ICustomECDSASignerFactory(signerFactory).createSigner(signerX, signerY, signerVerifier);
   	ISafe(address(this)).setup(owners, 1, setupTo, setupData, fallbackHandler, address(0), 0, payable(address(0)));
   	}

2. During the validation phase, it only validates the signature from one (Passkey) owner. This is a potential security risk since a single signer has full control over a Safe.

Additional context

This issue was created to explore potential solutions and decide where we want to improve this situation. While briefly discussing it in a standup meeting, we agreed that solving it would be complex because it would require duplicating the whole Safe signature check logic in the contract (one of the solutions).

[nlordell]

Correct me if I'm wrong, but would you say that the expected outcome would be to:

1. evaluate the security implications of the current setup? (Basically, what you said in the standup where we a single owner has full control of the multisig)
2. evaluate with the product team what the requirements are for multi-owner use cases
3. propose changes to the API to adjust for potential multi-owner use cases?

[mmv08]

Correct me if I'm wrong, but would you say that the expected outcome would be to:

1. evaluate the security implications of the current setup? (Basically, what you said in the standup where we a single owner has full control of the multisig)
2. propose changes to the API to adjust for potential multi-owner use cases?

Bang on!

Something that came to me while writing the issue: IIRC, the current launchpad contract was your experiment to make Passkey signers work with 4337, and we never defined any formal requirements (product, technical, etc) for the contract. Perhaps this is the moment to do this, sync with Niharika and formalize the requirements, etc

[nlordell]

This is blocked on product decision on what must be supported for SDK passkey support.

[nlordell]

We found a general solution with the shared signer, which would work for arbitrary ownership structures, so this is once again unblocked.