Allow relaying of counterfactual Safe deployments

[schmanu]

Description

Through our UI we offer to pay later for the safe deployment. This will cause the Safe to be deployed with its first transaction.

When a user chooses to do so on a chain which supports relaying (currently Gnosis Chain and partially Arbitrum), we do not offer relaying for the first counterfactual deployment tx as the relay service does not allow such transactions.

A counterfactual transaction is a multiSend to the MultiSendCallOnly contract which always contains two transactions:

1. createProxyWithNonce on the SafeProxyFactory
2. executeTransaction on the newly deployed Safe

Requirements

Allow counterfactual txs through the relay service. If it is a call to the MultiSendContract check

• [ ] if all calls are executeTransaction (batched execution - is already supported I think just mentioning as it should not break)
• [ ] that the first call is calling createProxyWithNonce to a SafeProxyFactory and the second call is executeTransaction to any address

Additional information

No response

[iamacook]

Whilst 1. is relatively easy to implement, 2. will require us to reduce the strictness of the relayer.

Currently, we ensure that the executeTransaction call is coming from a deployed Safe. We'd need remove this check, but any matching signature will then be relayed. This is something we need to discuss before implementation.

[schmanu]

Alternatively we could predict the Safe address from the deployment of the first transaction and check that the second transaction is calling to that address.

[iamacook]

Alternatively we could predict the Safe address from the deployment of the first transaction and check that the second transaction is calling to that address.

Prediction requires on-chain data (proxy creation code) and gets quite complicated when considering chain-specific requirements, e.g. zkSync.

Ideally we'd use the SDK but it's an extra dependency for a somewhat simple change. We could hardcode/indefinitely cache the proxy creation code but they each come with caveats: remembering to update/making an on-chain call (although now possible!).

Great suggestion though - I'll make sure to include it in our discussion.

[iamacook]

As we will be moving away from this activation method with multichain, I will close this as it will soon be no longer relevant. For futurue reference: there are also indexing issues related to the above.