Delegate Mission Request: Building Identity - Driving Adoption of Attestations

[opjulian]

Delegate Mission Request: Building Identity - Driving Adoption of Attestations

Delegate Mission Request Summary:

Drive adoption of attestations within Optimism by creating an easy to use interface for Attestors. Attestations are the identity and reputation building block in Optimism both for projects and for individuals in the Collective, however their issuance is limited through code or leveraging the easscan site. Improving the End User experience can drive adoption of this primitive

S5 Intent 2: Intent 4 - Improve Governance Accessibility

Proposing Delegate: Brichis

Proposal Tier 8: Ember

Baseline grant amount: 36K (18K OP per applicant)

Should this Foundation Mission be fulfilled by one or multiple applicants: Multiple, up to two.

Start date: Two batches: One in March, a second one in May.

Completion date: 2-3 months after the applicants have been selected.

Apply Here

Specification

How will this Delegate Mission Request help accomplish the above Intent?
This Mission Request has the potential to fulfill two Intents. However, for budgetary purposes, it will be aligned with Intent 4.

Intent 4 - Improve Governance Accessibility:

• Enable contributors to the collective to have on chain proof of their impact
• Provide on-chain data to feed into evaluation of future RetroPGF Rounds
• Increase transparency in contributions and accountability for contributors and the Ecosystem
• Organizations and individuals are generating value for the Optimism Collective but much of the value generated by these actors is not trackable on-chain currently. During RetroPGF 3 we spoke about “on-chain metrics” 3 frequently but today it’s not really accessible for non-technical users.

Insights can be produced from the assessment of data points generated through these attestations. These insights about the strengths and weaknesses of the Optimism Collective can be used to inform governance decisions. Starting a robust feedback loop for fast and continuous improvement. For example, Badgeholders may use these data points to inform their allocation of RetroPGF, which addresses feedback provided by Badgeholders about having more on chain metrics for RetroPGF.

What is required to execute this Delegate Mission Request?

The applicant is expected to have an understanding of EAS . Previous experience integrating EAS is a plus.

Requirements:

• Specify tangible use cases this interface will address
• Enable Attestations to be issued in both OP Mainnet and OP Sepolia
• Include locks to enhance privacy and prevent the publishing of PID onchain
• Share proposed design and user flow in application (this should be evaluated by the Grants Council)

The expected deliverables are the following:

• Deliverable 1: Design of the user flow to be shared in the Governance forum for feedback.
• Deliverable 2: The creation of a user-friendly front end as a functional prototype.
• Deliverable 3: Awareness and adoption strategy
• Deliverable 4: Report on usage in the first month after deployment
• Deliverable 5: Report on learnings and suggested improvements

How should the Token House measure progress towards this Mission?

Bi-weekly updates in the governance forum, with the following table tracking milestones, titles, deliverables, due dates, and evidence of completion:

• Milestone 1: Completed front end design.
• Milestone 2: Complete execution of the awareness and adoption strategy
• Milestone 3: Successful usage of at least 30 issuers
• Milestone 4: A well documented Github repo that enables others to fork this front end and has a clear step by step on how this was put together.
• Milestone 5: Deliver an action plan on required upkeep of the repo and front-end so anyone can take it up if needed.

How should badgeholders measure impact upon completion of this Mission?

• Number of new attestations created on standard schemas.
• Number of new attestors who used the interface to attest
• Qualitative and quantitative data points to allocate RetroPGF.
• Metrics evolution for each of the schemas created.
• Quantitative and qualitative feedback on the ease of use of the interface.
• Number of frontend forks.