Enabling Modules to be redeployed in case of incorrect configuration by HatsModulesFactory

Background: the HatsModuleFactory

While Hats Protocol itself does not place any restrictions on who can deploy a module or how they can be deployed, the most common way is to use the HatsModulesFactory.

HatsModuleFactory and the HatsModule template provides some nice features for developers looking to build and deploy Hats modules:

  1. Module instances can be deployed cheaply by users as minimal proxy clones
  2. Such clones can incorporate immutable args for lower gas costs at runtime…
  3. …as well as initial mutable settings
  4. Instances can be immutably configured to align with a given target hat (or branch)
  5. Compatibility with the Hats Modules Registry, which enables users to configure, deploy, and manage modules from apps that support the registry (eg using the Modules SDK).

Potential Problem: fixing bad module configuration

When configuring module instances, users set up both the immutable args (2) as well as initial settings which can be modified later (3).

If they make a mistake on (2), they can easily redeploy with the correct settings. But they may not be so easily able to fix a mistake on (3) — or, indeed, if a mistake is made later to the mutable settings.

This is because immutable args and the target hat (4) are factors in determining the deployment address of the instance. Changing them will change the deployment address, allowing for redeployment. But if they need to stay the same, then redeployment would not be possible.

As a result, mistakes on mutable settings can only be resolved if the code in the module allows it. This is not ideal because it places additional burden on module developers to implement such logic (which is not always simple) as well as on module registry curators when reviewing new registry submissions.

Recommended Solution: add a salt nonce to the HatsModuleFactory

There is a clean solution to this problem: add an additional factor — a “salt nonce” — to the determinants of module instance deployment addresses to allow for the same instance to be deployed to a new address.

Here’s what a change to the HatsModuleFactory might look like:


This solution has a number of benefits:

  • Ensures Hats users can always* fix an erroneous configuration, regardless of whether the module developer explicitly implements the necessary in-module logic
  • Avoids placing additional review burden on module registry curators
  • Requires no changes to already-developed modules, since the change to the salt is applied at the factory level not the module level
  • Fully backwards-compatible with existing module instances, for which the salt nonce value is effectively 0

*If the target hat is mutable. If a hat is immutable, its modules cannot be changed.

Work to be done

If we determine this is a good approach, here is what remains to be done

  • The HatsModuleFactory contract code will need to be updated and tested
  • It will need to be deployed to all existing Hats-supported networks
  • The Modules SDK will need to be updated to support the new factory
  • Existing Hats apps and clients will need to be updated to support the updated Modules SDK and factory
  • They may also want to build in redeployment UX flows

Your Input Requested

I am interested in what the Hats community thinks!

  • How urgent is this problem?
  • Is the recommended solution advisable?
  • Are there any drawbacks not considered here?
  • Are there any additional steps or work to be done?
1 Like

I have opened a draft PR with the proposed changes.

This all makes good sense to me. My biggest question is what would be the impact on existing Hats apps and clients? In other words, would existing apps and clients break until they’re updated to support the updated Modules SDK and factory? If yes, I think we’ll just need a good communication strategy with plenty of notice to app/client developers.

1 Like

Great question. I don’t believe so, but it will be good to confirm — cc @gershido.eth and @scottrepreneur.eth. And we should definitely communicate to app/client devs either way.

1 Like

That’s right, it will be backwards compatible for users of the modules SDK. My current thinking is that the nonce will be added as an optional input for the module creation functions. If not provided, we’ll randomly generate one.

1 Like

After further discussion, here is a fuller migration plan. This as a non-urgent change, and as a result the following steps are sequential but do not have firm dates.

  1. Notify the Hats Protocol community of the upcoming migration and its (minimal) impact, including the the Hats Community and Hats Protocol Dev Chat telegram groups.
  2. Review, revise (if needed), and merge the proposed contract code change to the HatsModuleFactory.
  3. Update the Hats Protocol Subgraph to track deployments of MultiClaimsHatter via the new factory*
  4. Update the Ancillary Subgraph to track module deployments via the new factory
  5. Deploy (3)* and (4) to Sepolia testnet
  6. Update the Modules Registry /infra directory with the new factory address
  7. Update the Modules SDK to add the new saltNonce logic
  8. Merge (6) and (7) into production branches simultaneously
  9. Update app.hatsprotocol.xyz with the updated Modules SDK
  10. Deploy (3)* and (4) to all other Hats-supported chains

*may not be necessary pending further investigation