Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate Parent Safe Support for 4337 Module 0.7 #265

Open
nlordell opened this issue Feb 15, 2024 · 0 comments
Open

Evaluate Parent Safe Support for 4337 Module 0.7 #265

nlordell opened this issue Feb 15, 2024 · 0 comments

Comments

@nlordell
Copy link
Collaborator

nlordell commented Feb 15, 2024

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

Expected Outcome

A PoC for nested Safe user operation execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant