Crowdsourcing useful verifiable data.
Delegate Mission Summary:
Crowdsourcing verifiable data about the constituent components of Web3 will significantly enhance discoverability and trust at the user interaction layer. This enhancement improves the Web3 customer experience by simplifying decision-making, making it easier for users to understand and engage with our extremely complex ecosystem. By offering users accessible, community-sourced insights, we will make Optimism the most user-friendly and easily navigable choice in this field.
S5 Intent: Intent 3 “Improve the Consumer Experience”
Proposing Delegate: TBD
Proposal Tier: Ember
Baseline grant amount: 300,000 OP total (maximum individual applicant grant size 125k OP, or 41% of the grant pool)
Should this Foundation Mission be fulfilled by one or multiple applicants: Up to 5 applicants, with the expectation that requested grant size will be in proportion to scope size.
Submit by: To be set by Grants Council
Selection by: To be set by Grants Council
Start date: To be set by applicant
Completion date: Before December 31, 2024
Specification
How Will this Delegate Mission Request help accomplish the above intent?
The ‘crowdsourcing useful verifiable data’ mission is a strategic initiative aimed at enriching the consumer experience within the web3 space. Achieving this will require multiple efforts working along side each other.
Some may choose to build ambitious protocol level primitives that empower developers and users by introducing generalized attestation and querying, while others may focus on more niche use-cases such as reputation features intended to enhance Optimism’s ‘Trust Tiers’. Folks may also build specific social applications or gamified platforms that encourage the collection and curation of verifiable data in the form of an open knowledge graph, such as which smart contracts are safe to interact with and which token contracts may be dangerous.
These aforementioned examples are designed to provide context to the mission and spark creativity, and are not designed to pigeon-hole developers into a handful of ideas.
What is required to execute this Delegate Mission Request?
The successful execution of this Delegate Mission Request requires a RFP selection process that can evaluate technical proposals. Moreover this Delegate Mission Request will need to attract technical teams with strong design fundamentals.
Below is a generalized list to consider should this Delegate Mission Request be lucky enough to receive RFP’s down the line. It should be understood that ‘crowdsourcing useful verifiable data’ can take many forms and responsibilities/deliverables should be adjusted proportionally. Generally speaking, we think it prudent to attract builders that have the ability to technically forecast and roadmap.
Listed responsibilities and/or expected deliverables:
Technical roadmap
• Design and publish a comprehensive technical roadmap that details the methodologies for crowdsourcing useful verifiable data. The roadmap should specify the types of data to be gathered (application features, social interactions, security, reputation metrics, etc). Additionally, the roadmap should illustrate understanding and application of a generalized product development lifecycle. The roadmap should encompass stages from initial concept development to final deployment, ensuring a structured and efficient progression of the project.
Smart contract design and development
• High level plans for how smart contracts will be used to verify information and how data will be stored.
• RFP’s should make it clear if they already have smart contract development resources or are planning to source development resources should they be accepted.
Smart contract audit & testing
• Builders whose contracts involve advanced logic, sensitive data, or financial operations should anticipate the need for contract audits. Furthermore, it is important to clarify whether a team has prior experience with such audits or if they will require guidance in this process.
• Pass at least one third party audit if deemed necessary.
• Deploy the contract(s) on Optimism.
Open developer API development and deployment
• RFPs should clearly outline the core features of their API that will be accessible to other developers. This includes providing details such as the programming languages in which the API will be available. Emphasizing these high-level functionalities is essential for effective communication and collaboration.
• Publish the API and accompanying developer documentation.
• RFP’s should make it clear if they already have API developer resources or are planning to source development resources should they be accepted.
End user GUI design, development, and deployment
• RFP’s should include a list of core end user features expected to be included in the GUI - wireframes are acceptable.
• Deploy and test end user GUI to ensure that functionality is reliable.
• RFP’s should make it clear if they already have design and development resources or are planning to source resources should they be accepted.
How should the Token House measure progress towards this Mission?
We hope to work closely with Token House to finalize how to measure progress toward this mission, and have summarized our proposed path forward below. Essentially, we suggest dividing the process into three distinct phases. Successful completion of each phase would unlock OP from the Delegate Mission Request pool.
Phase 1: Planning & Design (25% of total grant received)
This phase can be generally considered complete after the awarded RFP team provides:
• Product development roadmap, showing the milestones to be achieved between now and the product launch date.
• Low fidelity front end designs or wireframes.
• Backend infrastructure schematic.
• Mission memo, a 1 - 2 page written document that establishes the team’s north star to help with consistent internal decision making. The document may include a why, what, how breakdown for the product, a mission statement, and pervasive design and development ethos.
Phase 2: Development (50% of the total grant received)
This phase can be generally considered complete after the awarded RFP team provides:
• A staging environment to interact with frontend design.
• Operational smart contracts on testnet.
• API developer documentation along with functioning API.
Phase 3: Testing & Deploying (25% of the total grant received)
This phase can be generally considered complete after the awarded RFP team provides:
• 3rd party smart contract audit passing results (if applicable).
• Demonstrate internally developed successful tests for smart contract functionality.
• Deploy on mainnet.
How should badge-holders measure impact upon completion of this Mission?
Given that Intent #3 is centered on enhancing the consumer experience, we propose the use of metrics that specifically track consumer usage. This should include both developer and end-user engagement, as both groups are key consumers of useful verifiable data.
Developer Usage
• How many subsequent applications are using verifiable data infrastructure in their own application design?
• Has the introduction of crowdsourced useful verifiable data introduced new features and use cases to subsequent application developers?
End user usage:
• How much verifiable data has been crowdsourced?
• How many user wallets are submitting or verifying new data?
• How many user wallets are accessing/reading data?
• How many user wallets are interacting with applications that have integrated crowdsourced verifiable user data?