Decide approach on deploying accounts via initCode
Add functionality from CompatibilityFallbackHandler
Decide on using singletons or non-singletons for plugins. Delete/add factories based on this decision
Add disable module functionality
Add Natspec comments
Add interfaces
Ensure events and errors are sufficient
The enable() function was pretty much copied from kernel, we should double check we’re happy with this code
Nice to have
Handle multiple 4337-compatible plugins. Most likely option is we write a routing fallback handler. We can take inspiration from CoW swaps’ extensible fallback handler
Based off of this, validateUserOp should be supported in each 4337-compatible module.
Other features to consider
Consider _packValidationData to pack validAfter and validUntil
Decide whether to use EIP-712 typed hash for signature verification
Helper function to check if module has been enabled for a specific wallet
ERC-1271 support. Safe supports ERC-1271, but how would things work if you wanted to sign something with a signer on one of your modules? Seen 1271 supported in some validator modules
Should/can we support batched transactions? e.g. executeBatch function as well as an execute function
Do we distinguish between validator modules and executor modules?
MVP
CompatibilityFallbackHandler
enable()
function was pretty much copied from kernel, we should double check we’re happy with this codeNice to have
Other features to consider
_packValidationData
to packvalidAfter
andvalidUntil
Security
Once feature complete, we should ensure the code is well tested. Regarding security, here is a helpful resource with a 4337-specific audit checklist and links to project audits https://github.com/aviggiano/security/blob/main/audit-checklists/ERC-4337.md