Foundation Mission Request: RetroPGF 3 Discovery & Voting

[bdresser]

Foundation Mission Request: RetroPGF3: Discovery & Voting

• Proposed Foundation Mission (RFP): RetroPGF Discovery & Voting application

• S4 Intent: Governance Accessibility

• Proposal Tier: Fledgling Tie

• Baseline grant amount: 150k OP

• Should this Foundation Mission be fulfilled by one or multiple Alliances: Multiple (two)

• OP Labs or Optimism Foundation Sponsor: Jonas (gh: @JSeiferth, TG/Discord: @jonassft)

• Submit by: August 4th, 2023

• Selection by: August 11th, 2023

• • *

How will this Foundation Mission (RFP) help accomplish the above Intent?

Retroactive Public Goods Funding (RetroPGF) Round 3 will take place this fall and will distribute 30M OP to reward contributions that have supported the development and adoption of Optimism.

Badgeholders (voters in RetroPGF) need to be able to discover and vote on nominated projects. A good voting experience is core to supporting the work of badgeholders and ensuring an accurate RetroPGF process.  

Round 2 of RetroPGF put a high burden on the voting experience of badgeholders, requiring them to do a lot of manual work spreadsheets and forms.  This friction limited the overall accuracy of the RetroPGF round.

Round 3 of RetroPGF is set to build on the learnings of round 2 and provide a richer and more intuitive experience for browsing projects and submitting votes.

By doing so, this mission will contribute to a more accurate evaluation of projects and contribute to the overall success of RetroPGF 3. 

What is required to execute this Foundation Mission (RFP)?

Completing this mission requires:

1. Building a frontend that powers the discovery of projects and voting by badgeholders in RetroPGF round 3. The frontend will be based on existing designs and user stories and will utilize the Ethereum Attestation Service, and a combination of onchain and offchain (storage bucket, IPFS, etc.) sources to read data. The frontend should be fully open-source and should allow for future iterations of the functionality. The Foundation will provide product designs; this RFP primarily requires implementation.
2. Hosting and managing the application infrastructure, including backend infrastructure needed to capture and store badgeholder votes.

Core functionality of the discovery & voting application:

• Discover Projects: The application will enable users to explore all nominated projects, including search, filtering and sorting functionality.
• Viewing a Project's Profile: Users will be able to discover the profile of a specific project, populated with details provided by the project's team. The information will include general information about the project (name, creator, profile picture, social media links, etc.) and specific information relevant to RetroPGF’s goal of aligning impact and profit (description of contributions, links to contributions, impact description, funding history, etc.). 
• Discovering and voting on Lists: A standout new feature of round 3 will be 'Lists', a new tool for badgeholders to share their votes with others. Users will be able to discover, search, filter and sort Lists. By selecting a List, a user will find general information about the list (name, creator, description, impact evaluation description) and the votes on a number of projects included in a list. Badgeholders will be able to either directly import the votes of the list into their ballot, or edit the votes in a list based on their preferences, before adding them to their ballot. 
• Allocating and submitting votes: Badgeholders will be able to allocate and submit votes. Badgeholders are voting on individual project profiles or via a list (see above). All votes are aggregated in a badgeholders ballot, where badgeholders are able to see an overview of their votes, make changes to individual votes and submit their ballot. 

Technical Architecture and implementation:

• Query project data: Ethereum Attestation Service (EAS) is used to query existing onchain information relating to entities, their RetroPGF 3 application, and social verifications. Relevant schema information and indexer will be provided once the proposal has been accepted. 
  • An entity represents individuals or organizations
  • An application represents an entity’s application for RetroPGF and maps 1:1 to an entity. 
  • A social verification represents an attestation made by OptimismFND that indiciates an entity is the owner of a specific Twitter or GitHub account
• Query project lists: Ethereum Attestation Service (EAS) is leveraged to query existing onchain information relating to project lists. Relevant schema information and indexer will be provided once the proposal has been accepted.
• Create a voting backend: Backend infrastructure is required to capture and store votes, badgeholder votes will be private and stored on a backend server hosted by yourself. Minor features in the application may require additional backend support. 
• You will host the application yourself and maintain it until March 2024. Optimism Foundation will help you host this application at an optimism.io subdomain
• Everything that you build should be open-source under MIT license and should allow for future iterations of the functionality. 

For this Mission, the Optimism Foundation will accept up to two submissions. Multiple frontends will maximize the likelihood of success and improve the resilience of the system.

The rollout of functionality of the application will be done in multiple phases:

• Phase 1: Project discovery (early-October 2023) - users are able to discover eligible projects and view project profiles. 
• Phase 2: Voting (mid-October  2023)- badgeholders are able to discover lists and to allocate and submit votes. 

Please find user stories, designs and EAS & Metadata Schemas for the application linked. Note that these are not final.

👈 Click here to see WIP wireframes

  

What milestones will help the Collective track progress towards completion of this Foundation Mission (RFP)?

1. Specification for implementation, design approach, and architecture for the functionality listed above.
2. Open-source code repository to observe progress over time
3. Launching Phase 1:  Project discovery
4. Launching Phase 2: Voting
5. Successful completion of the voting period

How should badgeholders measure impact upon completion of this Mission (RFP)? 

• Qualitative feedback on the "accuracy" of RetroPGF Round 3
• Number of badgeholders who successfully voted via the frontend
• Qualitative feedback from badgeholders on the voting experience

Application instructions

To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread below. Submissions will be open until August 4th, at which time the Foundation will review all submissions and select up to two individuals/teams to complete the work defined here.

Submission form

_Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary._ ## Foundation Mission (RFP) Application **Please verify that you meet the qualifications for submitting at the above [Tier](https://gov.optimism.io/t/collective-trust-tiers/5877/2)** * **Alliance Lead:** Please specify the best point of contact for your team * **Contact info:** * **L2 recipient address:** * **Please list the members of your Alliance and link to any previous work:** Read more about Alliances [here](https://gov.optimism.io/t/season-4-alliance-guide/5873) --- **What makes your Alliance best-suited to execute this Mission?** - [...] - [...] **Please describe your proposed solution based on the above Solution Criteria (if applicable):** - [...] - [...] **Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:** - [...] - [...] **Please define the [critical milestone(s)](https://gov.optimism.io/t/grant-policies/5833) that should be used to determine whether you’ve executed on this proposal:** - [...] - [...] **Please list any additional support your team would require to execute this mission (financial, technical, etc.):** - [...] - [...] **Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:** _(Note: there is no guarantee that approved Missions will receive up-front cash grants.)_ - [...] Please check the following to make sure you understand the terms of the Optimism Foundation RFP program: - [ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. - [ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant - [ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types) - [ ] I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833) - [ ] I understand that I will be expected to following the public grant reporting requirements outlined [here](https://gov.optimism.io/t/suggested-public-reporting-requirements-for-grantees/4176) -- end of application -- ---

[Chomtana]

Hi @bdresser @JSeiferth WIP wireframes can't be seen as they are in a private repo Do we need to strictly follow the wireframes or we can purpose new features or some adjustment?

[JSeiferth]

Hey @Chomtana, thanks for flagging. I updated the issue, you should be able to see the wireframes now. You'll need to strictly follow the wireframes. New features/adjustments can be suggested, but timelines are pretty tight, which is why we're trying to minimize scope.

[magentaceiba]

Foundation Mission (RFP) Application

• Team Lead: Magenta Ceiba
• Contact info: magenta@dorg.tech | Discord: magenta | magenta#9858
• L2 recipient address: 0xCc1Cd159bE407658F0CA54791db93CF6Ee3127e2
• Please list the members of your Alliance and link to any previous work:

1. Ori Shimony (dOrg) Mechanism Design - DAO operations specialist with experience in governance design and web3 project architecture.
2. Magenta Ceiba (dOrg) Project Manager - Organizational development consultant, specializing in decentralized leadership and finance architecture.
3. Muath Juady (dOrg) Frontend web3 developer & designer.
4. Elio Briceño (dOrg) Fullstack web3 developer.

Our team has been working together for the past 3 years at dOrg.tech. We received a grant from the Ethereum Foundation to build DAO Drops, a retroactive public goods funding experiment that leverages on-chain data to empower participants to make fund allocation decisions. The first round was a huge success– see the report here.

---

What makes your Team best-suited to execute this Mission?

• Our team are experts in decentralized development, mechanism design, and multi-stakeholder funding governance. We have successfully delivered dozens of projects for web3 protocols including Safe, Starkware, Aragon, Balancer, DAOStack, and many more.
• You can see an example of our retroactive public goods funding design and implementation at https://daodrops.io. This work directly aligns with Optimism's RPGF approach.
• We have experience building for project impact discovery and evaluation, including surfacing marginalized or lesser known impactful projects. That informs our capacity to develop voter discovery, evaluation, and grouping of projects.
• We are dedicated to the ethos of decentralization and public goods funding, and we have the skills to execute this mission successfully.

---

Please describe your proposed solution based on the above Solution Criteria (if applicable):

In order to ensure the best possible discovery & voting experience for badgeholders, we will closely follow the detailed functionality & technical architecture outlined in the RFP above.

Additionally, our solution will include the following considerations for each of the core functionalities:

• Discover Projects:

  • Implement list inclusion within the project discovery feature, enabling a toggle switch for easy navigation. Additionally, incorporate necessary sorting and filtering capabilities as specified in the design.
  • Leverage insights from building DAO Drops to identify and document potential enhancements or missing functionalities in project discovery for possible inclusion in Round 3.

• Project Profiles: Surface all relevant data about the project in an easy-to-follow format as provided in the mock-ups.

• User-Curated Project Lists:

  1. Architecture: Formulate a specification, aligning with the provided design and user stories, for collecting and storing user-curated project lists and their impact evaluations.

  2. Backend: Construct a RESTful API or GraphQL backend that handles user operations such as CRUD operations for projects on lists, POST requests for impact attestations, and generating shareable URI endpoints for the lists. These URI endpoints will enable curators to widely share their evaluations and collections. Integrate this backend with the RetroPGF Protocol APIs, IPFS for decentralized data storage, and Ethereum Attestation Service (EAS).

  3. Frontend: Implement a responsive frontend using ReactJS, following the provided UX/UI designs, ensuring asynchronous communication with the backend for a smooth user experience.

• Voting Infrastructure:

  1. Database Design: Construct a database schema to capture and store votes, ensuring badgeholders can vote on both projects and lists, and modify their votes until final submission. This feature will be an adaptation of a similar functionality we previously developed for DAO Drops.

  2. Application Hosting: Deploy the application on a scalable, cloud-based hosting platform, guaranteeing continuous monitoring and maintenance during Round 3.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

• Week 1: Finalize requirements, setup repositories, define and create List Schema and Badgeholder Vote Schema.
• Week 2-3: Implement project discovery and project profile views.
• Week 4-5: Implement functionality to save lists, integrated with the Attestation system and IPFS.
• Week 6-7: Implement badgeholder vote storage, update, and final submission.
• Week 8: Set up CI/CD and complete final QA before launch.
• During Round 3: Monitor, support and manage the app.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

1) Implement project discovery & list discovery functionality 2) Implement voting functionality and all other steps for production-readiness 3) Successful completion of Round 3

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

• Periodic check-ins with technical team to ensure alignment of implementation with requirements

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

• We would like to be considered for a small upfront cash grant to secure our team's time.

