You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the UserOp creates a new account using a staked factory contract, then the entity may also use storage associated with the sender
This refers to the fact that access to the account's associated storage is only permitted to be used by entities (including the account entity during validateUserOp) if the factory is staked. So a validateUserOp that makes use of some mapping(account => value) in a separate contract, while it would be generally be considered fair use, it requires staking for account creation.
The factory contract should be staked. @akshay-ap suggested we can create a "wrapper factory" that supports the required staking, without needing to modify the current factory and change existing Safe infrastructure.
Alternatively, it would be possible to try and work with bundlers directly to add exceptions for Safe (there is prior-art for this: alchemyplatform/rundler#231). Personally, I'm not a fan of this approach (it feels icky to go against the spec if it is possible to so and makes things dependent on specific bundler support).
This issue is here to document some of my findings around 4337 requirements, specifically in the context of account creation.
In particular the section on un-staked entities mentions that:
This refers to the fact that access to the account's associated storage is only permitted to be used by entities (including the account entity during
validateUserOp
) if the factory is staked. So avalidateUserOp
that makes use of somemapping(account => value)
in a separate contract, while it would be generally be considered fair use, it requires staking for account creation.In particular this means that:
Alternatively, it would be possible to try and work with bundlers directly to add exceptions for Safe (there is prior-art for this: alchemyplatform/rundler#231). Personally, I'm not a fan of this approach (it feels icky to go against the spec if it is possible to so and makes things dependent on specific bundler support).
References
The text was updated successfully, but these errors were encountered: