Introduction
This task aims to answer questions and provide insights into the integration of Roles and Reputations software into Optimism Fractal and the Respect Game. It covers various topics such as project evolution, token standards, app development, smart contract integrations, front-end integration, and future plans for Roles and Reputations. The goal is to provide a comprehensive overview of the project's goals and understand the best potential collaborations.
Table of Contents
- Introduction
- Note on Formatting and Jacob’s Response
- Project Overview
- Updates on Tracking Entities’ Trust in Relation to Each Other
- Token Standards and Collections
- Dual ERC1155 Collection
- Token Standard for Reputation and Respect
- Current Status and Technical Implementation of Respect Token
- Questions about Roles and Reputation Token Standards
- To Do
- Integrations with Hats Protocol and Respect Eligibility Module
- Implementing Roles and Reputation into the Fractal and Respect Game apps
- Improving Visibility for Respect in the Front-End
- Building a Scoreboard
- Cross-Chain Visibility
- Embedded Wallet and Account Abstraction Integrations
- Integrations with EAS
- ENS Integrations
- Novel Features with Roles and Reputations
- Personal Respect with Lifetime, Redeemable, and Transferrable Tokens
- Tracking Entities’ Trust in Relation to Each Other
- Community Gardens
- Mutual Respect Networks
- Intersubjective Consensus and Sovereign Tokens
- Consensus as a Service
- Auxiliary Tokens
- Fractal Referral Systems
- Higher order fractals
- Educational Institute and Grants Foundations
- Other Considerations
- Branding of Respect vs Reputation
- Reputation & Roles Factory and OP Rewards
- Conclusion
Note on Formatting and Jacob’s Response
This page was shared with Jacob Homanics, the developer of Roles and Reputations, in early May of 2024 and he provided thoughtful responses to many of the questions below.
NOTE: To make this page easier to read and understand, Jacob’s responses are highlighted in green.
Project Overview
- How much has the project evolved since you wrote the Optimism Mission proposal?
- It has developed on track for what the mission proposal had described. We have a functioning set of smart contract code that can be deployed with a frontend to interact with the deployed instances. The core smart contracts have went through a few revisions based on reviews and requirements.
- I see the critical milestones on Optimism governance were set to complete in April. Are you still planning to continue further development for Optimism?
- Yes I plan to continue. As for the milestones and their deadlines, it appears that those are not required to be hard deadlines. Rather, the collective is happy with the milestones as long as they are all completed by the 1 year mark (September 2024).
- If so, is there a roadmap or goals which you are aiming to achieve going forward?
- There is currently no roadmap written down. The current goal and objective is to gain some form of adoption and completion of the current milestones.
- It seems that some milestone for the documentation is not yet complete, but they welcome feedback, suggestions, and PRs to help make this documentation robust, clear, and concise to understanding using the Reputation & Roles project and MonoRepo. More details here.
- Correct - documentation exists, however the milestone cannot be considered complete as the documentation is not complete. Thus, this milestone is still in progress.
- Is the goal of this project still to become the open source bedrock upon which all sufficiently decentralized entities tackle the challenges of defining and assigning reputation & roles through a permissionless and decentralized system?
- Yes
- How could this work if it’s maximally successful in 1, 5, or 20 years? How would it look?
- I imagine something very similar to how the Hats Protocol operates. Maybe even more hands off. The Reputation smart contracts are simple and make very little assumptions. However its up to the implementer and ecosystem to utilize Reputation & Roles in whichever way they see fit (a la Hats Modules).
- You can imagine the current scope of R&R as laying the groundwork for the world to run with. There will be modifications and variations, however the core idea stays the same. Imagine R&R becoming an EIP, similar to the idea of how ERC20s, ERC1155s, and ERC721s exist in the ecosystem. They are, at their core, a specific idea, however there are many different implementations of them.
- What are your main goals with the project and in general?
- The main goal is impact, to bring true value in the world that pushes it forward in a positive way.
Updates on Tracking Entities’ Trust in Relation to Each Other
- The original proposal for Roles and Reputations puts a strong emphasis on enabling the tracking of an entity’s trust in relation to another in a completely onchain and clear way. Is this still the main focus?
- Absolutely, and it continues to follow suit in that manner. You can track an entity’s trust in relation with another 100% onchain. There are a few “caveats”, depending on how much of a stickler you are. For instance, rewarding reputation at an in-person event may require an offchain solution (possibly having users scan a QR code which hits a backend server, records their email and wallet address, then someone manually creates the onchain transaction through the offchain records). Additionally, the Roles side of things may have some offchain components as well. For instance, to gate private data, then you simply need an offchain solution. Maybe a Google Doc is gated by owning a specific Hat. Well Google Docs is not connected to the blockchain, thus maybe a backend service is required or manual intervention. Ideally, all of these offchain issues could be resolved and moved offchain as onchain technology continues to mature and evolve, allowing for more possibilities, alongside mass adoption of the technologies to allow more native support.
- How exactly does Roles and Reputations accomplish this? Can an entity be both a person or group of people?
- A single entity can only be one of the following: a person, a group of people, an organization, a business, a DAO, anything really. If you see this not to be the case, then I would love to hear your reasoning.
- For instance, these are truths that may exists: Dan Singjoy is an entity, ATX DAO is an entity, Microsoft is an entity, Austin Recreational Soccer League is an entity. Additionally, in R&R these truths may exist: Dan Sinjoy Reputation Tokens, ATX DAO Reputation Tokens, Microsoft Reputation Tokens, ARSL Reputation Tokens. And each entity can have and interact with any other entity’s Reputation Tokens. How each entity and its tokens are minted, distributed, burned, transferred, etc, is defined solely by that specific entity.
- Could the Roles and Reputation project enable large, complex webs of trust between many entities?
- For example, if there are hundreds of fractal communities with thousands of people giving their own Personal Respect to each other and each entity has varying levels of Respect given to others… then could the Roles and Reputations system track this graph of their trust/respect for each other in a clear way?
- I believe that this is possible. Each community and each person can have their own respective tokens.
- So for instance,
- Bob Token
- Alice Token
- ATX DAO Token
- Fractal Community 1
- Each of those tokens exist respectively for each entity. So while, Bob and ATX DAO are not exchanging tokens directly, Bob may be rewarding tokens to ATX DAO and ATX DAO may be rewarding tokens to Bob, in a completely unrelated manner.
- As for tracking this through a graph or other visual element, yes that should totally be possible. Someone just needs to implement the tools and frontend applications to do so.
- More details about these kinds of ideas can be found here, but before getting too much into bigger vision thinking I’ll first ask some more pragmatic technical questions that are more relevant for potential integrations in the short-term
Token Standards and Collections
Dual ERC1155 Collection
- Is there still a Dual-Token ERC1155 Collection with Redeemable and Lifetime tokens?
- Yes and No.
- ATX DAO will be following the Dual-Token collection as defined.
- The smart contracts however, allow for a third type of token: Transferable. This one is subject to open transfer protocols, I.E. able to be listed on a DEX, CEX, or to be transferred through regular means (i.e. through a wallet). It is up to organization to decide which and what types of tokens best fit their organization’s structure. For instance, ATX DAO WILL NOT be implementing a Transferable token, as we do not agree that our Reputation tokens should be tradeable.
- Does the same ERC1155 Collection include both Redeemable and Lifetime Tokens?
- Yes
- I see that there is now a transferrable token in the front-end. Is this part of the collection and is it now a Tri-Token ERC Collection?
- Yes. See explanation above.
Token Standard for Reputation and Respect
Current Status and Technical Implementation of Respect Token
- We’re currently considering if we should migrate the Optimism Fractal Respect token to an ERC 1155 token standard.
- The current implementation of Respect uses a unique combination of ERC721 and ERC20 token standards which allows you to see Respect in both ERC20 (fungible) and ERC 721 (nonfungible) token interfaces.
- Here is the Github repository with the current Optimism Fractal smart contracts.
- Tadas (a developer on the Optimystics team who created the smart contracts) said that the best and most recent explanation of the contract’s design can be found on this page, where he wrote about the rationale and technical issues with this token implementation. Tadas wrote this page in February to explain the unique design of the contract and improve how Respect displays in block explorers. At the end of the page he also considered the possibility of migrating the Respect token to an ERC-1155 standard.
- For more details and rationale, you can see Tadas explain how the smart contract implements interfaces of both ERC20 and NFT standard for the Respect token in this video. If you’re interested in learning about the philosophy originally behind this design, you could also see this blog post and video clip for more details.
- I’m wondering if implementing Roles and Respect could make it easier for us to migrate to ERC-1155 by adopting an open-source and well supported standard that includes many helpful integrations out of the box.
- After Tadas wrote the explanations linked below, I did a lot of research wrote the following page: Consider migrating to ERC-1155. This page includes reasons why I think that we should migrate Respect to a ERC1155 token standard and questions about doing so
Questions about Roles and Reputation Token Standards
- Would Roles and Reputations work with the current implementation as well or only if we switched to ERC1155?
- I do not believe so. R&R relies heavily on using the ERC1155 standard from smart contract implementation to Hats integration. These are not interchangeable with ERC721 components, but possibly ERC20.
- We’re currently using a non-standard implementation of token standards for Respect where Respect can be viewed as both ERC721 and ERC
- We’re thinking about migrating Respect to an ERC1155, as you can see in this task: Consider migrating to ERC-1155
- Can the ERC1155 implementation accomplish all the same benefits as the current implementation with ERC721 and ERC20?
- Yes to all of those, except for maintaining the fungibility with the non-fungibility. As the R&R smart contracts stand, they are precisely an ERC1155. This means that they are fungible, there is no tokenId or “serial number” assigned to each newly minted token. The way that I view ERC1155s, are that they are like ERC20s, but with metadata. With the Redeemable and Lifetime tokens, I did not see a need to have non-fungibility features, as they mostly were not really a currency.
- As you can see from above, I took inspiration from World of Warcraft’s Reputation system. Looking at Rustbolt Restistance, we can see that the player has 1650 reputation. We can ignore the “Friendly”, “Honored”, “Exalted”, and “3000” pieces of the picture as they do not immediately pertain to R&R (Someone may choose to build those systems on top of R&R. However, R&R simply tracks the total reputation of a user, I.E. the 1650 number). Also, note that there is no non-fungibility. Reputation is simply a tracked total number with respect to an entity.
- I can imagine if you wished to uphold both fungibility and non-fungibility, then possibly two different collections (smart contracts) need to exist. The traditional ERC1155 (sub for ERC20 if need be), but then an accompanied ERC721. They are not tightly defined, other than by an outside source. The outside source, RespectMinter, may have minting authority for both collections. RespectMinter may also have a Mint() function, which when called, mints tokens from the ERC1155 (or ERC20) collection AND the ERC721 collection. Maybe. Of course it costs more gas, but I think when we think about these concepts, we can’t be constrained by gas, or we truly can’t achieve the visions we’re looking at.
- Benefits of the current implementation include:
- Ability to set roles and permissions on a time basis (ie set councilors as top 6 respect earners over the past 12 weeks)
- This can also be flexibly used in other many ways too, such as sending awards or rewards to people who participated in OF Season 2 based upon the Respect earned in that season
- Ability to see total amount of Respect in addition to visible NFT for each token
- Would it make sense to use ERC 404 instead of ERC1155 or ERC721 and ERC20?
- I watched Jacob’s video about Trash NFT’s and learned about ERC 404. I organized details about ERC 404 in
Consider implementing ERC 404 Token Standard for Respect.
- My intuition is that it’s probably better to use a more proven and supported standard like ERC1155 than ERC404, but the fact that ERC 404 uses a similar design to Tadas’ implementation is enticing….
- This is my intuition as well. ERC404 tries to be both. On a certain level, it accomplishes that goal. However, once you look under the hood it has some wonky behavior that results in similar behavior from what is being seen with Respect.
- Does ERC404 token standard work with Roles and Reputations instead of ERC1155?
- No. Not without extra development work in place. R&R specifically and strictly only supports ERC1155 at the moment.
To Do
Integrations with Hats Protocol and Respect Eligibility Module
- How might the Hats Protocol integration with Roles and Reputation affect Optimism Fractal?
- We’re exploring ideas to create a flexible and granular Respect Eligibility Module that enables roles to be set based upon Respect
- You can see some discussions and code created by Spencer Graham for this here or details about modules here
- Essentially we'd be able to say that to be eligible for a given hat, a wearer would need to have earned X respect within the last Y periods, where X and Y are configurable/customizable on a per-hat basis
- In theory could also do more complex stuff like "must have at least Z total respect, with X of that respect earned over the last Y periods”
- Does the Reputation token in the R&R project have it’s own eligibility module?
- Could the Roles and Reputation project integrate with a Respect Eligibility Module to be able to have this kind of flexibility and granularity based upon time periods of Optimism Fractal?
- Would there be advantages of integrating with Hats Protocol through Roles and Reputations or does it make more sense to integrate Respect directly with Hats Protocol?
- Is there any big difference in terms of time/resources required or features enabled?
- Is there much custom logic or programming built into the Hats Protocol implementation in Roles and Reputations?
- I just added these questions to a task called
Consider creating Respect Eligibility Module with Hats Protocol
Implementing Roles and Reputation into the Fractal and Respect Game apps
- Over the past few months, we’ve been scoping and designing an application that makes it easy for communities to play the Respect Game and coordinate their governance with fractal decision-making processes. As we’ve been exploring features and designs for these apps, I’ve realized that that there is likely a need for two different apps: a Respect Game app and a Fractal app. Both of these apps are intended to make it easy for anyone to play the Respect Game, but they differentiate in their focus.
- The Fractal App is envisioned as a comprehensive app for communities and organizations to coordinate their operation with the Respect Game at weekly events (like Optimism Fractal). This includes governance features like voting with respect, forming councils, and social media networks for the community to interact between events. The Fractal app features one community token (such as OPF) that can be used to coordinate the activities and decision of the community. It is largely inspired by the original design of fractal communities at fractally.com.
- We’ve started coordinating the development of both of these apps in the following projects. Much of the work on these projects is currently in an internal Optimystics database and will be shared in the public Optimism Fractal projects as soon as possible. You can find details about each of these developments the project to Build Respect Game App and Build Optimism Fractal App.
- I’m wondering if/how Roles and Reputations can be integrated into both of these apps. These apps will share much of the same technical infrastructure and it seems to me that Roles and Reputations can provide much of what we need in these apps. The following sections provide an overview of some of the questions and features under consideration that may be related to Roles and Reputations:
- Can Roles and Reputations help enable the following key features we’re seeking in the Fractal and Respect Game apps?
Improving Visibility for Respect in the Front-End
The user interface enhancements, such as card views for displaying Respect, can make the Respect Game more engaging and accessible. This can also fix current issues experienced with the Optimism Fractal software. By visualizing Respect akin to a card game, communities can tap into the familiar and popular mechanics found in games like Pokémon or Magic: The Gathering, potentially increasing participation and interaction.
- This can be a solution to
Improve Visibility for Optimism Fractal Respect
Building a Scoreboard
- Can the Roles and Reputations software enable the us to build a scoreboard for Respect?
- This could also be useful for
Build Scoreboard for Respect and other components in our projects to
Build Optimism Fractal App and
Build Respect Game app
- Would it make sense and be possible to integrate the dual/tri ERC1155 Collection Front-end into the distribution of Respect tokens after a Respect Game?
- Some people might like to mint transferrable tokens and give them to their group after playing the game, whereas some people might prefer to just use lifetime and/or redeemable tokens
- It may be ideal to provide the option may be provided to the game host or the players to choose what kind of tokens they want to distribute after the game. This could be a very interesting new dynamic for the game, though we should also be careful to maintain simplicity so as to avoid overwhelming players
- Would there be a way for people to restrict whether accounts can restrict incoming token transfers i they don’t want them?
- I asked chatgpt about this somewhere and can search for it, though it’s not a big priority now. We can deal with issues of spam when they arise in the future
- Does it make sense for Vlad to also integrate this kind of ERC1155 standard for the automatic respect distribution flow for community admins/hosts as well?
Cross-Chain Visibility
ladders.vision is an open sourced and decentralized approach to viewing ALL data for any NFT on any blockchain.
- Will this be integrated into the Roles and Reputation repository so that Respect would be viewable on any blockchain?
- Does it work with all token standards?
Embedded Wallet and Account Abstraction Integrations
We are designing the user experience of this app for a community of older people who are not very technically savvy and have no experience with Web3, so we’re planning to use Privy and account abstraction with a paymaster account. This will make it so that the participants can simply sign in with their email and post consensus results onchain without needing to pay gas or having any knowledge about know how to use a blockchain account.
It’s very important that the UX is really smooth for this community because they are paying customers and we need to provide them with the most intuitive and enjoyable experience possible. I’m wondering if Roles and Reputations can help facilitate integrations alongside embedded wallet solutions like Privy and account abstraction services in a consumer app like this that can easily be used by grandparents.
- Will Roles and Reputations work with smart wallets in this way?
Integrations with EAS
- Could we also integrate Roles and Reputations with the Ethereum Attestation Service and Attestation Station as well so that every time the reputation/respect tokens are minted there is also an attestation with a Respect Game schema?
- We have a project to do this here where you can find details:
ENS Integrations
- We want to make the front-end for our apps compatible with ENS and I’m wondering if the Roles and Reputation front-end may help with this.
- We have a project to do this here where you can find details:
- Can Roles and Reputations facilitate the integration of ENS?
- Is Roles and Reputations already integrated with ENS?
Novel Features with Roles and Reputations
The following sections feature innovative features that we’ve been exploring for Optimism Fractal and it seems that Roles and Reputations may help enable. The first idea is about enabling features for Personal Respect in the Respect Game app and the following ideas are related to the goal of the Roles and Reputations to track trust upon for Respect between entities’.
Personal Respect with Lifetime, Redeemable, and Transferrable Tokens
We’re considering implementing a feature into our upcoming Respect Game app that will enable anyone to give out their own Personal Respect to fellow players at the end of the game.
This can be a very powerful way to promote the adoption of the Respect Game and potential integrations like Roles and Reputations. It can also be combined with a wide variety of different types of Respect Games via fun prompts. You can see some details about the idea of Personal Respect in this note.
I’m wondering Roles and Reputations might be able to help solve some of our questions for this kind of feature development. Here are some product requirement needs and questions that we need to resolve to implement this kind of feature:
- Send the minted tokens to other players in the same action
- Preset the amounts of Respect to send to other players
- Could we standardize the amount of Respect given out with Respect/Reputation for each game (ie ERC1155 with amounts of 55, 34, 21, etc)?
- Enable each player to personalize the image and/or text field of their personal respect (as explained here).
- Can the Roles and Reputations smart contracts help with these? Or would it make sense for us to develop our solutions with the Roles and Reputations open-source code?
- Can the Roles and Reputations front-end software enable each player to personalize the image and/or text field as they issue Personal Respect tokens after each game?
- Or perhaps this feature can be added to Roles and Reputations with a tool like Scaffold.eth?
Tracking Entities’ Trust in Relation to Each Other
Below are ideas and questions about potential integrations with Roles and Reputations and Hats Protocol to track and give Respect based upon another entities’ Respect. The goal of these ideas seem quite similar to the ideas expressed in the Roles and Reputations proposal about how the project aims to enable tracking an entity’s trust in relation to another in a completely onchain and clear way.
We’ve been developing these ideas for the past couple years and I’m very excited about how Roles and Reputations might play a role in actualizing them. It may be better to focus first on the other ideas that are easier to implement first, though these are also worth exploring on a conceptual level to see how we may best collaborate with the Roles and Reputation project going forward. The following sections provide details about ideas related to the following question: How could Optimism Fractal benefit from the ability to enable tracking an entity’s trust in relation to another in a completely onchain and clear way?
Community Gardens
Community Gardens is an idea where individuals can create "seeds," or redeemable NFTs, as a reward for their contributions to the community. The ability to generate these seeds is directly tied to the amount of respect each member earns from the community, ensuring a merit-based system. The more respect a member accumulates, the more seeds they can create, which can then be redeemed for various utilities or benefits within the ecosystem. You can see details about community gardens in this article and in this video.
I’m wondering if the Roles and Reputations could synergize and enable this kind of functionality. It could also be branded in different ways with similar functionality, though the ideas of community gardens is very interesting and seems to fit best. It’s also possible to identify the redeemable NFTs as something like fruits or plants instead of seeds, but so far seeds seems to be the best way to make this work. In this example, players would earn Respect as the lifetime token and a redeemable token called Seeds.
- Could the Dual-Token ERC1155 Collection with Redeemable and Lifetime tokens be useful for Personal Respect and the ideas of planting community gardens?
- If so, this could potentially be incredibly helpful…
- Perhaps we could deploy the Roles and Respect software into the Respect Game and Fractal app as we migrate to ERC1155, which could also enable the powerful primitive for non-fungibility out of fungibility where people can make collectively redeemable tokens along with their personal respect?
- People could give out their personal respect in each Respect Game (or elsewhere) and allow others to redeem goods and services (perhaps explained in terms of planting a seed)
Mutual Respect Networks
Respect Networks are a novel idea for ecosystems where participants can recognize each other's contributions with Respect to measure appreciation for collaborative efforts in a more expansive way across many communities and organizations. Mutual Respect Networks can include both Personal Respect, Community Respect, and any other kind of auxiliary Respect tokens that may be helpful to recognize appreciation for others.
I think these kinds of Respect Networks can work in a somewhat similar way to Community Gardens, but the Respect Network would be based upon the lifetime Respect token and not on a redeemable token. It also doesn’t include the same incentives and rationale, but it could be coupled with a Respect Network of Community Gardens where communities recognize both the lifetime and redeemable tokens of other communities. You can see details about this idea here. You can see ideas about this idea here.
Roles and Reputations may help enable this kind of decentralized graph of Respect and Trust by providing infrastructure for entities to trust each other’s opinions about who to Respect.
Intersubjective Consensus and Sovereign Tokens
I wonder if Roles and Reputations can synergize with the idea of sovereign tokens and intersubjective consensus to allow everyone to set their own subjective value of redeeming each other’s Respect. This may be similar to the community garden idea above.
Consensus as a Service
We’ve thought a lot about how fractal communities can interact with each other and how Optimism Fractal can interact with other communities like the Optimism Collective. You can see some notes about this in this note. The goal of Roles and Reputations is closely aligned with fostering trust between entities based upon Reputation which has some similaries with this idea of consensus as a service, so I’m wondering if Roles and Reputations could be useful for this and generally building a web of trust amongst communities.
Auxiliary Tokens
We’re exploring ideas of issuing new forms of Respect to recognize the work of all kinds of leaders in the Optimism Collective, such as an OPC token that enables various stakeholders in the Optimism Collective to vote using methods and tooling like Respect Trees or Cignals that is being pioneered at Optimism Fractal. The OPC token could also be used at events like the Optimism Town Hall to help facilitate structured, Respectful discussions with Cagendas. You can see more ideas for auxiliary tokens in this note.
I’m wondering if there may be some synergies between this concept and the goal of Roles and Reputations to facilitate trust between entities, as well if the token standard design and front-end implementation of such auxiliary tokens should use the Roles and Reputations software implementation.
Fractal Referral Systems
We’re exploring ideas about implementing a referral system whereby people who invite others to play the Respect Game earn Respect to incentivize and encourage active engagement. This referral system could also be used and integrated with other communities that play the Respect Gamel; and Roles and Reputations may provide a helpful solution to facilitate the ability to refer and earn awards for respected community members. You can learn more about this in this page.
Higher order fractals
Higher order fractals are cooperative structures composed of groups or communities rather than individuals, allowing for scalable and robust consensus processes. This model enhances collaboration by integrating contributions from various groups into unified decision-making, promoting scalability in governance. You can see more about this idea on this related page: Synthesize Higher Order Fractals ideas
I’m not sure if Roles and Reputations is a fitting solution for Higher Order Fractals or if this is a high priority at this point, but am curious if it could be integrated with higher order fractals in the long-term as Roles and Reputations seems to have some similar goals regarding sharing trust between entities.
Educational Institute and Grants Foundations
I’m designing an educational institute and grants foundation called FractalJoy to support the growth of Optimism Fractal and other communities playing the Respect Game. FractalJoy will be devoted towards spreading joy and optimism with various courses and financial incentive programs that closely complement Optimism Fractal. The project is currently mostly private but will be made public soon. There is a lot of potential for FractalJoy to implement the Roles and Reputations with a JOY token that can be explored in the future.
Other Considerations
Branding of Respect vs Reputation
- Could we fork the Roles and Reputation project and call it Roles and Respect instead?
- Would this require much work to change the word Reputation to Respect in the code, front-end, and documentation?
- It’s not a huge priority as reputation is cool and generally aligned with Respect, but Respect is more so a part of our culture and brand experience with the Respect Game.
- Respect is also shorter and has some important meanings that Reputation does not, so if it’s possible to keep the naming consistent with Respect while gaining benefits from the R&R project then that would be nice
Reputation & Roles Factory and OP Rewards
- Have you deployed or are you still planning to deploy the Reputation & Roles Factory smart contract? Are there OP rewards for deploying instances of this project?\
- How much funding might be available for deploying Roles and Reputations?
- When might this be available?
Conclusion
I’m very interested in potential collaborations and integrations with Roles and Reputations. There’s a huge amount of information here and I got much more inspired than expected, so it’s worth considering the highest priorities going forward and determine what integrations might make the most sense. Looking forward to it!