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
An existing use case for this is the CoW Protocol Composable CoW framework, where specialised signature validator implementations are used to make custom and "programable" orders for CoW Protocol. It allows injecting additional logic into the isValidSignature check for a CoW Protocol order for additional on-chain guarantees (such as require(block.timestamp > START_TIME) to implement good-after-time orders).
Additional Signing Schemes
A commonly requested feature is to add support for additional signing schemes:
Secp256r1 for PassKey support
Session key management (where a session key would allow multiple transactions of a specific kind to be executed over a period of time)
While this is currently mentioned in the spec, a possible implementation of this is not clearly defined ATM see #62.
User Operation Signature Support
Additional signing logic for ERC-4337 user operations. Specifically, it would be nice to allow similar behaviour to plugins applied to ERC-4337. That is, plugins currently get access to execute transactions on behalf of Safes that enable them, so some analogy should exist for 4337 user operations where custom validateUserOp logic could trigger a transaction execution from an account.
A potential implementation would have modules expose:
A function for validating user operations. Custom logic can be added (for example, check what is being called and what parameters are used)
A fallback that would execute as a plugin a transaction on the account. This ensures a registry check to verify that the module has not been flagged (registry checks during user op validation is tricky... while possible if we guarantee that user ops are submitted with a staked paymaster, it would further balloon gas cost of using 4337 over Safe Protocol even further).
The proposed implementation would require these modules to be simultaneously installed as a plugin, a fallback handler and a signature validator, which isn't super clean.
The text was updated successfully, but these errors were encountered:
This issue is meant to document potential use cases for signature modules in the Safe Core Protocol
Extending Support for ERC-1271 Signatures
See https://github.com/safe-global/safe-core-protocol-specs/blob/main/modules/README.md#signature-validators.
An existing use case for this is the CoW Protocol Composable CoW framework, where specialised signature validator implementations are used to make custom and "programable" orders for CoW Protocol. It allows injecting additional logic into the
isValidSignature
check for a CoW Protocol order for additional on-chain guarantees (such asrequire(block.timestamp > START_TIME)
to implement good-after-time orders).Additional Signing Schemes
A commonly requested feature is to add support for additional signing schemes:
While this is currently mentioned in the spec, a possible implementation of this is not clearly defined ATM see #62.
User Operation Signature Support
Additional signing logic for ERC-4337 user operations. Specifically, it would be nice to allow similar behaviour to plugins applied to ERC-4337. That is, plugins currently get access to execute transactions on behalf of Safes that enable them, so some analogy should exist for 4337 user operations where custom
validateUserOp
logic could trigger a transaction execution from an account.A potential implementation would have modules expose:
The proposed implementation would require these modules to be simultaneously installed as a plugin, a fallback handler and a signature validator, which isn't super clean.
The text was updated successfully, but these errors were encountered: