[READY TO VOTE] Advancing Optimism Anonymous Community and Governance Tooling

Mission Request made by LauNaMu and originally shared here.

Delegate Mission Request Template

Delegate Mission Request Summary:

This Mission focuses on testing and generating accessible implementations of ZK primitives to enhance privacy within the Optimism Ecosystem. The goal is to create implementations and test behaviours in low-risk, publicly verifiable governance and community interactions. The successful application in these initial scenarios will set the stage for integrating these privacy-preserving solutions into more critical, high-stakes implementations within the ecosystem.

S5 Intent: Intent 3 - Improve the Consumer Experience

Proposing Delegate: Brichis

Proposal Tier: Ember Tier

Baseline grant amount: 8.000 OP per applicant

Should this Foundation Mission be fulfilled by one or multiple applicants: up to 4

Submit by: To be set by Grants Council

Selection by: To be set by Grants Council

Start date: - March 2024

Completion date: 3 months from the start date of the project

Specification

How will this Delegate Mission Request help accomplish the above Intent?

ZK is eating the world, and Optimism would benefit from generating more End User applications that can introduce OP Communities and Governance Participants to this technology. By developing tools that promote fair, candid, and balanced discussions, this mission will contribute to a more effective and equitable governance process.

Therefore it’s necessary to address these issues through the use of new privacy preserving governance applications that can lead to:

  • Anonymous Feedback gated to specific Attestation holders (ex. Badgeholders) only
  • Anonymous Whistleblowing gated to specific Attestation holders only
  • Anonymous Voting gated to specific Attestation holders only
  • Gated groups based on Optimism ecosystem IRL attestations & interactions

By implementing these tools and systems, the mission will contribute to building a higher level of trust, credibility and quality process within the Optimism governance framework and set the building blocks to enhance and provide privacy preserving governance processes.

What is required to execute this Delegate Mission Request?

This Delegate Mission Request will leverage:

  • EAS as an attestation layer for identity & credentials
  • Semaphore groups as industry-standard for anonymous ZK groups
  • Bandada as an easy-to-use UI & credential aggregator to lower the entry barrier for creating flexible anonymous groups, and finally
  • Privacy Preserving Governance Applications: that will be built in this Mission Request

Applicant teams must proof experience in web3 development using: addresses, messages, attestations, building with APIs.

Conceptual ZK knowledge to generate and verify a proof, knowledge on how to use SDKs and packages (Bandada o Semaphore) no need to be familiar with circuit creation.

Specific use case/community in mind, detailed scope on who would be using this application: hypothesis to be tested and expected outcomes of their use.

Technical Development:

  • Design and Development of Applications: Building user-friendly web applications for governance and community engagement on the Optimism network.
  • Initial “Happy Path”: 1) user connects wallet 2) if they are a badge holder, allow them to vote, give feedback, whistleblow
  • These applications should be flexible enough so that they support other attestation-enabled groups like: RetroPGF recipient, previous badgeholder, delegates, etc.
  • Integration with Bandada and EAS: Ensuring seamless integration to leverage the privacy and security features of Bandada (Semaphore) groups, along with the attestation issuing capabilities of EAS.

Community Engagement and Education:

  • Outreach Programs: To educate the community about new tools and their benefits.
  • Feedback Mechanisms: Implementing systems to gather user feedback for continuous improvement of the applications.

Testing and Deployment:

  • Beta Testing: Conducting thorough testing phases to ensure reliability and user-friendliness.
  • Deployment on Optimism Network: Ensuring the applications are fully compatible and optimised for Optimism Mainnet and/or testnet.

Documentation and Support:

  • Comprehensive Documentation: Providing clear documentation for both users and developers so other communities or projects that can benefit from these builds can fork them and reuse them.
  • Ongoing Support and Maintenance: Establishing a framework for regular updates and user support.

Governance and Reporting:

  • Transparent Reporting: Regular updates to the community and stakeholders about the progress and impact of the applications.
  • Collaboration with Governance Bodies: Working closely with Optimism’s governance system for alignment and support.
  • Sharing learnings on the development process, user experiences, and adoption for the Optimism Ecosystem to learn and build upon.

Note: Semaphore & Bandada teams from Privacy Scaling Explorations team (EF) have committed to provide as much technical guidance and support needed for builder teams to successfully complete this mission and leverage anonymous groups infrastructure and integrate them into new governance or community applications. Semaphore is an OG Public good in the ZK space.

How should the Token House measure progress towards this Mission?

  1. Development Milestones:
  • Initial Design and Concept Approval: Date by which the initial design and concept for the applications are approved.
  • Prototype Development Completion: Target date for the completion of the first functional prototype of the applications. This should have initial UI and basic mocked APIs.
  1. Integration and Testing Phases:
  • Bandada and EAS Integration Completion: Deadline for successfully integrating the applications with Bandada(Semaphore) and EAS.
  • Alpha Release: Scheduled date for the alpha release, focusing on core functionalities.
  • Beta Testing Launch: Date for initiating beta testing, involving a select group of users to evaluate the applications’ performance.
  • Beta Testing Feedback Review: Deadline to review and analyze feedback from beta testing to make necessary improvements.

3. Deployment and Rollout:

  • Optimism Mainnet/Testnet Deployment: Specific date for deploying the applications on the Optimism Mainnet and/or Testnet.
  • Public Launch: Target date for the public release of the applications, post all necessary testing and refinements.
  1. Community Engagement and Education:
  • Community Outreach Program Launch: Date for starting community outreach and educational programs about the new tools.
  • Feedback Collection Initiation: Deadline for implementing feedback mechanisms to gather continuous user input.

During this mission it is expected for teams to provide:

  • Monthly Update Submissions: Regular bi-weekly updates to the Token House through the governance forum, detailing progress, challenges, and next steps.
  • A final report on learnings from the challenges faced in the adoption of this technology within the Optimism Ecosystem and suggestion for other communities looking to re-use this build.

How should badgeholders measure impact upon completion of this Mission?

  • Number of unique users using the new applications.
  • Number of unique interactions in these apps
  • Amount of new anon-relevant groups created via the application
  • Quality and quantity of feedback received from elected govNERDs, badgeholders and OP communities
  • Quantity of incidents reported via the whistleblowing tool: Track the number and nature of incidents reported, assessing the effectiveness of the whistleblowing tool.
  • Feedback from Badgeholders on their perceived ability to have more candid discussions (regardless of their tenure in the ecosystem) based on new interaction methods available.

Have you engaged a Grant-as-a-service provider for this Mission Request?
No.

Has anyone other than the Proposing Delegate contributed to this Mission Request? @LauNaMu and Andy from PSE

14 Likes

I think more private governance tooling in the OP stack would be a huge WIN and I like that multiple teams can apply to fulfill the mission. However, I suggest keeping a technology-agnostic approach to encryption to allow a wider set of use cases, rather than only focusing on ZK. An open approach would allow more teams to apply, then the grants council can choose the most interesting ones.

Sharing this tweet from Moloch DAO as a reference:

4 Likes

Hi @Cotabe!

Thank you for your feedback! It would be great to learn which private governance tools or solutions you have in mind that may not be easily developed through ZK to understand the problem space better.

One of the goals with this proposal is to bring ZK developers to the Optimism Ecosystem as detailed in Intent 3 hence why this Mission request is looking for a build leveraging this kind of technology.

Experimenting with ZK can enable this technology to be used by the broader network of communities growing within Optimism, bring more ZK builders, and improve the coordination mechanisms of communities in Optimism.

I’m glad you mention the tweet from MolochDAO as it is actually one of the things that informed this proposal! :slight_smile:

As shown in the report, Semaphore is the best ZK graded tool for builder accessibility. Semaphore is the primitive being proposed in this Mission Request. I would also highlight that all of the projects listed in the report are ZK primitives and one of the big benefits we have as well is that the Semaphore and Bandada team have offered anyone interested in building this Mission their complete technical support throughout the development process (which imo is a big win for the Optimism Builders).

1 Like

I am an Optimism delegate [Agora - OP Voter] with sufficient voting power and I believe this proposal is ready to move to a vote.
agree with keeping a technology-agnostic approach to encryption to allow a wider set of use cases. Dont see need to use

  • EAS as an attestation layer for identity & credentials
  • Semaphore groups as industry-standard for anonymous ZK groups
  • Bandada as an easy-to-use UI & credential aggregator to lower the entry barrier for creating flexible anonymous groups, and finally

