Evaluate Parent Safe Support for 4337 Module 0.7

[nlordell]

Context / issue

Nested Safe ownership structures are problematic in the context of 4337 user operations because of storage access restrictions. However, it should technically possible to accomplish at a UX cost, by creating a signing scheme that allows for a "leaf" Safe to execute the user operation, instead of the "root" Safe.

Proposed solution

Specifically, imagine an acyclic Safe ownership tree, where we want to execute a transaction with the root. The idea would be to pick a path to a "leaf" Safe (that is, a Safe with only EOA owners). Since we assume an acyclic Safe ownership tree, this must always be possible. The idea would then be to have the "leaf" Safe sign a user operation to execute executeParent(...) in the module, which will in turn check signatures with the root Safe before executing the transaction. Since the signature check is done in the 4337 execution phase, typical restrictions that apply to storage are no longer there.

The problem with this scheme is that the UX is not great:

• The leaf Safe has a different signature format.
• The user operation would appears as if it was from the "leaf" Safe in "4337-user-operation-explorers".
• Requires the root Safe to be 4337-enabled.

Alternatives

• Evaluate Nested Safe Calling Convention with ERC-4337 #251

Expected Outcome

A PoC for nested Safe user operation execution.