Follow up with more questions for Spencer in Hats Protocol + Optimism Fractal chat

Context

Review questions and answers in Respond to Spencer about Hats Protocol and Optimism Fractal Updates

Amazing, thank you for sharing. I love the vision and reading the blog post helped me better understand the potential of Hats Protocol. The interoperable programmable graph sounds really cool and it’s exciting to think about how network effects accrue from each integration with Hats…

After reading the article I shared it with AI to draft some documents about benefits of integrating Hats Protocol in Optimism Fractal, potential roles for Optimism Fractal, and an overview of synergies between the Respect Game and Hats Protocol. The documents are early works in progress but might be helpful for inspiration and anyone is welcome to improve upon them

Thanks so much for all the answers, that’s very helpful to know!

Here are some follow up questions:

1. What happens if a community wants to change or update an agreement? For example, suppose a community wants to start with a very simple agreement that’s only a couple sentences long then add to it and release a new version(s) that participants would need to sign again in the future.
1. Would this require deploying a new instance of the Hats Agreement Module again, giving out new Hats, and updating permissions to require the new Hats whenever the community wants to update the agreement?
2. If so, how much time and resources would it take to do so?
3. If not, is there some easier way to update an agreement that doesn’t require deploying a new instance of the module?
4. I watched the video clip of the Hat-claim mini app with the All In For Sport’s claim page again and see that this Hat is mutable. Does this mean that the agreement is mutable without needing to change the Hat as well?

2. How much time and resources would it take to set up the agreement module? What would be the next steps?

3. How much time and resources would it take to set up a Respect Eligibility Module? What would be the next steps?
1. Question for @jacob- Does the Roles and Reputations project use a module for Reputation tokens? Could this project integrate with a Respect Eligibility Module?

4. Would there interdependencies between the agreement module and the respect eligibility module? Or would these be these entirely separate modules that can be deployed independently of each other?

5. Is the Hats Protocol entirely independent from the ProtoDAO and Haberdasher Labs?
1. I see this section of the new blog post is quite clear about Hats Protocol’s dedication to being a credibly neutral core infrastructure with immutable smart contracts that developers can depend upon so I think I know the answers to this section… but just want to make sure there aren’t some dependencies that I’m missing.
2. Is the Hats Protocol code all entirely open source with an AGPL-3.0 license and in this Github repository? For anyone who’s interested, I just asked ChatGPT about this license and and the conversation can be seen here. As a high level overview, the AGPL-3.0 license is a type of open source license that requires anyone who uses the software and modifies it to make sure the original and modified code is available to others.
‣
3. How dependent is the Hats Protocol code on the ProtoDAO and Haberdasher Labs? Do either of these organizations have custody or ability to change the code that we would deploy in our app and community?
4. If we decide to use Hats Protocol for critical infrastructure like an agreement or automated council that changes based upon Respect, then would this create risks or vulnerabilities for us if there are changes from the ProtoDAO or Haberdasher Labs?
5. Are there any other dependencies of Hats Protocol’s that someone building a business with the protocol should be aware of?

6. Is there anything that builders using Hats Protocol should be aware of with regards to upcoming changes to the OP Stack or Ethereum protocol (such as EIP 3074)? For example, do you expect that apps using Hats Protocol will have any interruptions in service or experience large upgrades in the near future?

1. How to Create/Admin Community in Fractal App with Hats

I’m exploring a design for an app where participants register to join a fractal community by signing a brief agreement, then automatically receive a Hat that signifies that they are a member of the community. I’d like to design it so that participants are only eligible to play the Respect Game in this community if they have the member Hat for the community.

I’m wondering how this would technically work and at what point the Hat would permit access to the game. In this design, could the lack of a Hat prevent participants from interacting with the contract or joining the game lobby? Or would it technically work better to make it so that people can still join the game but can’t earn Respect unless they have a Hat?

Follow Up Questions

• How much time and resources would it take to set up agreement? what are the next steps?
• Create participant agreement for Optimism Fractal with Hats Protocol
• how much time and resources would it take to set up Respect Eligibility Module? what are the next steps?
• Explore and Test Integrations with Respect Eligibility Module

• Does the agreement module require respect eligibility module or is this separate?

• I think i remember seeing an open-source front-end for the agreement module as well. Is this true? Is there any additional work required to set up front-end for agreement?
Review Watch Hats Protocol Town Halls

• Is the Hats Protocol entirely independent from the ProtoDAO and Haberdasher Labs?
• What are Hats Protocol’s dependencies?
• If we decide to use Hats Protocol for critical infrastructure like an agreement or automated council that changes based upon Respect, then would this create vulnerabilities for us if there are changes from the ProtoDAO or Haberdasher Labs?
• Is the Hats Protocol code all entirely open source?
• How dependent is the Hats Protocol code on the ProtoDAO or Haberdasher Labs? Do either of these organizations have custody or ability to change the code that we would deploy in our app and community?

• Can we make Account Abstraction work with Hats Protocol where only people with Hats can get gasless transactions sponsored by paymaster on this app / smart contract?
• Would this be easy to configure for our clients that may want to create their own smart contracts using our code?

• Can we make account abstraction work to give gas-less transactions to both metamask users and privy users can get free transactions?
• Is this a Hats specific question or more general?

• Is there anything we should be aware of with regards to Hats Protocol, our app development, and upcoming upgrades to Ethereum protocol changes or upgrades (such as EIP 3074?)

• Explore Integrations with Hats Protocol and EAS

• See for more questions

Review the following earlier questions