Evaluate Providing Additional Context Data to Module Guards

[akshay-ap]

Evaluate Providing Additional Context Data to Module Guards

[akshay-ap]

Approach 1: Modify Safe Contract and module guard interface to include context field

This approach involves adding a context parameter to the module guard's checkModuleTransaction function and introducing two new overloaded functions in the Safe contract that accept context as a parameter.

POC here:
https://github.com/safe-global/safe-smart-account/compare/feature-context-in-module-tx?expand=1

Pros:

• The module guard interface introduced in v1.5.0 has not yet been released, so it is safe to assume that these changes won't force any redeployment.
• Changes in Safe contract are backward compatible.

Cons:

• Increases the size of Safe contract but still within the 24kb limit.
• To use this feature modules have to adapt their implementation.

Approach 2: Set context information in Guard before execution of module transaction.

In this approach, the module guard provides a method to set context information. The module guard stores the context information in its storage (can also use transient storage). The module guard reads the context information from its storage in checkModuleTransaction function.

Safe account stores the context in Guard using setContext(bytes32 moduleTxHash, bytes calldata context) whenever required before executing the module transaction. This can be achieved by using multisend or a separate transaction. Module guard has to implement additional logic to permit calls that are to itself and method signature is bytes4(keccak256(setContext(bytes32,bytes))).

Pro

• No Change in Safe contract.

Cons

• Module guard has to implement additional logic to store context information.
• Additional gas costs associated with storing/reading context info in module guard.
• A call to guard must be made before the transaction.

Approach 3: Module stores context information in its own storage. Module guard reads context info from module storage.

In this approach, it is up to the module to store the context information for the module transaction and make it available to the guard when requested. The module guard reads the context from the module storage before executing the module transaction.

interface IModule {
 function getContext(bytes32 moduleTxHash) external view returns (bytes memory);
}

Guard implementation:

...
 function checkModuleTransaction(....){
 bytes memory context = IModule(module).getContext(moduleTxHash);
 // check context
 ...
 }
...

Pros:

• No change in Safe contract

Cons:

• Requires module to implement additional interface to provide context information to guard.
• Additional gas costs associated with storing/reading context from module storage.
• Module and Guard need to have an agreement on a protocol (to generate nonce, replay protection)

Personal opinion: I would prefer approach 1. It is also backward compatible with existing Safe contracts.

[nlordell]

If we want to support module guards with external context for only specific modules, we can implement the guard in such a way that:

• Use Option 2 from Akshay's proposal above
• Modify the guard so that it has exceptions to the specific modules and a specific ISpecializedGuard interface
• Have the modules call that guard interface.

Concretely, what this looks like for the 4337 module would be:

• A negative control guard has an exception to the Safe4337Module contract.
• The negative control guard additionally implements IUserOpGuard interface
• The Safe 4337 Module calls checkUserOp(...) on the guard if installed on the Safe during user op validation.

This requires changes to the Safe 4337 module (which is true for all approaches above) but does not require any changes to the core smart contracts.