Safe Recovery Initial Setup

[remedcu]

This PR adds an empty NPM package for the Recovery Module, including:

• CI configuration
• Default Hardhat template
• hardhat-deploy configuration
• Linting

Inspired from #297, this PR fixes #350

[mmv08]

Did we decide that we need a new module instead of choosing plenty of existing options? I cannot see any decision made in #348

[remedcu]

Did we decide that we need a new module instead of choosing plenty of existing options? I cannot see any decision made in #348

Even though not as the first milestone, we want to support the 4337 flow sooner or later, which I believe the existing options do not support.

CC @nlordell

[mmv08]

Did we decide that we need a new module instead of choosing plenty of existing options? I cannot see any decision made in #348

Even though not as the first milestone, we want to support the 4337 flow sooner or later, which I believe the existing options do not support.

CC @nlordell

I took a look at candide contracts and they seem to fit our requirements, except for the 4337. Theoretically, we may just inherit our contract from it and add a validateUserOp function - was that option explored?

cc @Sednaoui

[Sednaoui]

Did we decide that we need a new module instead of choosing plenty of existing options? I cannot see any decision made in #348

Even though not as the first milestone, we want to support the 4337 flow sooner or later, which I believe the existing options do not support.
CC @nlordell

I took a look at candide contracts and they seem to fit our requirements, except for the 4337. Theoretically, we may just inherit our contract from it and add a validateUserOp function - was that option explored?

cc @Sednaoui

I am not sure I understood the 4337 requirements needed for the Recovery Module. Can you please further clarify? From our knowledge:

• Candide recovery module works for any safe, including ones with the 4337Module.
• When the owner interacts with the recovery module, if the owner is a 4337 account, then the account normally validatesUserOp before they can call the recovery module. The recovery module only checks that the call is coming from the account itself.
• When a guardian interacts with the module, they interact with it just as any other contract on chain.

Having validateUserOp can work for Safe{Core} Protocol because they do have signature validators, if the goal for example for guardians to initiate and finalize the recovery using the owner's account (owner pays the gas and is the sender), then the recovery module can act both as a plugin and a signature validator. That is not possible with just 4337 Safe Module, so I don't understand the reasoning to include validateUserOp in the recovery module.

[nlordell]

For some additional context, we are considering adding "signature validator" support to the 4337 module to allow modules to be executed over 4337 (which is currently not possible with Safe and the 4337 module).

[Sednaoui]

For some additional context, we are considering adding "signature validator" support to the 4337 module to allow modules to be executed over 4337 (which is currently not possible with Safe and the 4337 module).

Got it -- yes in that case the support for signature validators are quite beneficial. We can add support for it in the social recovery module if this is planned

[remedcu]

Based on internal discussion, we have decided we will be exploring currently available module options instead of creating a new one from scratch. So, this PR will be considered as "won't implement".