Hat mutability research

[spengrah]

Currently, hats are immutable in the sense that their properties -- ie max supply, details, imageURI, toggle, and eligibility -- cannot by changed once the hat is created.

This has the benefit of limiting the governance / attack surface for hats, but at the cost of flexibility for DAOs. For example, a DAO may want to add mechanistic eligibility logic to an existing hat after experimenting manually with several candidate approaches. Currently, this would require creating and minting a brand new hat.

This is a research issue, with the goal of exploring the following questions:

1. What is the design space for hats mutability? On what dimensions could mutability be introduced partially or with constraints?
2. What are the risks and trade-offs of the dimensions from (1)?
3. What is a recommended approach for hats mutability?

[spengrah]

Properties that could be changed after hat creation:

• max supply
• details
• imageURI
• eligibility
• toggle

The main design question is who is authorized to change it. Since the entire branch of admins of a given hat have admin control over the hat, this introduces a lot of questions about whether there should be additional parameters determining which of those admins have updating rights.

For example, in theory we could give hat creators the ability to restrict who can change the hat H's properties to...

• all of H's admins
• only the top hat
• the top n hat levels
• only the hat's immediate admin, ie level H - 1
• only the hat's m immediate admins, ie level H - m

This could get quite messy, so we need to figure out what makes most sense via discovery.

My recommendation is to start with the simplest option and potentially expand from there as we discover use cases.

[spengrah]

Another dimension to play with could be the number of times that a property could be changed. Allowing only 1 change following creation, for example, could give DAOs the flexibility they need while limiting the governance / attack surface.

[spengrah]

If we do want to enable configuration of this stuff, we do theoretically have room to store up to 96 bits of config in the hat struct without needing to add an extra storage slot:

struct Hat {
    // 1st storage slot
    address eligibility; // can revoke Hat based on ruling; 20 bytes (+20)
    uint32 maxSupply; // the max number of identical hats that can exist; 24 bytes (+4)
    bool active; // can be altered by toggle, via setHatStatus(); 25 bytes (+1)
    uint8 lastHatId; // indexes how many different hats an admin is holding; 26 bytes (+1)
    
    // 2nd storage slot
    address toggle; // controls when Hat is active; 20 bytes (+20)
    uint96 config; // --- NEW
    
    // 3rd+ storage slot
    string details;
    // optional
    string imageURI;
}

What could we do with those 96 bits? A few ideas:

1. cap and track the number of times each of a hat's properties are changed, eg only allow changing the eligibility module once (which we can track in a single bit)
2. store how many admins of a hat could make such a change
3. any remaining unused bits could be used by hat creators as arbitrary metadata pointers

[spengrah]

A few other ideas:

• include a mutable flag as part of a hat's properties that allows DAOs to decide whether a given hat is mutable or immutable
• create several mutability modes, eg
  1. fully immutable
  2. each property can be changed only once
  3. each property can be changed only twice
  4. fully mutable

[jonasms]

Mutating a hat's maxSupply property makes sense to me. It's unclear to me in what scenario an org would want to limit which admins can modify that value. In other words, what would lead an org to want to give a hat admin control over a subtree but not control over growing that subtree (i.e. increasing maxSupply)?

If there isn't a clear use case for enabling this custom control, I recommend against the feature for the sake of maintaining complexity of the system.

That being said, having a mutable flag makes sense to me. Some use cases may call for mutability for the sake of flexibility, while others may not -- I'm thinking of protocols that are designed to be immutable. If such a protocol wants to leverage hats (either for contracts or end users) but hats were always mutable, then the system as a whole would lose its status of being fully immutable.

That being said, is mutability of hats relevant to any use case(s) that currently have traction? Seems simple to include this feature in a V1+N when there's a clear demand for it.

[spengrah]

simple mutability addressed in #66