Just this is fine

  • Privacy Preserving Governance Applications: that will be built in this Mission Request
5 Likes

As a top 100 delegate I believe this proposal is ready to proceed to a vote. Agora - OP Voter

2 Likes

This sounds good. It is very detailed and I appreciate the thinking behind it. However, is the timeframe of three months until completion too narrow?

1 Like

Yes please! We need anon voting in the space!

I agree with @Pr0 though, not sure why this mission request needs to prescribe what tooling a project must use. Semaphore is super cool, but there are lots of tools out there.

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote!

chuck noris

3 Likes

'3rd’ing Pr0’s point, I’ll happily support this one if the wording is amended to remove the specification of certain tools. It might well be that the ones you’ve listed are the ones that all applicant teams end up using (are there even any other alternatives to EAS? I guess maybe hypercerts… if you squint a bit?) but it still seems more appropriate for the mission outline to be as neutral as possible.

3 Likes

I suggest to check this mission request trying to cover ZK stuff for private features [DRAFT] ZK Toolkit for ZK Application Developers I would work on making sure that both missions have clearly different scopes.

Also echoing comments above about having a more agnostic/neutral approach should be ideal, considering the continuously/dinamic changing ecosystem.

+1. Going to wait till there’s a response here before deciding whether or not to approve this mission. Privacy tech will be severely important for governance in the future though so I’m excited about this.

1 Like

I’m an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote!

2 Likes

As has been mentioned earlier, we like this request.

We are an Optimism delegate with sufficient voting power and we believe this proposal is ready to move to a vote.

2 Likes

I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.

3 Likes

Hi everyone!

Thanks a lot for your support to this Mission! We are excited to have received the votes needed to move the Mission to a vote. We’ve discussed this and we agree that removing the specifics for Semaphore/Bandada and EAS can enable more people to build on top of this Mission, but still keeping it to ZK tech (so it remains aligned with the Intent and the goal of onboarding more ZK builders to the Optimism Ecosystem).

I’ve talked to @brichis and my main concern is that if the phrasing is changed now I understand that the process is to have to revote it? I’m not sure if this can be achieved within the time limits. If not, can it be passed as was?

Proposed change is to have only the following text under

This Delegate Mission Request will leverage:

  • ZK powered Privacy Preserving Governance Applications: that will be built in this Mission Request.

And have Semaphore/Bandada and EAS described as examples of infrastructure that can be leveraged, but it is not limited to them being used.

Tagging the Delegates that voiced an interest in having it be primitive agnostic:
@Pr0 @Griff @MinimalGravitas @chaselb

Hi @Joxes , I understand your concern.

These missions have very different scopes, target audiences, and value created for the Collective as I understand it:

The Mission proposed by Michael is looking to build a Tool Kit that enhances adoption of ZK libraries and tools leveraged by Developers for building (creation or improvement of building blocks).

This Mission is aimed at having End-User applications that leverage ZK tech on the back to provide a privacy preserving experience for Governance Participants.

Here are some additional comments provided by Andy that also supports the other Mission goal in creating a library or repository.

Thank you for your thoughtfulness!

Very good point! We based the 3 month time frame based on the timelines used and successfully completed by projects and individuals that have received a Grant from the PSE team to build End-user facing applications with Semaphore. FYI several of these builders were not working full-time on it, so I see some wiggle room. This could be extended to 4 months, but due to the nature of a very targeted audience and this being an attempt to test in low-stakes environments we wouldn’t want to push for more than this.

Hi!

I think there may be a mistake? The Proposal is already re-named to Ready to Vote and has received 6 votes. Is the threshold no longer 4 votes?

Thanks!

1 Like

To make it easier for you to change, I’ll provide an approval on the condition of the change mentioned being reflected (so, in theory, if 4 delegates make an approval on this condition, then you can change it without worrying about whether you have sufficient approvals).

I am an Optimism delegate [Blockchain@USC] with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes

Hi @LauNaMu – yes, my mistake. I was looking at a tracker that had not been updated yet. You are indeed ready to move to a vote

1 Like

Signaling support for this proposal.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like

The Grants Council has opened early submissions as an Indication of Interest for this mission request here

For your application to be considered, the Mission request must pass the Token House vote on February 14th. Submissions will not be considered if a Mission Request is not approved on the 14th.

1 Like