---

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• [x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
• [x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• [x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
• [x] I confirm that I have read and understand the grant policies
• [x] I understand that I will be expected to following the public grant reporting requirements outlined here

[Chomtana]

Hi @JSeiferth @bdresser, I've recently been looking over your proposed wireframe. However, I have some questions and concerns.

Final Score Calculation

In RetroPGF 2, each badgeholder was given an excel sheet to distribute their votes as percentage scores, which must sum up to 100. The final percentage for each project was calculated by averaging the percentage of all badgeholders. The project would then be awarded OP tokens proportional to its percentage from a total of 10M OP.

However, RetroPGF 3 proposes a change. Instead of percentage scores, badgeholders are now responsible for directly assigning an OP amount to each project, but the total OP doesn't have to sum up to 30M OP. If the total sum is not 30M OP, it seems to lead to multiple possible ways to calculate the final score.

From my understanding, we will do this by summing up the OP assignment from all badgeholders for each project, then dividing that by a constant such that the total OP after division equals 30M OP. This would then yield the final RetroPGF 3 OP distribution result.

Can anyone confirm if my understanding of the process is correct?

Are we responsible for calculating the final result?

Privacy Concerns

Another concern is over the privacy of badgeholders' voting results. While these results are supposed to be private, the system is designed to store them in our backend, which potentially exposes the data to us. Is this the intended design, or should we explore cryptographic solutions to ensure complete vote privacy?

Missing Pages

Upon reviewing the wireframe, we noticed that the following pages appear to be missing:

• Project detail page
• Result page
• Voting guideline

Is it our responsibility to create documentation?

We are committed to delivering the best quality product within a tight timeframe of one month, so understanding these requirements beforehand is crucial. We are aiming to finalize the Specification for implementation, design approach, and architecture for the functionality listed above by 4th August.

I appreciate your help in understanding these details better. Thank you for your time, and we hope you will select us for this work.

[JSeiferth]

@Chomtana here are the answers to your questions:

Final Score Calculation

Are we responsible for calculating the final result?

You are not responsible for calculating the final results, this will be done by the Optimism Foundation

Privacy Concerns You will be trusted to maintain the privacy of badgeholder votes and to not share the votes publicly. Cryptographic solutions to this could be a nice to have but are not in the scope of this RFP

Missing Pages As mentioned in the RFP, user stories and designs for the application will be published by August 4th.

Documentation Basic documentation of your work is required. User facing documentation and guidelines will be created by the Foundation.

[Chomtana]

So, we sent raw ballot results to the foundation.

I wonder if two frontend are selected, how can we sync the ballot result together if badgeholders are voted on different platforms?

[carlbarrdahl]

Hi @JSeiferth, Some questions came up while reading through the RFP:

• It says badgeholder votes will be private but the lists that contain the votes are public.
  • Does this mean badgeholders choose to publish the list?
• Is List and a submitted ballot the same thing?
  • Does each submitted ballot automatically become a list or is there extra UI and logic for list management?
• Can we use EAS to store votes as attestations or are you thinking an internal database for this?
• Are the projects stored as EAS attestions with pointers to metadata or in a different indexer/data source?
• Phase 1 and 2 roll-out both say mid-October 2023, is this correct?

[Zeptimus]

Hello @JSeiferth,

Our team has a couple of extra questions to add to the ones before asked by @carlbarrdahl regarding the RFP that we'd appreciate if you could help us clarify:

1) Will we be tasked with creating a submission form for the projects to apply for being part of the RetroPGF vote? If not, and if the foundation is managing this through a separate website, are there accessible APIs that will allow us to efficiently obtain the relevant data?

2) As for the design of the platform, can we expect that designs will be provided for every page that is meant to be implemented? In case there are pages for which designs are not supplied, would it be acceptable for us to bring our own designer to create these, in order to facilitate the voting process?

[Developer-piyush]

Foundation Mission (RFP) Application

Alliance Lead: Piyush Choudhary Contact info: piyushch377@gmail.com | Discord: boldpanther L2 recipient address: 0x2b7c6e9612c3935c039d13222f852103305d6657

Please list the members of your Alliance and link to any previous work and what makes your Alliance best-suited to execute this Mission?

Our team is exceptionally well-suited to execute this mission due to the diverse expertise and experience of its members. Each team member brings valuable skills and accomplishments to the table, ensuring that we can tackle all aspects of the project effectively and produce high-quality results. Let's elaborate on our team members' capabilities:

1. Sumit Kumar - WEB3 and Blockchain Developer: Sumit is a skilled developer with profound knowledge of the optimism ecosystem and blockchain technologies. His expertise in WEB3 development will be pivotal in implementing decentralized features and integrating blockchain capabilities into the project. Sumit's experience in working with distributed ledger technologies will contribute to the project's innovation and cutting-edge functionality.

   GitHub Profile: https://github.com/startup-dreamer

2. Chaitanya Rai - Backend Development Lead and Security Expert: Chaitanya is a seasoned backend developer with extensive experience in creating complex backends and designing efficient schemas. His ability to architect scalable, robust, and secure backend systems will be instrumental in building a reliable foundation for the project. With a track record of successful projects, Chaitanya has honed his skills in handling data and ensuring seamless interactions between the frontend and backend components.

   GitHub Profile: https://github.com/Chaitanyarai899

3. Safayet Alam - MERN Stack Developer: Safayet is a highly experienced MERN stack developer, proficient in crafting interactive, responsive, and user-friendly frontends. His expertise in front-end development will ensure that the project delivers a smooth and engaging user experience. With a keen eye for design and user interface principles, Safayet can create visually appealing and intuitive interfaces that align with the project's objectives.

   GitHub Profile: https://github.com/safayetdib

4. Piyush (Alliance Lead and Project Manager) - SAAS Development Expert: I bring invaluable expertise as our Alliance Lead and Project Manager. With over 3 years of experience in leading SAAS development in web3 and 5+ years in web2 SAAS, I have a proven track record in delivering high-quality development solutions. I operate a dedicated agency specializing in web3 and web2 SAAS, serving numerous clients successfully. My leadership and project management skills will ensure seamless coordination and timely delivery of the project.

   GitHub Profile: https://github.com/developer-piyush LinkedIn: LinkedIn Profile Hooman Digital

5. Nitish Kumar - In-house UI/UX Designer: Nitish is our skilled in-house UI/UX Designer who plays a vital role in shaping the project's design and user experience. With his expertise, he can make design fixes, optimize responsiveness for mobile devices, and ensure that the project's visual appeal matches its functionality. Design is already being provided but if something comes up we can easily manage.

   Behance Profile: https://www.behance.net/nitishkumar142

6. Avanish Singh - Web3 and Blockchain Developer: Avanish's talent lies in web3 and blockchain development, particularly in writing smart contracts. His skills will be critical in implementing blockchain logic. With a deep understanding of blockchain protocols, Avanish can contribute to building secure and reliable applications.

   GitHub Profile: https://github.com/Averek7

7. Abdul Al Numan - Full Stack Developer: Abdul brings extensive experience as a full-stack developer with a specialization in creating interactive UIs and managing complex backends. His proficiency in both frontend and backend development will help bridge the gap between the user interface and underlying systems. Abdul's expertise in API integration and handling data will be vital for ensuring smooth communication and data flow within the application.

   GitHub Profile: https://github.com/numangit

With this talented team, we have a well-rounded and diverse set of skills to tackle the all aspects of the project. Each team member will play a crucial role in ensuring the project's success, and together, we are committed to delivering a high-quality solution that meets and exceeds expectations.

Some past projects to showcase our team skills:

1. DVal - Seamless Blockchain-based Solution:

DVal offers a seamless end-to-end solution that leverages blockchain technology to optimize the entire journey from the manufacturer to the end customer. The platform also provides additional after-sales services, such as handling warranty claims. Visit the GitHub repository Github and the live link here to explore further Live Link.

2. Blockchain-based Decentralised Supply Chain Management System:

This project is a decentralized supply chain management system powered by blockchain. It enhances supply chain operations by ensuring transparency and traceability throughout the process. Discover more on the GitHub repository Github and link Live Link.

3. Smart Wallet Project

This project is Web3 Blockchain based smart-wallet smart contract deployed through Hardhat development and testing environment. This project is of a smart wallet in which allows its owner to allot certain amount of money(ethers) to spent as a allowance and anyone can deposite any amount of money. Discover more on the GitHUb repository: Github

4. DevNetwork - a complete social media platform

This prokect a secure full stack social media application with complex backend and no-sql Schema. The authentication and authorization system is JWT based for enhanced security. Discover more on the github repository Github and live Link.

5. Aurum-Protocol - NFT Lending Borrowing Protocol

Aurum is an over-collateralized NFT Custodial Lending and Borrowing Protocol that allows users to borrow ETH using their NFT as collateral while enabling lenders to earn interest on their deposited ETH by participating in the protocol's lending pool. The github Repository for this project Github and the Live Link

6. Collaterizing NFTs for Loans and Borrowing:

The Collaterizing NFTs project introduces a novel concept of using valuable NFT assets to secure loans and enable borrowing and lending within the NFT ecosystem. To learn more, visit the GitHub repository Github and Live Link.

These projects showcase our team's expertise in blockchain development, decentralized applications, backend development and innovative solutions that address real-world challenges. Feel free to explore the repositories and live links to see the projects in action!

Together, our highly experienced and innovative team members form a strong technical foundation that can handle a wide range of challenges. We can effectively collaborate, leveraging each other's strengths, to deliver a project that meets and exceeds expectations. Our collective passion for technology and commitment to excellence ensures that we are capable of producing top-tier results for this mission. In conclusion, with our talented team of diverse technical backgrounds, we are confident in our ability to execute this mission successfully and deliver a product of the highest quality.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

Project Discovery Feature:

• For implementing the desired searching, sorting, and filtering functionalities, we are planning to use open-source search engines such as Apache Solr or Elasticsearch in the backend. These search engines offer robust full-text search capabilities, efficient sorting, and flexible filtering options for various tags, making them ideal choices to handle project discovery in the RetroPGF 3 application.

• In the frontend, React.js will be used to create drop-down options, toggles, etc., as shown in the wireframe and seamless integration with the backend will be done.

Viewing a Project's Profile Feature:

• React.js will be used to build the exact profile viewing page as provided in the wireframe.
• Dedicated API routes to fetch the data from the database about each project and populate the frontend page.
• Ethereum Attestation Service (EAS) to query existing on-chain information relating to entities, their RetroPGF 3 application, and social verifications
• Relevant tags on every project profile making it easily discoverable through searching, filtering, and sorting functionalities.

Discovering and Voting on Lists Feature:

• Making dedicated REST-API routes for badgeholders to create lists which are discoverable and many other list related functionalities.

• Here are the exact API routes for every list related functionality:

  • POST request -\api\list\createlist: this post request route will take the name, description, creator name, and projects in the body to declare a list which will be added to their ballot.
  • PUT request - \api\list\updatelist: this request will be used to further add more projects to the list or delete project by the creator.
  • POST request - \api\list\copylist: this request will add a list published by a badgeholder into the copier's ballot to be updated and used by badgeholder.
  • DELETE request - \api\list\deletelist: this request will delete an entire list or a copy of a list if the badgeholder is not satisfied with list.

• Frontend: Building the exact frontend as shown in the wireframe for lists which will be highly responsive, smooth, and user-friendly.

Architecture and Implementation to Allocate Votes:

• Database Schema: A no-sql schema is the preferred choice according to us for this project, however, we are still very comfortable and confident if any particular schema or database has already been selected. Here is an example schema which can be used to store all the voting information: Project Collection:

  {
  "_id": "project_id_1",
  "name": "Project 1",
  "description": "This is the description of Project 1.",
  "creator": "Creator's Name",
  "profilePicture": "url_to_profile_picture",
  "socialMediaLinks": {
    "twitter": "twitter_handle",
    "github": "github_username"
  },
  "contributions": ["contribution_1", "contribution_2", "contribution_3"],
  "impactDescription": "Description of the impact of Project 1.",
  "fundingHistory": [
    { "date": "2023-07-01", "amount": 1000 },
    { "date": "2023-07-15", "amount": 1500 },
    { "date": "2023-07-28", "amount": 2000 }
  ]
  }

  Voter Collection:

  {
  "_id": "voter_id_1", \\ can be a hashed to maintain complete anonymity.
  "name": "Voter 1",
  "address": "0xabcde12345",
  "ballot": [
    {
      "project": "project_id_1",
      "vote": 5
    },
    {
      "project": "project_id_2",
      "vote": 3
    },
    {
      "project": "project_id_3",
      "vote": 2
    }
  ]
  }

• By using the above schema or a better-revised schema or any schema provided to us, REST API routes will be created:

  • POST \api\voting\vote: will be used by the badgeholder to cast the vote.
  • PUT \api\voting\updatevote: will be used to update votes.
  • GET \api\voting\votinginfo: to fetch the current voting information of the badgeholder.
  • GET \api\voting\opused: will fetch information about OP used by the badgeholder to populate the OP allocated progress seek shown in the wireframe.

• Whitelist functionality to be implemented in the backend so only whitelisted wallet address badgeholders could access these important routes or any other badgeholder route.

• Complete and total anonymity will be maintained by not revealing any voting information to anyone but the voter through any route.

• Smooth frontend using REACT.js which will be highly responsive and exactly the same as provided in the wireframe.

CI/CD pipeline for hosting:

• Implementation of a continuous integration and delivery pipeline with any preferred cloud service providers like AWS, AZURE cloud, etc.
• Optimal configuration and DevOps infrastructure using Docker and Kubernetes for seamless scaling and availability.

Based on the information provided, we have meticulously crafted this schema with careful consideration and brainstorming. However, please note that the finalization of the schema is subject to approval and discussion with the foundation team after more details have been released. The schema can be viewed at this link: Schema

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Week 1: August 11th - August 18th

• Requirement Analysis and Finalization:
  • Discuss and gather detailed requirements from the organization and understand everything in even more depth.
  • Finalize the database schema based on the requirements.
  • Obtain access to the organization's private resources, including API keys for integration with Ethereum Attestation Service (EAS).
  • Plan and design the login and verification system using technologies like JWT for badgeholders and users.
• Frontend and Backend Setup:
  • Set up the frontend project using React.js in NEXT.js framework.
  • Initialize the backend project and configure the required dependencies.

Week 2: August 19th - August 25th

• Building Login and Verification System:
  • Implement API routes for badgeholders and users to register and log in.
  • Implementing whitelist functionality in the backend for whitelisting wallet address of the badgeholders.
  • Use JWT (JSON Web Tokens) for authentication and authorization of badgeholders and users.
  • Create frontend components for user registration, login, and verification.
• Frontend for Login and Registration:
  • create the user interface for user registration and login.
• start working on the search functionalities by using preffered search engine( Apache Solr, elasticsearch etc.)

Week 3: August 26th - September 1st

• Backend for Discovery Page:

  • Work on the chosen open-source search engine (Apache Solr or Elasticsearch) in the backend to create the functionalities.
  • Implement search, sorting, and filtering functionalities for project discovery using the search engine.

• Frontend for Discovery Page:

  • Create the user interface for project discovery using NEXT.js.
  • Implement frontend components for searching, sorting, and filtering functionalities.
  • Integrate the frontend with the backend to fetch and display search results.

• Discovery page will be completed by 3rd week.

Week 4: September 2nd - September 8th

• Backend for Viewing Project Profiles:
  • Implement API routes to fetch project details from the database based on the provided schema.
  • Integrate Ethereum Attestation Service (EAS) to query on-chain information and display relevant social verifications on project profiles.
• Frontend for Viewing Project Profiles:
  • Create the user interface for viewing project profiles using React.js.
  • Implement frontend components to display project details and social verifications.

Week 5: September 9th - September 15th

• Backend for List Creation Page:
  • Implement API routes for badgeholders to create, update, copy, and delete lists, count OP functionality to update the real time count on Navbar as shown in the wireframe.
• Frontend for List Creation Page:
  • Design and create the user interface for creating and managing lists using NEXT.js.
  • Implement frontend components for list-related functionalities, including list creation and management.

Week 6: September 16th - September 22nd

• Backend for Submitting Vote Components:
  • Create API routes for badgeholders to cast votes, update votes, fetch voting information, and OP used progress.
• Frontend for Submitting Vote Components:
  • Design and create the user interface for voting on projects and lists using NEXT.js.
  • Implement frontend components for casting and updating votes.

Week 7: September 23rd - September 30th

• Integration and Testing:

  • Integrate all frontend and backend components to create a fully working application.
  • Perform thorough testing to identify and fix any bugs or issues.

• CI/CD Pipeline and Deployment:

  • Set up a continuous integration and delivery pipeline for automatic deployment of the application.

• Conduct user acceptance testing with the organization to validate the application's functionality.

End of September and Start of October: Project Completion

• Final Review and Documentation:

  • Ensure the application meets all requirements specified in the RFP.
  • Conduct a final review with the organization to validate the successful execution of the mission.
  • Conduct user acceptance testing with the organization to validate the application's functionality.
  • Prepare documentation and user guides for the application.

• Launch and Operation:

  • Deploy the application to production and ensure it is operational and accessible to users.
  • making required changes if any using CI/CD pipeline and maintain the project till March 2024.

By following this week-by-week plan, both frontend and backend development will progress together, ensuring that all major components of the application are built simultaneously. The plan also includes specific milestones for each page and functionality, allowing for continuous integration and testing to deliver a complete and functional RetroPGF 3 Discovery & Voting application by the end of September. By following this timeline we will have enough time for proper testing and validation.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

The critical milestones that should be used to determine the successful execution of the proposal are as follows:

1. Completion of Project Discovery Feature (End of Week 3):

   • Backend implementation of the search engine (Apache Solr or Elasticsearch) for project discovery, including search, sorting, and filtering functionalities.
   • Frontend implementation of the project discovery page using React.js and integration with the backend to fetch and display search results.

2. Viewing Project Profiles Feature (End of Week 4):

   • Backend implementation to fetch project details from the database and integrate with Ethereum Attestation Service (EAS) for social verifications.
   • Frontend implementation of the project profile viewing page using React.js, displaying project details and social verifications.

3. Discovering and Voting on Lists Feature (End of Week 5):

   • Backend implementation of API routes for badgeholders to create, update, copy, and delete lists, including OP used count functionality.
   • Frontend implementation of the list creation page using React.js, allowing badgeholders to create and manage lists.

4. Submitting Vote Components (End of Week 6):

   • Backend implementation of API routes for badgeholders to cast and update votes, fetch voting information, and OP used progress.
   • Frontend implementation of the voting components using React.js, enabling badgeholders to cast and update votes.

5. Integration and Testing (End of Week 7):

   • Successful integration of all frontend and backend components to create a fully working application.
   • Thorough testing to identify and fix any bugs or issues, ensuring a stable application.

6. CI/CD Pipeline and Deployment (Start of October):

   • Setting up a continuous integration and delivery pipeline for automatic deployment of the application.
   • Successful deployment of the application to production, making it accessible to users.

7. Final Review and Documentation (Start of October):

   • Validation of the application's functionality through user acceptance testing with the organization.
   • Preparation of documentation and user guides for the application.

A review meeting will be held with end of each timeline to show our progress and assure that these milestones have been completed by us.

Based on the information provided, we have meticulously crafted this schema with careful consideration and brainstorming. However, please note that the finalization of the schema is subject to approval and discussion with the foundation team after more details have been released. The schema can be viewed at this link: Schema

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

We request holding regular bi-weekly or milestone review meetings with the foundation's technical team to ensure transparency and maintain high-quality standards in all our work. Additionally, we kindly request some financial assistance to support the use of highly secured and premium cloud computing resources. This assistance will enable us to maintain the application until March 2024 within a secure computing environment.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Upfront capital is not an issue. Though we will need financial assistance to leverage premium cloud computing resources to keep the project running till march 2024, properly and in a secured enviroment.

---

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance. [x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant [x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual [x] I confirm that I have read and understand the grant policies [x] I understand that I will be expected to following the public grant reporting requirements outlined here

[JSeiferth]

Some Q&A 🌞

I wonder if two frontend are selected, how can we sync the ballot result together if badgeholders are voted on different platforms? @Chomtana

A: We will ask badgeholders to only iterate and submit their ballot via one of the frontends. A solution that allows for ballots to be synched across frontends would be nice to have, but we're trying to minimize the scope due to the short timeline.

• It says badgeholder votes will be private but the lists that contain the votes are public.
  • Does this mean badgeholders choose to publish the list?
• Is List and a submitted ballot the same thing?
  • Does each submitted ballot automatically become a list or is there extra UI and logic for list management?
• Can we use EAS to store votes as attestations or are you thinking an internal database for this?
• Are the projects stored as EAS attestions with pointers to metadata or in a different indexer/data source?
• Phase 1 and 2 roll-out both say mid-October 2023, is this correct? @carlbarrdahl

A:

• Badgeholders can publish a list in which they recommend how to vote on projects to other badgeholders. This is essentially a delegation and knowledge sharing tool that allows badgeholders to share how they vote on projects/areas they have expertise in. Badgeholder votes themselves are private.
• A list is separate from a ballot. Badgeholders can import votes from a list into their ballot or use a list to inform their votes. Ballots do not become lists.
• This will require some internal database see "Backend infrastructure is required to capture and store votes, badgeholder votes will be private and stored on a backend server hosted by yourself."
• Yess, projects are stored as EAS Attestations with pointers to metadata on IPFS
• Oh thanks for flagging! Phase 1 should begin early October

Q

1) Will we be tasked with creating a submission form for the projects to apply for being part of the RetroPGF vote? If not, and if the foundation is managing this through a separate website, are there accessible APIs that will allow us to efficiently obtain the relevant data? 2) As for the design of the platform, can we expect that designs will be provided for every page that is meant to be implemented? In case there are pages for which designs are not supplied, would it be acceptable for us to bring our own designer to create these, in order to facilitate the voting process? @Zeptimus

A:

1. You'll not be tasked with creating the submission form, this is handled by the Foundation/OP-labs. The data will be stored as attestations on EAS with pointers to metadata on IPFS - see "Query project data" in the RFP.
2. There will be designs for every page. If in the process of fulfilling the RFP we find missing functionality/designs the support of your own designer could be useful.

[Chomtana]

Thank you for your clarification. All of the questions and answers are extremely useful.

[charliecf]

Foundation Mission (RFP) Application

• Alliance Lead: Charlie @charliecf
• Contact info: zcf#9299 (Discord)
• L2 recipient address: oeth:0x3a153B0608a87a4BdD4F7Afa90670110d4CBEa62
• Please list the members of your Alliance and link to any previous work:
  • Team's work: https://github.com/voteagora, our repos are open source
  • Agora
  • https://vote.optimism.io/

---

What makes your Alliance best-suited to execute this Mission?

We’ve been working with the OP Foundation and the Optimism community on the Token House voting interface and contract improvements over the last few months and are intimately familiar with the technical requirement and community needs.

Our team has a strong mix technical and product design experience:

• Governance focused full-stack technical team having done work from client, backend, to protocol work. With a strong emphasis on governance software.
• Deep product & design experience building robust apps in both web3, crypto and more specifically in governance for communities ranging from Optimism to Nouns, ENS, and Uniswap.
• We have consistently worked with the community to gather input, respond to feedback, and provide support.

Lastly, we have a strong belief in the mission around RetroPGF and therefore want to contribute. We were a recipient of last round’s RetroPGF, we understand the process, the community and the potential economic impact if such a project is successful at scale.

Please describe your proposed solution based on the above Solution Criteria:

As one of the core responsibilities of the Citizen’s House, we believe RetroPGF’s success is a critical piece to building a thriving Optimism ecosystem.

Voting Client

• Unified voting experience: Hosted on vote.optimism.io to help improve user experience for both Token House and Citizen House voters (as many of them overlaps). Everyone will be able to see and discovery projects, only logged in badgeholders will be able to view voting specific pages in relation to RetroPGF.

• Query project data & lists: Use Ethereum Attestation Service to fetch project meta data on-chain.
• Discover Projects: The application will enable users to explore all nominated projects, including project name search, filtering and sorting functionality.
  • Note: scope does not include front-end creation of profiles and projects.
• Project's Profile Page: Users will be able to discover the profile of a specific project, populated with details provided by the project's team.
  • General information about the project (name, creator, profile picture, social media links, etc.)
  • Specific information relevant to RetroPGF’s goal of aligning impact and profit (description of contributions, links to contributions, impact description, funding history, etc.)
• Lists feature, with discovery & voting: Enable badgeholders to share their votes with others. Users will be able to discover, search, filter and sort Lists. By selecting a List, a user will find general information about the list (name, creator, description, impact evaluation description) and the votes on a number of projects included in a list. Badgeholders will be able to either directly import the votes of the list into their ballot, or edit the votes in a list based on their preferences, before adding them to their ballot.
• Votes: Badgeholders will be able to allocate and submit votes. All votes are aggregated in a badgeholders ballot, where badgeholders are able to see an overview of their votes, make changes to individual votes and submit their ballot.
• Notification opt-in: Ability for badgeholders to opt-in to smart, non spammy voting notifications to ensure full compliance

Open Backend Voting API

• Open API Access: Shared infrastructure layer to prevent duplication of “voted twice” across multiple clients. Optimism Foundation & Labs will have full and unlimited access along with ability to grant access.

• Capture and store votes: Badgeholder votes will be private and stored off-chain.
• Server-side verification of attestations: To ensure that no one can spoof or interfere with the votes.
• Server side functions: Allow admins to download key reports for later processing / measuring

Admin Dashboard

• Voting Operations Dashboard: Enable OP foundation to track status of each badgeholder’s vote. This will include and not limited to voting status, results and their progress throughout each RetroPGF process.
• Notification System: Enable OP ops to opt-in for email notifications on new projects or when they need to vote again (for future RetroPGF rounds)
• Data Export: export data to clean CSV such that OP Foundation is able to build custom tables, analytics, etc.

All of our code will be open-sourced (as they are already) for the community to build on top, collaborate and continue to improve on together.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Assuming a start date of August 18th, 2023 - 1 week after the selection deadline.

Milestone	Delivery Date
Lock in EAS schema and List architecture	August 18th, 2023
Design and release API schema	September 1st, 2023
Voting API launch	September 21st, 2023
Launch discovery of projects, profile & lists**	October 6th, 2023
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

We will commit to making improvements, support and feature improvements for subsequent RetroPGFs until March 2024. **See questions on List architecture below

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

• Design and build the backend voting API. It will be open-sourced and usable by other clients as well.
• Build the client and integrate into vote.optimism.io. This will make it easy for users to navigate between Token House and Citizen House voting requirements, especially for voters who are part of both.
• Gather feedback and feature requests from RetroPGF Round 3, write and publish learning and next steps to the community.

Please list any additional support your team would require to execute this mission:

Close collaboration with the project sponsor (@JSeiferth) and Optimism team on design and implementation feedback.

There are certain areas of the spec that still feel a little up in the air and we would need to lock in certain key details in order to make sure we hit the deadline and have a great lunch.

1. Clarity on the goal and architecture of the Lists feature: we need ensure that badgeholders’ votes are not exposed to third parties looking to lobby next season. If that is not a concern, we would propose that all of the votes go on-chain also. Architecture design and confirmation needed by August 18th, 2023.
2. Schemas locked down: We will need detailed schemas for CitizenHouse Attestations, RetroPGF projects Attestations and List Architecture locked by August 18th, 2023.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:

As a small team with no institutional investors reliant mostly on public goods funding, the grant being locked for a year significantly impedes our operations, requiring us to source funding from elsewhere to make payroll on a month to month basis – as well as cover upfront costs like tax. We can scrape by without upfront cash by seeking grants elsewhere, and look into financing, but early liquidity would significantly help our operations.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• [x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
• [x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• [x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
• [x] I confirm that I have read and understand the grant policies
• [x] I understand that I will be expected to following the public grant reporting requirements outlined here

[Chomtana]

Foundation Mission (RFP) Application

Please verify that you meet the qualifications for submitting at the above Tier:

Opti.Domains is a grant recipient in season 3, Cycle 11

Grant Update: https://gov.optimism.io/t/ready-gf-phase-1-proposal-opti-domains-interoperable-domain-name-for-the-op-stack/5510/22?u=opti.domains

As clarified by @lavande: “That sounds like Fledging! Receiving and executing on a grant constitutes working with the Collective”

https://gov.optimism.io/t/collective-trust-tiers/5877/10?u=opti.domains

Alliance name: Opnitor Alliance Lead: Chomtana Chanjaraswichai (Opti.domains) Contact info: Chomtana001@gmail.com L2 recipient address: 0x73F4e6132Cd9E4a3945d9CA6E98e5985BBe16d2D

Please list the members of your Alliance and link to any previous work:

Chomtana Chanjaraswichai (Opti.Domains, Alliance Lead)

• Solo developer developing Opti.Domains
• 1st in Axelar 2nd Code4rena audit contest
• 2nd in Axelar 1st Code4rena audit contest
• Contribute to Seaport in Gas Optimization
• Fork Wagmi Library to integrate support for custom ENS UniversalResolver support
• Fork Rainbowkit Library to integrate support for the domain name on Optimism
• Participated in SCB Bangkok Blockathon 2023 and won 3rd price with 838.Earth project
• Participated in SCB Bangkok Blockathon 2021 and won 2nd price with Estate-Onblock project
• Has experience developing Kaokonlakao, the largest running event in Thailand with more than 10,000 participants actively submitting their running progress to our system with a bunch of volunteer grading submitted progress.
• Won silver medal in 13th Thailand Olympiad in Informatics (TOI13)
• Won many hackathons in the past

4 developers below have these experiences in common

• https://www.finstable.co.th/
• Videfi | ETHGlobal
• Muddy Heart | ETHGlobal
• ScalingTree | ETHGlobal
• Cretodus | ETHGlobal
• SCB Bangkok Blockathon 2023
• SCB Bangkok Blockathon 2021

Warun Singhal (Developer)

Working as a Blockchain Software Engineer at Finstable co. ltd (01/2022 - Present)

• Joined BANGKOK BLOCKATHON 2023 by SCB10X ( APR 2023 ) and made it to 15 of the finalists team with the project BestEx: The Super Aggregator, BestEx searches for the best prices for your trade over DEX Aggregators and Centralized Exchanges.
• Joined SCALING ETHEREUM by ETHGlobal ( MARCH 2023 ) and got the prizes Winner of The Graph - Best new subgraph(s) & Winner of Polybase with the project ScalingTree: One repository for the world tree data. Social media for trees.

https://ethglobal.com/showcase/scalingtree-zida1

• Joined FVM SPACE WARP by ETHGlobal ( FEB 2023 ) and got the prize Winner of Filecoin & IPFS - FVM Jetpacks with the project Cretodus: A decentralized data marketplace where any users can upload any data they want to keep it on Filecoin network for data preserving. https://ethglobal.com/showcase/cretodus-fga5u

Nattawat Songsom (Developer)

Experience:

• Currently working as a blockchain software engineer at FInstable co. ltd (01/2023 - PRESENT)
• Joined the Autonomous world 2023 hackathon by ETHGlobal and built Muddy Heart, an On-chain action RPG game powered by @lattizexyz's MUD engine. https://ethglobal.com/showcase/muddy-heart-cdm0k
• joined the BANGKOK BLOCKATHON 2023 by SCB10X ( APR 2023 ) and made it to 15 of the finalists team with the project BestEx: The Super Aggregator, BestEx searches for the best prices for your trade over DEX Aggregators and CEX, guaranteeing your best execution prices in trading. Pitch video link: https://www.facebook.com/huzen.karode/posts/pfbid0nYkFkBYf7uKzXChgCU6nM1tY3aX2VM8jFiJD1d6yDpXEJcxPuNo23KVQKknoWHgyl
• joined SCALING ETHEREUM by ETHGlobal ( MARCH 2023 ) with the project ScalingTree: One repository for the world tree data. Social media for trees. https://ethglobal.com/showcase/scalingtree-zida1 and got the prizes
  • Winner of The Graph - Best new subgraph(s)
  • Winner of Polybase - Pool Prize
• joined FVM SPACE WARP by ETHGlobal ( FEB 2023 ) and got the prize Winner of Filecoin & IPFS - FVM Jetpacks with the project Cretodus: A decentralized data marketplace where any users can upload any data they want to keep it on Filecoin network for data preserving. https://ethglobal.com/showcase/cretodus-fga5u

Academic work:

• Published the paper “The SWC-based Security Analysis Tool for Smart Contract Vulnerability Detection” which presents a Solidity analysis tool for detecting bugs in smart contracts. Link: https://ieeexplore.ieee.org/document/10067759

Teerawut Saesim (Developer)

Work Experience: Currently working as Software Engineer at Finstable co,. Ltd (10/2022- Present)

• Consolation Prize at the final round of National Software Contest (NSC2022) to make digital platform that helps medical personnel manage COVID-19 case data, in the format of a web application.
• Joined Hack FS 2023, ETH Global. Project name “Videfi”, a web3 content platform utilizing decentralized file storage solutions, such as Filecoin, IPFS, Lighthouse.storage, NFT.storage, etc. Videfi aims to make freedom of content creation and strengthen ownership upon content of creators. https://ethglobal.com/showcase/videfi-nvth7
• Joined the Autonomous world 2023 hackathon by ETHGlobal and built Muddy Heart, an On-chain action RPG game powered by @lattizexyz's MUD engine. https://ethglobal.com/showcase/muddy-heart-cdm0k

Tanakorn Karode (Developer)

Working experience:

• 05/2023 - Present Currently working as a CTO of Prairie Falcon Partners, providing crypto currency market making service
• 07/2020 - Present Blockchain researcher at BLOCK research team, Prince of Songkla University, Phuket, Thailand
• 02/2023 - 05/2023 Software Engineer at Trinket Inc., a social media platform utilizing location and time for experiencing, adapt a blockchain for media preservation
• 02/2023 - 05/2023 Technical Advisor at Finstable Co., Ltd.
• 03/2021 - 01/2023 CTO at Finstable Co., Ltd.,
• 07/2020 - 02/2021 Lead blockchain engineer at Finstable Co., Ltd., a blockchain consulting firm, providing total solution for business tokenization and blockchain services

Competition:

• 06/2023 Joined Hack FS 2023, ETH Global. Project name “Videfi”, a web3 content platform utilizing decentralized file storage solutions, such as Filecoin, IPFS, Lighthouse.storage, NFT.storage, etc. Videfi aims to make freedom of content creation and strengthen ownership upon content of creators. https://ethglobal.com/showcase/videfi-nvth7

• 05/2023 Joined the Autonomous world 2023 hackathon by ETHGlobal and built Muddy Heart, an On-chain action RPG game powered by @lattizexyz's MUD engine. https://ethglobal.com/showcase/muddy-heart-cdm0k

• 04/2023 Joined the BANGKOK BLOCKATHON 2023 by SCB10X and made it to 15 of the finalists team with the project BestEx: The Super Aggregator, BestEx searches for the best prices for your trade over DEX Aggregators and CEX, guaranteeing your best execution prices in trading. Pitch video link: https://www.facebook.com/huzen.karode/posts/pfbid0nYkFkBYf7uKzXChgCU6nM1tY3aX2VM8jFiJD1d6yDpXEJcxPuNo23KVQKknoWHgyl

• 03/2023 Joined SCALING ETHEREUM by ETHGlobal with the project ScalingTree: One repository for the world tree data. Social media for trees. https://ethglobal.com/showcase/scalingtree-zida1 and got the prizes

  • Winner of The Graph - Best new subgraph(s)
  • Winner of Polybase - Pool Prize

• 02/2023 Joined FVM SPACE WARP by ETHGlobal and got the prize Winner of Filecoin & IPFS - FVM Jetpacks with the project Cretodus: A decentralized data marketplace where any users can upload any data they want to keep it on Filecoin network for data preserving. https://ethglobal.com/showcase/cretodus-fga5u

Academic work:

• W. Werapun, T. Karode, T. Arpornthip, J. Suaboot, E. Sangiamkul, P. Boonrat, (2023). The Flash Loan Attack Analysis (FAA) Framework—A Case Study of the Warp Finance Exploitation. Informatics - MDPI 2023, Vol10, issue 1(March 2023), pp. 1-22, https://doi.org/10.3390/informatics10010003, ISSN-2227-9709
• T. Karode and W. Werapun, "Robustness against fraudulent activities of a blockchain-based online review system", Peer-to-Peer Networking and Applications, Spinger Nature, IF (2020) 3.07, E-ISBN 1936-6450, P-ISBN 1936-6442, Vol 14, Issue 5, ISI Q2, 23 Aug 2021.
• T. Karode, W. Werapun, T. Arporntip, "Blockchain-based Global Travel Review Framework" The International Journal of Advanced Computer Science and Applications (IJACSA), Volume Il. No 8. pp. 90-99, August 2020 (ISI / Scopus Index).
• T. Karode, W. Werapun, "Performance Analysis of Trustworthy Online Review System using Blockchain". The 17th International Conference on Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology (ECTI-CON 2020), pp. 510-513, 24-27 June 2020.

Ittiwat Whangdee (UX/UI Designer)

Working experience:

• Currently working as a UX/UI Designer at Finstable Co., Ltd.,
• Mobile Developer at Bangkok Web Solution Co., Ltd.,

Competition:

• Joined the Autonomous world 2023 hackathon by ETHGlobal and built Muddy Heart, an On-chain action RPG game powered by @lattizexyz's MUD engine. https://ethglobal.com/showcase/muddy-heart-cdm0k

• Joined the BANGKOK BLOCKATHON 2023 by SCB10X ( APR 2023 ) and made 15 of the finalists team with the project BestEx: The Super Aggregator, BestEx searches for the best prices for your trade over DEX Aggregators and CEX, guaranteeing your best execution prices in trading. Pitch video link

• Joined SCALING ETHEREUM by ETHGlobal ( MARCH 2023 ) with the project ScalingTree: One repository for the world tree data. Social media for trees. (https://ethglobal.com/showcase/scalingtree-zida1) and got the prizes

  • Winner of The Graph - Best new subgraph(s)
  • Winner of Polybase - Pool Prize

• Joined FVM SPACE WARP by ETHGlobal ( FEB 2023 ) and got the prize

  • Winner of Filecoin & IPFS - FVM Jetpacks with the project Cretodus: A decentralized data marketplace where any users can upload any data they want to keep it on Filecoin network for data preserving.

https://ethglobal.com/showcase/cretodus-fga5u

Petch Luancharoen (UX/UI Designer, Inspex Point of Contact)

• UX/UI Designer at Inspex
• Former UX / UI Designer at DoDeep

What makes your Team best-suited to execute this Mission?

• Our team has developed Opti.domains, the first protocol utilizing EAS on the Optimism mainnet, as of the time of writing.
• Opti.domains has implemented social verification system utilizing EAS.
• We can advise the Optimism team on EAS schema and attestation design, ensuring optimal task accomplishment.
• Our team boasts a rich history of rapidly developing high-quality products. A notable example is Videfi, a fully functional decentralized video publishing platform we developed within two weeks during an ETHGlobal hackathon.
• Our alliance is the first to inquire about the project requirements.
• We have successfully completed most of the tasks associated with the "Specification for implementation, design approach, and architecture for the functionality listed above."
• Our alliance leader has experience developing Kaokonlakao, the largest running event in Thailand with more than 10,000 participants actively submitting their running progress to our system with a bunch of volunteer grading submitted progress. So, we have proven that we can handle the load of the RetroPGF 3 project discovery and voting system.
• Our alliance members have met together in multiple hackathons.

Professional level EAS experience

We have a long experience with EAS from the start. We have developed our Opti.domains smart contract and social verification backend integrated with EAS a few months ago and have developed a good relationship with EAS team in github discussion.

https://optimism-goerli.easscan.org/address/0xf01dd015bc442d872275a79b9cae84a6ff9b2a27

https://optimism-goerli-bedrock.easscan.org/

https://optimism-goerli-bedrock.easscan.org/address/0xf01Dd015Bc442d872275A79b9caE84A6ff9B2A27

We are the first ones who utilize EAS to attest social verification. It's quite complex but we have made it.

Try one yourself at https://town-testnet.opti.domains/

We have published the EAS SDK package for our internal migration process 3 days before the offical launch of EAS SDK.

Proof:

• Our EAS SDK - 1 August - https://www.npmjs.com/package/@optidomains/eas-sdk
• Official EAS SDK - 4 August - https://www.npmjs.com/package/@ethereum-attestation-service/eas-sdk

On 4 August, we have finished our migration process to have it compatible with latest EAS (Smart contract and social verification backend) in 3 days which is a very remarkable duration.

Not only EAS SDK but we can also deploy and customize the EAS indexer (https://github.com/ethereum-attestation-service/eas-indexing-service) ourselves. So, it won't be blocking if there are any problems in your EAS indexer because we can host it ourselves.

But in fact, we can use https://optimism.easscan.org/graphql public endpoint for basic attestation query

We also detect errors in the official optimism document regarding EAS and have opened a pull request

https://github.com/ethereum-optimism/community-hub/pull/853

This demonstrates our great understanding of EAS at a level that can advise you in the design of schema especially on social verification if you need it. Our intensive experience with EAS that significantly reduces development time and increase the quality of RetroPGF 3 Discovery & Voting development

High-quality and fast development

Our team has developed Videfi in 7 days and has a working decentralized video publishing platform prototype that won ETHGlobal HackFS 2023 ApeCoin — Best Contribution price

Core functionalities are working very well despite only 7 days of development.

Start from 11 June

Finish on 18 June

Live demo: https://bafybeie5exjjebz4rditcbqn7wdjlendhyvdbbkar63afbtvtg6gsjxli4.ipfs.sphn.link/ Github: https://github.com/Videfi/videfi-front ETH Global: https://ethglobal.com/showcase/videfi-nvth7

We understand that timeframe is short and our team is specially designed for this. We also select a tech stack that allows us to ship the best quality product in the shortest amount of time.

Experience with grant

We have experience with grants and have simulated the RetroPGF voting process in the previous RetroPGF 2 and a new proposed one. It's clear that RetroPGF 2 voting experience is horrible as badgeholders are required to copy their ballot to deform.

The new process solves this redundancy, however, assigning op for each project is still hard due to the reason explained in the Extra feature: Rubric-based list builder section below.

Please describe your proposed solution based on the above Solution Criteria:

We will strictly follow the wireframes and purpose some very useful features but we will implement them only if we have free time. As @JSeiferth stated, "timelines are pretty tight".

Core functionalities

We will develop core functionalities as listed in the requirements

Wallet connect

• Users can connect their wallet on the Optimism mainnet chain with Rainbowkit's industrial-grade wallet connect system.

Discover Projects

• Users can explore all nominated projects
• Users can search for a specific project by text
• Users can filter projects by categories
• Users can sort projects by name and others
• Users can view detailed information about a specific project including general information about the project (name, creator, profile picture, social media links, etc.) and specific information relevant to RetroPGF’s goal of aligning impact and profit (description of contributions, links to contributions, impact description, funding history, etc.).
• Users can easily view social media linked to each project

List system

• Any user can create a list
• Users can view all published lists
• Users can view details of each list
• Users can specify a list name
• Users can specify description and impact evaluation description
• Users can add projects to the list
• Users can assign OP amount to each project
• Users can fork list
• Users can update their list
• Users can delete their list
• Users have an easy user interface to view project information without switching to a new tab
• Users can choose to share their list publicly or kept private as a draft
• Shared list will have a link that can be shared to others
• Voting time remaining is shown to the user
• Project added and OP allocated progress bar is summarized
• Should show which list is forked form

Ballot system

• Only badgeholders can access ballot page
• Badgeholders can add projects to their ballot
• Badgeholders can assign OP amount to each project
• Badgeholders can import lists into their ballot and OP assigned will be calculated in a sensible way
• Badgeholders can reset the ballot to experiment with a different list formula
• Badgeholders must submit their ballot. A personal password is needed to submit the ballot.
• Badgeholders can load their submitted ballot by entering a correct password.
• Badgeholders can update their ballot. The latest one will be used.
• Badgeholders have an easy user interface to view project information without switching to a new tab
• Voting time remaining is shown to the badgeholder
• Project added and OP allocated progress bar is summarized

Extra feature: Rubric-based list builder

Note: we will implement this feature only if we have free time

Imagine a badgeholder who is faced with the challenging task of assigning the number of OP token to a project, this decision is influenced by multiple factors. The number of OP allocated to a project must consider various aspects, not only the impact of an individual project but also including the total number of projects and the relative earning of each project.

Assigning correctly in the first pass is nearly impossible, necessitating second, third, and subsequent passes to craft the perfect ballot.

In our opinion, we can utilize the grant council scoring system to assist badgeholders in independently scoring each project based on its impact, separate from other projects. Subsequently, we can employ these scores to calculate a perfect final list. However, it's essential to acknowledge that each badgeholder may possess their own impact evaluation metrics. Thus, we propose allowing badgeholders to design their individual metrics, while providing a base template for each category to ensure consistency.

Extra feature: Analytics dashboard

Note: we will implement this feature only after we have launched both two phases.

Analytics dashboard will be a place for Optimism foundation to view overall voting statistics (Need to enter username and password to enter).

Frontend

Framework

We propose employing Gatsby, an advanced, open-source framework that employs React and GraphQL. Gatsby excels at CMS development, aligning perfectly with the project discovery system's requirements. This proficiency is exemplified through an internal scraper that procures project information and images from EAS and IPFS, and subsequently caches it into numerous JSON metadata, images, and markdown files. This process is enabled by the non-overlapping nomination and voting periods in RetroPGF.

Among Gatsby's numerous advantages, the extensive plugin ecosystem is noteworthy. In this project, we aim to leverage gatsby-source-filesystem for reading cached markdown files, gatsby-transformer-remark for transforming these markdown files, and gatsby-plugin-sitemap for SEO-optimized sitemap creation.

Gatsby can also execute all operations required on our project discovery page. Gatsby's features are described comprehensively here. However, for the list and ballot systems, we plan to utilize simple API fetching usually done in traditional react development.

If real-time dynamic changes to the projects list are required, we will enable our scraper to push the updates to our frontend GitHub repository every time a new project is nominated. This action will trigger the build and deployment pipeline of our Cloudflare Page, ensuring that the latest changes are reflected and available to users within 5 minutes. We may try to use the client route as a fallback if one has entered that page before it was built. It will query our REST API and show the project detail instantly.

This approach facilitates a bifurcated development process for our frontend and EAS and IPFS-related scraper, with each section proceeding independently and in parallel. The frontend will be under the purview of our four developers with proven expertise in rapid, high-quality application development, while the scraper will be the responsibility of Chomtana, a solo developer from Opti.domains, known for pioneering EAS use in their projects and possessing extensive EAS experience.

Deployment

Gatsby compiles into a static site, thereby providing the flexibility to host it on any static site hosting service. We propose using Cloudflare Page, renowned for its 100% Uptime SLA and unlimited bandwidth.

With the Cloudflare Pro plan, we have the capacity to build 5000 times per month. In our design, we aim to build slightly more than the total number of nominated projects. Statistically, the total number of projects should not exceed 3000.

(Gatsby cloud is 2 times more expensive and may possibly create unnecessary stack bonding which greatly affects maintainability in the future. Cloudflare offers unlimited bandwidth and unlimited pages while gatsby cloud doesn't and only support 5000 pages. Cloudflare offers global CDN while gatsby cloud is limited to US and EU.)

Database

We plan to leverage MongoDB Atlas serverless along with comprehensive backup mechanisms, ensuring our data is hosted securely and has sufficient capacity for peak-hour demands.

Upon analysis, we found that the RetroPGF 3 listing and ballot systems favor a NoSQL document-based database as follows:

Projects

[
  {
    "name": "yyy",
    "description": "zzz",
    "walletAddress": "0x...",
    "website": "...",
    "teamType": "individual",
    "socials": {
      "twitter": "...",
      "github": "..."
    },
    "members": [
      {
        "walletAddress": "0x..."
      }
    ],
    "coverImage": "ipfs://...",
    "body": "... <Markdown> ..."
  }
]

Public keys

[
  {
    "username": "chom",
    "publicKey": "..."
  },
  {
    "username": "jseiferth",
    "publicKey": "..."
  }
]

A mapping between badgeholders, their ballots

[
  {
    "_id": "...",
    "walletAddress": "...",
    "signature": "...",
    "ballot": {
      "personal": "<Encrypted by badgeholder's personal key>",
      "chom": "<Encrypted by chom's key>",
      "jseiferth": "<Encrypted by JSeiferth's key>"
    }
  }
]

Lists along with owners, impact evaluations, and votes

[
  {
    "_id": "...",
    "walletAddress": "...",
    "signature": "...",
    "name": "...",
    "description": "...",
    "forkedFrom": "<List ID>",
    "list": [
      {
        "projectId": "...",
        "opAssigned": 72000,
        "comment": "",
        "evaluation": {

        }
      }
    ],
    "rubrics": [

    ]
  }
]

Furthermore, as ballot and vote-related elements frequently constitute an object array, NoSQL is the logical choice.

As per @JSeiferth indication, the task of calculating final results falls under the purview of the Optimism Foundation. Therefore, our responsibility lies solely in exporting raw ballot results to the foundation, thereby negating the necessity for relational data.

This strategy considerably reduces development time and cost by avoiding unnecessary complexity.

Backend

Our intent is to create a REST API using the Express.js (with TypeScript) framework. We will implement SIWE for Ethereum wallet sign-ins, Passport for social logins (if necessary), and Mongoose for MongoDB database communication. While GET endpoints will be publicly accessible, submission endpoints will be safeguarded through cookie-based UI restriction for security reasons. Having successfully integrated these elements in our Opti.domains project, we can assert the feasibility of swift development.

Project Discovery API

Our scraper will harvest project information from EAS and IPFS, cache it into multiple JSON metadata and markdown files, and subsequently serve these files through our REST API. This negates the need for reliance on the RPC server, IPFS, or EAS for stability or limitation concerns.

Having many people querying RPC or IPFS servers simultaneously will easily hit the rate limit of these providers and the UI will down. That's why we cache them.

The JSON metadata and markdown files will also be hosted in our open-source GitHub repository, enabling external developers or data analysts to immediately commence analysis without API data fetch requirements.

Voting and Listing API

Our Voting API is configured to feature REST API endpoints, querying lists, and individual ballots by wallet address and a given password. The Optimism Foundation team can retrieve all ballots by providing their username and password.

List and ballot submissions will be managed securely, with cookie-based authentication from the official frontend to prevent unauthorized submissions. Badgeholders will be prompted to enter their password for each ballot submission or update, thereby encrypting the data, ensuring accessibility only to the Optimism Foundation, excluding even the development team.

Shared infrastructure can also be made possible by having both sides open some kind of endpoint with each party holding a special token or private key.

EAS and IPFS scraper

EAS and IPFS scraper constantly poll nominated project attestation from EAS and then fetch contents and images from IPFS. This data is saved to two places: MongoDB and cached to Gatsby content. MongoDB is used to serve uncached content while Gatsby pages built with Cloudflare page will serve cached content.

Deployment

For backend API deployment, we propose utilizing AWS Fargate, a highly reliable PaaS solution from AWS that facilitates container management and auto-scaling. For optimization, we will consult an AWS expert.

Our EAS and IPFS scraper will be deployed to AWS EC2 because we require regular updates to our Git repositories. To ensure safety in case of any emergency situation, the EC2 image will be snapshotted. The scraper will be executed by a cron job event that runs every minute, ensuring timely and automated data collection.

Ballot data encryption

Encrypting ballot data in a way that it cannot be viewed by the development team involves using end-to-end encryption (E2EE). This method ensures that only authorized parties (in this case, the badgeholder and the Optimism Foundation) can decrypt and access the data. Here's a general outline of the process:

When a badgeholder submits a ballot, the application uses the public key of the Optimism Foundation to encrypt the data. The encryption process transforms the data into a format that can only be reverted to its original state (decrypted) using the corresponding private key. Each party will have separated encryption using a separate key.

Once encrypted, the ballot data is safely stored in our MongoDB database. The encrypted data, also known as ciphertext, is meaningless and unreadable to anyone intercepting it, including the development team.

This process ensures the confidentiality and security of the ballot data. It's important to note that the private key must be stored securely and never shared, as possession of this key allows for the decryption of the data. Therefore, the development team, lacking this private key, cannot access the raw ballot data, ensuring its privacy and integrity.

Our encryption mechanism can decrypt with one key so that the risk of losing the key will be minimal.

In the case that the Optimism Foundation team chooses not to hold the private keys, you can place your trust in us to hold them instead. We can discussion about who the key holders should be.

Audit, Bug Hunting and Feedback Competition

Chomtana, our Alliance lead, has a rich background with Code4rena, a reputable decentralized audit provider. Leveraging a competitive approach, Code4rena enhances the auditing process's efficiency. Chomtana has also partaken in Code4rena's inaugural UI bug-hunting competition.

With this knowledge and experience, we plan to conduct audits and bug-hunting competitions for our RetroPGF 3 project discovery and voting system. This strategy will ensure the delivery of a superior product, free from bugs and security vulnerabilities.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

We champion the agile methodology in product development due to the potential uncertainty of initial requirements. Feedback from project sponsor @JSeiferth, the Optimism team, and Badgeholders is instrumental in refining these requirements, thus aligning our product to optimally meet user needs.

To mitigate potential development delays due to unforeseen complications like an unfinalized EAS Schema or EAS bugs, we will develop the EAS and IPFS-related components in parallel with frontend development.

We will deploy our live development endpoints from the project start and open source our repositories

Project Implementation Specification, Design Approach, and Architecture

We have organized our teams into two distinct units: the Front & Back team, and the EAS team. These teams will operate concurrently to ensure expedient completion of the development tasks.

We are pleased to report that a significant portion of these tasks have already been completed.

Team Front & Back: Sprint 1: Frontend Hackathon

Development: 12 - 21 August 2023 Review: 22 - 25 August 2023

In this phase, our team will develop the frontend for both the 'Project Discovery' and the 'Voting UI' functionalities using mock-up data. This approach ensures no backend or scraper feature interactions are required at this stage.

Team Front & Back: Sprint 2: Backend Integration

Development: 26 August - 11 September 2023 Review: 12 - 15 September 2023

The second sprint will be dedicated to the development of backend API, database, and integration of the backend systems with the already developed frontend.

Team EAS: Sprint 1: Discuss EAS Schema with OP Team

12 - 21 August 2023

At this juncture, we have not yet received the necessary information about the EAS schema and their social verification schema from the OP team. To address this potential bottleneck, we have split our operations into two independent teams working in parallel. We anticipate receiving this information by the review phase of sprint 1.

Team EAS: Sprint 2: Development of EAS and IPFS Scraper

Development: 22 August 2023 - 11 September 2023 Review: 12 - 15 September 2023

This phase will involve the development of the EAS and the IPFS scraper. The latter is a cron job scheduled to run every minute. Its tasks include querying the EAS attestation, fetching content and images from IPFS, and transferring these assets to their respective repositories. This action will subsequently trigger the deployment pipeline.

Sprint 3: Testing, Bug Fixes and Additional Features

12 - 20 September 2023

Utilizing the feedback provided by the Optimism team, we will seek to improve our product through rigorous testing and bug fixing.

Should time allow, we will also undertake the development of an extra feature: the Rubric-based list builder.

Sprint 4: Project Discovery to Production

20 - 30 September 2023 (Must work together with Optimism Foundation and specialists from AWS and MongoDB if possible)

We will deploy a 'Project Discovery' only version to the production.

We will also deploy our 'Voting System' to UAT and perform load testing on our system.

Sprint 5: Audit, Bug Hunting and Feedback Competition

(Use UAT Environment)

23 September - 2 October 2023

We intend to conduct an audit, bug hunting and a feedback competition, with an open invitation to all, particularly badge holders, to participate. This endeavor aims to ensure an impeccable voting UI.

We commit to promptly addressing and rectifying any bugs reported during this phase.

Sprint 6: Production, Maintenance, and Support

Sprint 6.1: Deploy Voting UI to production

2 - 6 October 2023 but can be postponed up to foundation decision on voting launch date.

Our 'Project Discovery' and 'Voting System' will be deployed to production during this sprint.

Sprint 6.2: Maintenance, and Support

After voting UI launch

We will provide active maintenance via a robust alerting and monitoring system and offer support through our discord channel.

Provided we have adequate time, we may develop an additional extra feature: an Analytics Dashboard.

Sprint 7: Export Ballot Data and Long-Term Maintenance

After voting finish

During the final sprint, we will either export the ballot data or allow the Optimism Foundation, who hold the private key, to export the ballot data for the final RetroPGF 3 result.

We commit to providing long-term maintenance as stipulated in the project requirements.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

• Get feedback from the Optimism Foundation team on the agile Review phase
• Everything will be open source in an isolated GitHub organization for this project
• Successfully launch phase 1: Project discovery
  • Deploy to production on 25 - 30 September 2023
• Successfully launch phase 2: Voting
  • Deploy to UAT on 25 - 30 September 2023
  • Deploy to production on 10 - 14 October 2023
• Successfully export ballot results to the Optimism Foundation

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

We need to keep in touch with the Optimism team especially @JSeiferth, the project sponsor in our agile review phase.

It would be great if we can get feedback from badgeholders especially on our agile review phase.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:

Upfront Capital is not a barrier

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• [x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
• [x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• [x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
• [x] I confirm that I have read and understand the grant policies
• [x] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

[owocki]

Supermodular Foundation Mission Application

• Team Lead: Kevin Owocki
• Contact info: kevin@supermodular.xyz | Owocki#1337
• L2 recipient address: 0x00De4B13153673BCAE2616b67bf822500d325Fc3

Team members

• Kevin Owocki - Community Lead
• Carl Barrdahl - Engineering Lead
• Octavian Todirut - Design Lead
• Cristina Lare - Front End Engineer
• Carey Murdock - Ops & Admin

Previous Work

We are the team behind Supermodular, the venture studio that launched Gitcoin. We are focused on doing lean 0 to 1 build outs in the regen ecosystem.

• Gitcoin - which has funded $50m worth of ecosystem public goods. https://impact.gitcoin.co

A few other things we’ve built:

• PGN bridge - Bridge for the Public Goods Network (Op Stack L2)
  • https://bridge.publicgoods.network
• quadratic lenster - Quadratic tipping via quadratic funding rounds on Lens Protocol
  • https://gov.gitcoin.co/t/quadraticlenster-xyz-launch-wrap-up/15962
• funding.social - See who youre following on lens + who they contribute to on Gitcoin
  • https://funding.social
• Gitcoin Grants data visualizer
  • https://twitter.com/owocki/status/1658103631500161024
• Sybil-resistant faucet
  • https://twitter.com/owocki/status/1671581682925965312
• GiveGratitude - a tool for easily minting hypercerts
  • https://givegratitude.io
• QuadHoney - an experimental mobile Quadratic Voting webapp built for ETHDenver
  • https://qf-flash.vercel.app
• Our work is open-source: https://github.com/supermodularxyz

What makes your Alliance best-suited to execute this Mission?

We have deep & broad experience in web3 development and have built projects with similarities in these requirements (voting, dynamic forms, signatures). We're one of the only teams that has deployed web3 public goods funding software at the scale that Optimism RPGF requires ($50m of volume per https://impact.gitcoin.co/ + $10mm+ in RPGF via Optimism )

We also have previous knowledge of EAS with which we built:

• A way to attest grants projects owned by Zuzalu Citizens
• Off-chain ticket stubs stored stateless in QR codes

Additionally, we are deeply seated in the regen web3 ecosystem, having produced 150 podcast episodes on regen web3 and been involved in the production of several schelling point conferences.

Lastly, Did you know that Optimism and Gitcoin go way back? In the 2019 bear market, we received a grant from OP founders Jing/Karl's previous venture (plasma group), and we were kept alive by it. We <3 Optimism!

Please describe your proposed solution based on the above Solution Criteria (if applicable):

We build everything in public so progress can be followed on GitHub and the latest deployed build.

The choices of libraries and frameworks we use are based on:

• Battle-tested - used it large-scale production systems
• Great documentation - easy to learn and understand codebase and onboard devs
• Ecosystem - others have built on it and easy to find help and answers to questions
• Great developer experience - powerful and fun to build with

Suggested tech stack:

• Next.js
• Tailwind.css
• React Query - great declarative async state handler with caching
• Wagmi
• React Hook Form - performant form handling with schema validation
• Prisma
• Postgres or MySQL
• Vercel

Frontend

The frontend will query EAS Graph for projects using ReactQuery. Filters, sorting, and pagination will determine the query key so navigation and changes are swiftly updated correctly. IPFS is queried for additional data such as meta or application data. ReactQuery caches the responses based on query keys making it efficiant and only perform network requests when necessary.

The badgeholders can add projects to their voting list similar to a shopping cart. This is their voting scratchpad where they can allocate votes for each project. They can easily navigate between the input fields and see immediate feedback of the total tally. Badgeholders can share this list with others.

Wagmi is used to connect the badgeholders' wallet and to sign the voting ballot before sending it to the backend.

Backend

The backend receives the submitted ballot with the votes and a signed message. This signature is verified to make sure the badgeholder did in fact submit the ballot and ensure the authenticity.

The backend also stores the votes and lists, either as EAS attestations or in a private database in accordance to the requirements and user stories.

If it makes sense for this project, the backend will also handle user sessions with SIWE (Sign in with Ethereum). This way the user can sign a message to create a JWT session that is used to authenticate the user when submitting ballots and creating lists and submitting ballots. This also ensures the badgeholder can only vote once.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

1. Specification (1 week)
   • Read and understand provided user stories and designs
   • Define folder structure, components.
2. Set up project (1 day)
   • Create codebase
   • GitHub repo
   • Vercel deployment
3. Discover Projects (1 week)
   • Implement basic layout from provided designs
   • Fetch projects from supplied data source using React Query (filter, sorting, pagination)
   • Render each project based on selected view (grid or list)
   • Fetch project metadata from ipfs
   • Add/Remove to Voting List button
   • Implement tags filter, sorting, pagination
   • Implement designs and add empty, loading, and error states
4. Project Profile (1 week)
   • Implement basic layout from provided designs
   • Render project profile with metadata and application data
   • Add/Remove to Voting List button
   • Implement designs and loading skeletons
5. Discover List & voting on Lists (2 weeks)
   • Implement basic layout from provided designs
   • Fetch lists from supplied data source
   • Render each list
   • Fetch additional metadata if needed
   • Add list to ballot
   • Edit distribution
   • Implement designs and add empty, loading, and error states
6. Vote allocation and ballot submission (2 week)
   • Implement basic layout from provided designs
   • Build Vote allocation form
   • Implement filter and sorting
   • Calculate tally
   • Sign message
   • Send ballot and signature to backend
   • Implement designs and add empty, loading, and error states
7. Backend (1 week)
   • API endpoint to receive ballot and a signature
   • Verify signature
   • Store ballot in database
   • Create, update and read lists
   • Create attestations if necessary
8. Testing & QA (1 week)
   • Testing and bugfixing
   • Deployment to production
   • Add optimism.io domain

Milestone	Done by
Specification	2023-08-20
Set up project & deployment	2023-08-20
Discover Projects	2023-09-03
Project Profile	2023-09-10
Discover List & voting on Lists	2023-09-17
Vote allocation and ballot submission	2023-09-24
Backend	2023-09-24
Testing & QA	2023-10-01

Some of these milestones are done in parallel, for example ballot submission and backend as well as testing & QA which will run throughout the project.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

• We will create a public repository and deployment on August 20
• We will deploy Project Discovery 01 October 2023
• We will deploy Voting on 01 October 2023

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Check-ins every other week to do demos/get feedback.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:

We do not need upfront capital to do this.

---

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• [x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
• [x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
• [x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
• [x] I confirm that I have read and understand the grant policies
• [x] I understand that I will be expected to following the public grant reporting requirements outlined here

[Zeptimus]

Hey @JSeiferth,

What is the expected timeline for Applications for projects opening, Applications for projects closing, and voting beginning, and voting ending.

I understand the dates are not exactly predictable, but to have a great proposal, we would love at least a relative timeline, noting that it may change if need be.

[DanieleSalatti]

General Magic Foundation Mission (RFP) Application

• Alliance Lead: Daniele Salatti
• Contact info: Zeptimus will handle comms: @zeptimusq (Telegram)
• L2 recipient address: 0x248d6B056B103A96a0ac30d4E57Fd169ED00AD9c (retropgf-voting.generalmagic.eth)
• Please list the members of your Alliance and link to any previous work:

Team members

• @DanieleSalatti - Project Lead. Fractional CTO and Senior Software Engineer. With a rich history at Gitcoin, Meta, and Amazon, now leads v37, offering strategic tech insights to SMBs and startups. Github
• @amin__dev - Developer. More info: Github Software Engineer & Architecture Lead Developer at Giveth. Amin has been working on the Giveth DApp for 4 years, Leading the development team since 2020.
• @pourcheriki - Developer. More info: Github Lead Front-End Developer at Giveth. Cherik has been leading the front-end design on a variety of products and features in the Giveth Galaxy for the last 2 years.
• @markoprljic - Design lead. Head of Design and Business Developer at General Magic. “Magic Marko” is a top notch designer and has been practicing his art on web2 and web3 projects for over a decade.
• @mhmdksh - Devops. He's managing servers and working with devst to enhance processes, and automate deployment procedures.
• @ZeptimusQ - Comms. Transparency and accountability advocate. A passionate representative focused on decentralized governance.
• @thegrifft - Advisor. Co-founder of Giveth, Commons Stack, General Magic, Dappnode. Optimism Steward.
• @moe_nick - Advisor. Products & Fintech Enthusiast. PM for https://giveth.io, also PMing the Pairwise project ex-MyDigipay, ex-Tadbirpardaz, ex- Finnotech
• @aabugosh - Advisor. Head of Business Development & Growth at General Magic, Comms Contributor at Giveth / https://twitter.com/aabugosh
• @anamarie_com - Advisor. Marketing Lead at General Magic and RetroPGF community initiative.
• Various other members of the Giveth & General Magic community as needed. We will have a lot of administrative and community related tasks that will be managed by the core team and the support from our will be of great assistance.

What makes your Alliance best-suited to execute this Mission?

Our Alliance is uniquely positioned to execute this mission due to our extensive experience and proven track record.

• Years of Web3 Public Goods Experience: We have designed and developed Giveth, the longest running donation platform in the web3 space. Giveth has been fostering community and facilitating donations for public goods since 2018 and its current DApp has similar features such as project discovery, project pages, and voting on projects (via GIVpower).
• Diverse Application Experience: Besides Giveth we have worked on a wide variety of other projects across the space, including the Conviction Voting on Gitcoin, Gitcoin’s new Grants Stack and Allo Protocol, ENS Merch Shop, the TE Academy Fundamentals course, and the TEC Design Dashboard.
• Our RetroPGF Community Connections: We are uniquely positioned to execute on this proposal as we can easily coordinate with two teams already working on RetroPGF this round.
  • Pairwise is currently in active development, and we are excited to coordinate with that team to use their simple UX as a fun method to create standard lists. The team has been researching RetroPGF voting for the last several months and will be helpful in advising our work.
  • RetroPGF community marketing is well underway, we have been advocating and marketing the use of RetroPGF online via twitter and in IRL events during EthCC and ETHBarcelona. This project owns retropgf.com and we would plan to host the voting application there.
• RetroPGF Experience: Our team has participated in RetroPGF from every angle and we have all benefited greatly from it, and we want to give back! We have seen every side of RetroPGF and truly appreciate and understand the challenge.
  • Daniele had 2 grants in RetroPGF2 (delegation.tools and the DAppNode Optimism Package)
  • Giveth was a recipient of RetroPGF1 & 2
  • Griff was a badgeholder in the last round.

We are excited to apply our unique experience to become a part of one of the most important Public Goods experiments in web3.

Please describe your proposed solution based on the above Solution Criteria (if applicable)

We have deeply reviewed the solution criteria and want to include an optional feature set on top of the Solution Criteria to address some of the conclusions put forth in this fantastic article: RetroPGF2 Learnings & Reflections.

“Going forward, categories may also be used as a form of high-leverage voting, where a voter who doesn’t have expertise in a particular area could allocate funding to the overall category, which is then distributed pro-rata with other badgeholders’ votes. Overall, this is a dimension worthy of further exploration.”

“The most consistent feedback from badgeholders during the evaluation process was around the overwhelming quantity of projects to review.”

“Most [Badgeholders] tended to distribute their votes among 20-40 projects, with the median badgeholder allocating their votes among 30 projects.”

In our proposed solution, we aim to enhance the existing workflow by introducing a strong categorization system, leveraging the list feature to create distinct “categories”. These categories are intended to be static lists of 30-60 projects, which voters will use to choose an OP amount for each project. Our vision is to streamline the discovery process, enabling voters to focus on categories aligned with their expertise, thus making the process of decision-making more efficient and accessible. Moreover, this approach provides an option for voters to incorporate the expertise of the citizens they trust in areas beyond their knowledge.

To realize this vision, we are committed to creating an open, transparent process to classify the projects. We'll engage projects to collect additional data, publicly share all collected data, conduct community reviews of our categorizations, and actively collaborate with the Pairwise team to integrate with their application. Our focus on strong project categorization, combined with the effective integration of technology and community engagement, aims to enhance the overall user experience and the efficacy of the voting process but, most importantly, it is an optional, experimental flow that will not be required for the use of the application.

To break down the above further:

Categorization of Projects into “Categories”:

• We will create special categorized lists that we will call categories, and those will include multiple projects that have applied for RetroPGF. This will facilitate easier navigation and decision-making for voters.

Integration with Pairwise:

• We will collaborate with the Pairwise team to create specific categories for project lists. This will allow voters to submit their lists on the dapp we create or upload them directly from Pairwise. Our application will not depend on Pairwise's success but will integrate seamlessly with it if they succeed.
• We will work side-by-side with the Pairwise team to categorize the projects into categories, and validate those categorizations with the community.

Forking, Editing and Iterating on Lists:

• Voters will have the ability to fork other citizen’s lists and edit them according to their preferences. This will encourage diversity of thought and a more comprehensive evaluation of projects.
• We will show the providence of where each public list came from, e.g. “Vitalik’s Core Tech list (forked from Karl).
• We have a lot of experience with the community forking approach from the TEC Design Dashboard and are excited to share these lessons in this context.

Public or Private Submission of Lists:

• Citizens will have the option to submit their lists publicly or record and share their evaluations privately.
• Citizens will be able to create custom lists or use categories to submit lists publicly (or privately).

Vote Delegation with Category Percentages:

• Our solution will include a functionality that allows voters to add other citizens’ lists to their ballot while still being able to adjust the individual amounts for each project before submitting,
  • e.g. When Vitalik forks Karl’s ’s Core Tech list, he can adjust any of the OP amounts that he wishes and publish it publicly or save it privately before adding it to his ballot.
• Further we will allow each voter to adjust their OP distribution from a high level using categories. The voter will be able to see the percentage of OP that is being allocated to each category in their ballot and they can adjust that percent of the total OP being distributed.
  • e.g. When Vitalik is ready to submit his ballot, he can see what percentage of OP is distributed across every category and adjust a whole category’s OP amount by changing that percentage. If Core Tech had 10 projects, Project A= 2M OP, B=500k OP, C=300k OP, D=200k and E thru J = 0 OP, then this would mean that Core Tech has 10% of the total OP distribution. If Vitalik switches it to 15%, then Project A= 3M OP, B=750k OP, C=450k OP, D=300k and E thru J = 0 OP. Note: This is an optional feature for the voter, they are not required to do this to submit their ballot.

Community Feedback:

• We will actively seek feedback from the community regarding the categories, and that the DApp ensures that our solution remains relevant, user-friendly, and effective in achieving the goals of RetroPGF.

Admin view:

• Our solution will include an admin/operational dashboard that will allow the foundation to track the vote status and notify or send vote reminders to citizens.

Technical Overview:

• The DApp will be built on top of the Nextjs framework (React) and hosted at retropgf.com
• The DB server will be Postgres, hosted on AWS unless the OP foundation has a preference for a different provider
• The frontend will be hosted on Vercel, unless the OP foundation has a preference for a different provider
• A full CI/CD pipeline will be created
• Unless the OP Foundation has a preference for other tools, monitoring will be provided using a combination of DataDog and Sentry, and PagerDuty will be used for operational support and escalations.

In summary, our solution aims to incorporate even more of the learnings from RetroPGF to streamline the discovery and voting process. This will make voting intuitive, flexible, and more representative of the collective expertise of the citizens, improving the overall voting experience while still maintaining the desired workflow outlined in the solution criteria.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work

There are two distinct lines of work, the technical work and the categorization work

Technical work:

• Project Kickoff and Planning (1 day): We will begin with a project kickoff meeting to align our team with the mission's goals and requirements. This will be followed by a detailed planning phase where we will outline the project's scope, define roles and responsibilities, and establish key milestones and deadlines. It would be very helpful to have a Product owner from Optimism with us for this 2 hour call.
• Design and Architecture (1 week): During this phase, we will design the system architecture and user interface based on the provided designs and user stories. We will also formulate a specification for collecting and storing user-curated project lists and their impact evaluations.
• Development of Core Features (7 weeks): This phase will involve the development of core functionalities such as project discovery, user-curated project lists, and voting infrastructure. We will also construct a RESTful API or GraphQL backend that handles user operations and integrates with the RetroPGF Protocol APIs, IPFS, and Ethereum Attestation Service (EAS).
• Testing and Quality Assurance (2 weeks): We will conduct thorough testing of all features and functionalities to ensure they work as expected and provide a smooth user experience. This will include unit testing, integration testing, and user acceptance testing.
• Launch of Project Discovery Feature (During the QA phase): We will launch the project discovery feature, enabling users to explore all nominated projects and view project profiles.
• Launch of List Creation Feature (During the QA phase): Concurrently with the project discovery feature, we will launch the voting feature, allowing citizens to discover lists, and allocate and submit Ballots.
• Maintain, Support and Improve (Until March 2024): Post-launch, we will provide continuous maintenance and support, ensuring the application runs smoothly and any issues are promptly addressed. We will continue to work on this application expecting to be rewarded via RetroPGF.
• Feedback and Iteration (Ongoing): Throughout the project, we will actively seek feedback on the forums from the community and make necessary adjustments and improvements to our solution.

Categorization work:

• Project kickoff and planning (1 day): Same as above.
• Create and review a deform (3 days): This will be an optional form that projects can use to give us extra information that will help us categorize the projects.
• Distribute the categorization deform (Ongoing): We will reach out to projects to ensure they have an opportunity to help us group them in the best category until voting begins.
• Build an AI powered tool to help us categorize (2 weeks): There is a lot of information to parse. We experimented with vectorization of Giveth projects in a 40-dimensional space and were pleasantly surprised by the results. AI will be used to speed up the process, but the final results will require great human oversight.
• Publish initial categorization draft (3 business days after the close of applications): Once the application deadline has closed, we will add the final applicants into our data set and work nonstop to publish a first draft of categorization, groupings and titles.
• Rapid feedback and iterations (until the voting begins): We will work with the community to address feedback and concerns as they come up. It is important to set the category titles and the projects in each category before voting has begun, for the legitimacy of the process.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal

Here are the critical milestones that should be used to determine whether we've executed on this proposal:

Milestone 1: Specification Completion

• Overview: Finalize the system design and architecture based on the provided designs and user stories.
• Deliverable: Detailed system architecture and user interface design ready for public feedback.
• Expected Completion Date: 2023-08-20

Milestone 2: Development of Core Features

• Overview: Develop the core functionalities of the application, including project discovery, user-curated project lists, and voting infrastructure.
• Deliverable: Functional application with core features, integrated with RetroPGF Protocol APIs, IPFS, and Ethereum Attestation Service (EAS).
• Expected Completion Date: 2023-10-01

Milestone 3: Testing and Quality Assurance Completion

• Overview: Conduct comprehensive testing of all features and functionalities to ensure they work as expected and provide a smooth user experience.
• Deliverable: Fully tested application ready for launch.
• Expected Completion Date: 2023-10-01

Milestone 4: Launch of Project Discovery Feature

• Overview: Launch the project discovery feature, enabling users to explore all nominated projects and view project profiles.
• Deliverable: Live project discovery feature.
• Expected Completion Date: 2023-10-05

Milestone 5: Launch of Voting Feature

• Overview: Launch the voting feature, allowing citizens to discover and create lists, allocate OP, and submit Ballots.
• Deliverable: Live voting with list integration.
• Expected Completion Date: 2023-10-05

Milestone 6: Maintenance and Support

• Overview: Provide continuous maintenance and support, ensuring the application runs smoothly and any issues are promptly addressed.
• Deliverable: Ongoing application support and maintenance.
• Expected Completion Date: March 2024

Please list any additional support your team would require to execute this mission (financial, technical, etc.)

• Close Collaboration with the RetroPGF Team: We believe that working closely with the RetroPGF team would be invaluable for the successful execution of this mission. Their insights and feedback would help us better understand the specific needs and challenges of the RetroPGF process, allowing us to tailor our solution more effectively. Regular communication and collaboration with the team, especially early on, would ensure that our solution and design choices align with the vision and goals of the core team driving RetroPGF.
• Citizen Feedback: We would also appreciate the opportunity to gather feedback from several citizens. Their input would be beneficial in ensuring that our solution is user-friendly, intuitive, and meets the needs of the citizens.
• Tech Specs: We will need tech specifications and schemas for the entities, and the expected data that we will gather from their RetroPGF3 application by August 15th.
  • Support we would appreciate, though not required:
• Modifications to the project submission form that would help us categorize would save a lot of double work, even if these were optional.
  • We would love to add 2 questions, one open ended to get specific categorization data and one that simply asks “What other projects in the Optimism Ecosystem are similar to yours?”
• Access to project contact information will help us reach out in case we need extra information to better categorize each project.

---

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

• Access to upfront capital is not a barrier for us. However, a small upfront cash grant would benefit immediate project expenses. We understand this is not guaranteed.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.✔️
• I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant✔️
• I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual✔️
• I confirm that I have read and understand the grant policies✔️

I understand that I will be expected to follow the public grant reporting requirements outlined here ✔️

[e1Ru1o]

Foundation Mission (RFP) Application

• Alliance Lead: Lázaro Raúl
• Contact info: lazaro@nethermind.io | Telegram: @e1Ru1o
• L2 recipient address: 0xDD71EbF2B1ce923E3e231388a8a7cDba253485c1

• Please list the members of your Alliance and link to any previous work:

  Role	Team member
  Frontend	Jithin Kunnath
  Backend	Rachit Anand
  Full Stack	Yehia Tarek
  DevOps	Ryan Lin
  QA	Shashank Sanket
  Security Review	Murat Gunsay
  Project Manager	Dawid Zielinski

We work with ecosystem leaders, including Starkware, Lido, Obol, EigenLayer, Aave, and Flashbots.

• StarkWare: Juno, an open-sourced, full-node client implementation, and Voyager, a block explorer, are among our contributions to the Starknet ecosystem.
• Lido: Research to design a mechanism for a good validator set maintenance. We also run and manage an extensive network of validators for Lido.
• Obol: Specification for establishing Distributed Validators for Obol V2.
• EigenLayer: Restaking dashboard and AVS node specification.

What makes your Alliance best suited to execute this Mission?

• Nethermind is a world-class team of engineers and researchers with expertise in protocol engineering, layer two scaling, decentralized finance, smart contracts development, blockchain security and cryptography research.
• We actively participate in Ethereum's core development, decentralization, and sustainability through the Nethermind Execution Client. Moreover, we’re developing an op-Nethermind client, to support the OP-stack.
• Nethermind was a major recipient of the RPGF2 for the infrastructure category in the last round. As such, we understand the perspective of being a grantee and what could be improved to effectively showcase one’s work and establish successful communication between the grantee and badgeholders.
• One of our team members, Bobby Bola, was a token badge holder in RPGF2. This experience equipped him with valuable first-hand insights into the UX obstacles, where he identified areas with significant potential for improvement.

Please describe your proposed solution based on the above Solution Criteria (if applicable):

Technology Stack

1. Frontend:
   • Next.js for client/server-side rendering to handle extensive data.
   • React app with ChakraUI to leverage ready-made UI components that support all responsive designs by default for fast, high-quality delivery.
2. Backend:
   • Use Elasticsearch to filter the data collected.
   • Passport package for user authentication.
   • PostgreSQL database since we have well-defined needs and schemas.
   • AWS for hosting the platform.

Solution

The solution will mainly follow the provided specifications outlined in the RFP. Some specifics about our solution are as follows:

Authentication / Authorization:

• Users can be authenticated using their wallets.
  • During registration, users need to sign messages to prove ownership of their wallets.
  • They can use multiple wallets or social media accounts if there are attestations about them.

    Discover Projects & Lists

• To list all projects, our API will work as an aggregator between the data sources provided.
• To filter or search for a project, we will use Elasticsearch methods. Our API will be connected to the Ethereum Attestation service, Optimism indexers, and private database to provide accurate search results.

  Viewing a Project's Profile

• Project data will be cached using server rendering and updated periodically to achieve optimal speed.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Time	Plan
Week 1	Gather schemas & Indexer from Optimism and any extra details needed. Set up repositories, users authentication, design DB schema and connections required.
Week 2	Fetch projects & Lists data from EAS & IPFS. Write functionalities for querying data from the provided indexers. Elastic search features.
Week 3 & 4	Start with a React app for listing projects and list, and apply filters on them. CI/CD & Hosting Configuration.
Week 5 & 6	Add badgeholders voting functionalities to the app & connect with the database.
Week 7	Testing, Documentation, QA, Security review.
Week 8	MVP run with the Optimism team.

Delivery & continuous support is going to be provided as needed / requested during the RetroPGF round 3. We will request to create a dedicated support channel in the Optimism discord for badgeholders and community members using our application.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

1. Displaying and filtering Projects & Lists on the app.
2. Voting functionality.
3. Production-ready version & live app.
4. Documentation.
5. Reflection and communication on badgeholder feedback.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

• Providing on time / early, schemas & indexer, users stories, page designs, and hosting details will be desirable to avoid blockers given the above plan.
• An open communication channel with Jonas and the Optimism team for easy/quick discussions about voting technicalities.
• Support channel in Optimism Discord to have an open communication channel with Badgeholders.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

This would not be a barrier to us completing the mission.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

• [x]  I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
• [x]  I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant.
• [x]  I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual.
• [x]  I confirm that I have read and understand the grant policies.
• [x]  I understand that I will be expected to following the public grant reporting requirements outlined here.

[JSeiferth]

Submissions for this RFP are now closed. Thanks to everyone who submitted a proposal! You can find user stories and designs for the application linked. Note that these are not final.

Someone from the Optimism Foundation will reach out on or shortly after Aug 11 to communicate which proposal(s) have been accepted and schedule a kickoff.

In the meantime, feel free to tag me here or reach out directly (jonas@optimism.io) with any questions.

🚀

[Chomtana]

We have looked into your user stories and designs

I have seen that it's missing create, update, and delete list features. Where do lists come from?

Anything else looks good on our side.

===================================

We have seen an attestation schema closely related to the RetroPGF project

https://optimism-goerli-bedrock.easscan.org/schema/view/0xbb6c51e8228c22b994ac1a4e207ba099b6d05787b37b5a9ad19d0085efc2ce08

Don't sure if this schema is the one for the project discovery system

However, if this kind of schema is open to all we may experience spam (Attest random info) that affects the project discovery feature. We have a great idea for this problem if we get selected.

We have used EAS GraphQL to snapshot our Opti.domains OG role. This trick can be used in our EAS and IPFS scraper in the project discovery system.

[GriffGreen]

GM! We reviewed the designs and user stories, and they are fantastic! In fact, they fit perfectly with the General Magic proposal.

Our proposal adds the feature of categories to the application. It might sound like a deviation from the proposed work flow, but actually it is only a few small additions and one extra page to add incredible UX to the RetroPGF voting experience.

In this figma you can see the small changes that we would add to make this happen:

https://www.figma.com/file/ps9GcjKUznhys1327Y3n9u/RetroPGF-Voting-with-Categories?type=design&node-id=0%3A1&mode=design&t=h5BRD9ez6Ndlksb0-1

And in this video (click the link below) I walk through the figma to explain these changes. https://www.youtube.com/watch?v=YoXlB0-kAzs

In the end, the designs really don't have to change in any material way, and the category feature can be completely ignored if desired, so that the proposed workflow is maintained. However I think the category feature, along side the forking of lists, will enable experts to really dig deep into the categories they know best and delegate to the experts they trust to judge other categories.

Thank you for your consideration!

[JSeiferth]

Hi all – thanks for the excellent submissions and discussion! 🌞

The Optimism Foundation has selected Agora’s and Supermodular’s proposals to move forward with the work described in this RFP. That said, we're really excited about the amount of interest and expertise from everyone here!

To all the other teams that applied, we'd love to help you find the right way to contribute to the Optimism Collective! There are a couple of avenues to contribute to RetroPGF specifically:

• We published another RFP to build an application that allows badgeholders to create Lists

• There are a couple of Ecosystem Project Ideas on RetroPGF. These are not associated with an OP grant, but impactful work in this area is in scope to be rewarded in future rounds of RetroPGF.

• If you have an idea of what you’d like to build for RetroPGF, feel free to reach out to me and/or post about it in the forum

And stay tuned for more RFPs & Ecosystem Project Ideas to be posted in the next few months. Thank you again for your proposal!

[yitongzhang]

Thanks @JSeiferth for the update! It's been amazing to see some many incredible proposals, and we're very to have been chosen to work on this RFP. As with our other work, we'll be sharing progress on milestones in this thread on the following dates.

Milestone	Delivery Date
Lock in EAS schema and List architecture	August 18th, 2023
Design and release API schema	September 1st, 2023
Voting API launch	September 21st, 2023
Launch discovery of projects, profile & lists	October 6th, 2023
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

[carlbarrdahl]

Hey everyone, Excited to be part of this project! :rocket:

We have created a repo and set up deployment so you can follow our progress. https://github.com/supermodularxyz/OP-RetroPGF https://retro-pgf.vercel.app

[yitongzhang]

Hey everyone,

Just wanted to give a quick progress update here. Last week, Jonas helped lock in the EAS schemas, and we've started working with @carlbarrdahl and the Supermodular team to align on the API design. We're on track and expecting to release the API Schema around Sept 1st.

Milestone	Delivery Date	Status
Lock in EAS schema and List architecture	August 18th, 2023	✅
Design and release API schema	September 1st, 2023
Voting API launch	September 21st, 2023
Launch discovery of projects, profile & lists**	October 6th, 2023
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

[yitongzhang]

Hey everyone,

Chiming in with an update on our second milestone: we're sharing our API schema with the public here:

https://argoagora.notion.site/Retro-PGF-API-Spec-49912c0587844fef98a72e6251130618?pvs=4

Milestone	Delivery Date	Status
Lock in EAS schema and List architecture	August 18th, 2023	✅
Design and release API schema	September 1st, 2023	✅
Voting API launch	September 21st, 2023
Launch discovery of projects, profile & lists**	October 6th, 2023
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

[yitongzhang]

Hey folks, just chiming in here with a milestone update. We just shipped the voting API today. It's still in dev as we work through some kinks with the Supermodular team, who will be developing their frontend with this API. If you happen to poke around and find issues, please flag them to @stepandel or me .

Milestone	Delivery Date	Status
Lock in EAS schema and List architecture	August 18th, 2023	✅
Design and release API schema	September 1st, 2023	✅
Voting API launch	September 21st, 2023	✅
Launch discovery of projects, profile & lists**	October 6th, 2023
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

Coming up next: Launch EAS indexer API for projects and lists up on Sep 29 Launch discovery of projects, profile & lists on Oct 6

Links here:

Dev endpoint API Docs Github repo

[yitongzhang]

Hey folks, just chiming in here with a milestone update. We just shipped the Frontend for the discovery of projects, profile & lists. It's still a little rough around the edges, but will get rapidly tuned up over the next few days

Milestone	Delivery Date	Status
Lock in EAS schema and List architecture	August 18th, 2023	✅
Design and release API schema	September 1st, 2023	✅
Voting API launch	September 21st, 2023	✅
Launch discovery of projects, profile & lists	October 6th, 2023	✅
Full launch (full feature list with voting)	October 19th, 2023
Monitoring and support	Mid-October

Coming up next: Expecting lots of polish work as well as the full launch of the application early next week!

Links here:

See the frontend on dev

[Chomtana]

Hi, @yitongzhang can I use your GraphQL API to query RetroPGF3 projects?

[carlbarrdahl]

Here's an update. The UI is done and we're currently working on implementing the Agora backend.

Milestone	Done by	Status
Specification	2023-08-20	✅
Set up project & deployment	2023-08-20	✅
Discover Projects	2023-09-03	✅
Project Profile	2023-09-10	✅
Discover List & voting on Lists	2023-09-17	✅
Vote allocation and ballot submission	2023-09-24	✅
Backend	2023-09-24
Testing & QA	2023-10-01

You can try it out here: https://retro-pgf-staging.vercel.app

[stepandel]

Hi, @yitongzhang can I use your GraphQL API to query RetroPGF3 projects?

hey @Chomtana, yes you can! It's not in prod yet, but you can use our dev endpoint by now: https://optimism-agora-dev.agora-dev.workers.dev/graphql

Projects, lists and badgeholders are under retroPGF schema

[yitongzhang]

Hey folks, just chiming in here to say that we're working closely with the foundation on the final launch milestone. We've partially launched the relevant features for this stage of RPGF, and have the rest in a dev environment for testing with select badgeholders, and will launch upon the Foundation's go-ahead.

We consider these final milestone to be as complete as can be, and will come mark them as full complete after the conclusion of this round's voting.

Milestone	Delivery Date	Status
Lock in EAS schema and List architecture	August 18th, 2023	✅
Design and release API schema	September 1st, 2023	✅
Voting API launch	September 21st, 2023	✅
Launch discovery of projects, profile & lists	October 6th, 2023	✅
Full launch (full feature list with voting)	October 19th, 2023	⏳
Monitoring and support	Mid-October	⏳

[JSeiferth]

This RFP has been completed! ✨