Context / issue

This is in between a feature request and a bug report.

When using a Safe with a passkey signer by calling Safe4337Pack.init, the Safe4337Pack.#SAFE_WEBAUTHN_SHARED_SIGNER_ADDRESS property does not get initialized unless using a predicted safe configuration. Which means that when we are inputting options.safeAddress (for a deployed Safe), Safe4337Pack methods that need the WebAuthn signer address will behave unexpectedly.

For instance, Safe4337Pack.getEstimateFee ends up calling getDummySignature with a zero address, which makes the bundler fail its user operation estimation (in the case of Pimlico this means returning revert AA33).

Proposed solution

There are already two ways for the user to avoid this bug:

• initializing Safe4337Pack using a predicted safe config (removing safeAddress from options, making this block run

  safe-core-sdk/packages/relay-kit/src/packs/safe-4337/Safe4337Pack.ts

  Line 278 in 073a309

  safeWebAuthnSharedSignerAddress =

• initializing Safe4337Pack with the WebAuthn signer address in customContracts.safeWebAuthnSharedSignerAddress

But they are not obvious and could have their place in the Safe4337Pack docs, maybe under "customContracts" which doesn't say that you can override safeWebAuthnSharedSignerAddress.

Or it could be fixed in the SDK by also checking in this if block if the signer is a passkey (and go fetch the right signer address) in the same way it checks for it in the else block.

Steps to reproduce

1. Deploy a Safe with a passkey signer
2. Initialize Safe4337Pack with a safeAddress and without overriding customContracts
3. Test a transaction with the Pimlico bundler/paymaster
4. Pimlico should return revert AA33 because the initial gas estimation (using a wrong getDummySignature) lacks one signature verification, and so it underestimates the real verificationGasLimit needed

Additional context

I can make a PR that checks for a passkey signer in the if ('safeAddress' in options) block, but I don't know if there was a particular reason why it wasn't added. I tried making a transaction with a deployed Safe config and passkey signer (by having updated customContracts) and it worked, so I'm assuming it's fine.