Proposed Foundation Mission Request: Enable easy interoperation between Farcaster accounts and Ethereum Attestation Service, such that Farcaster accounts can effectively ‘issue’ attestations.

S5 Intent: Improve governance accessibility

Proposal Tier Ember

Baseline grant amount: 10k OP per solution for up to 2 solutions

Should this Foundation Mission be fulfilled by one or multiple teams: Up to two teams

**OP Labs or Optimism Foundation Sponsor: @C-Emily-Furlong *

Submit by: June 15th 2024

Selection by: June 30th 2024

Start date: June 30th 2024

Completion date: by August 30th 2024

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

This Mission Request calls for critical infrastructure enabling better compatibility between EAS Attestations and Farcaster accounts. Attestations are a critical piece of governance infrastructure and a core primitive of the OP Stack and will continue to remain a key building block of reputation within the Collective.

This Mission will enable the Collective to leverage Farcaster to improve governance accessibility while maintaining attestation compatibility and composability.

What is required to execute this Foundation Mission Request?

Problem statement

We want Farcaster accounts to more effectively and efficiently ‘issue’ attestations. Farcaster accounts have several connected Ethereum addresses. [Custody and recovery addresses](https://docs.farcaster.xyz/reference/contracts/reference/id-registry) are verifiable on-chain via the Id registry contracts and so-called ‘[verified addresses’ are only verifiable off-chain](https://docs.farcaster.xyz/reference/hubble/httpapi/verification). These address mappings can be changed over time by the user.

The holder of a Farcaster account may issue an attestation from one of the Ethereum addresses connected to their account, but for third parties to be sure that an attestation was issued by the person behind a Farcaster account, the Ethereum address must be connected to that account at the point in time that the attestation was issued. This connection must be verifiable on-chain for resolver contracts to be able to enforce it in the process of issuing attestations. Only custody and recovery addresses are verifiable on-chain, but users rarely have access to them to sign messages like attestations.

Use case

In the [Retroactive Public Goods Funding (Retro Funding) Round 4 sign-up experience](https://retrofunding.optimism.io/), users sign in with their Farcaster accounts, create projects and apply for Retro Funding. Projects are represented onchain as attestations, with the attestation UID acting as the project identifier to be used across future Retro Funding Rounds and Grant applications. The project attestation schema contains a ‘created by’ field, which references the Farcaster account id of the user who created the project.

Currently the attestation is issued by the sign-up app and attestation consumers must trust that the app correctly identified the user by their Farcaster id. The desired outcome is that users themselves are able to issue this project attestation, as well as other attestations about their projects, and third parties can read those attestations and trust that the project was indeed created by the holder of the Farcaster account. Third parties can further reference these attestations to add context to the impact of these projects and much more.

Suggested avenues to explore

In our exploration of this problem space, we have come across two ideas for solution avenues, which we think offer different trade-offs and would both be valuable additions to the EAS <> Farcaster tool set. It is up to the teams applying for this Mission to assess the viability of these ideas and suggest an appropriate technical architecture in their application. Alternative ideas for how to solve this problem are welcome.

Teams can apply to build one or multiple solutions, including suggesting solution ideas that are not listed below. The OP reward will be adjusted depending on the scope of the solution(s) proposed by teams.

Avenue 1

Attestations are issued by user action via their Ethereum account (EOA/smart account)
The Ethereum address is onchain verifiably associated with the user’s Farcaster account via a new onchain registry mapping Farcaster accounts to Ethereum accounts used for issuing attestations
This Ethereum address <> Farcaster relationship can be checked via a [resolver contract](https://docs.attest.org/docs/core--concepts/resolver-contracts).
The resolver contract enforces that the issuer’s Farcaster id is correctly entered into the attestation schema.

Solution requirements avenue 1

There is an easy way for Farcaster users to register an Ethereum address that they want to use for issuing attestations on behalf of their Farcaster account.
- It is easy for developers to integrate this step into their application, in case they want a user to issue an attestation but the user has not yet done this registration.
Anyone can create an attestation schema that enforces the following rules:
- Only those with a Farcaster account can issue attestations from this schema.
- Their Farcaster account id is correctly entered into the attestation metadata when they issue it (enforced via resolver contract)
Anyone consuming these kinds of attestations is able to trust that the Farcaster id given in the attestation metadata is the effective issuer of the attestation.

Avenue 2

Attestations are issued on behalf of a Farcaster user by an application that has an account key for the Farcaster user
The application issues the attestation, using the account key to generate a signature, which is included in the attestation metadata along with the Farcaster id of the user
The attestation schema includes a [resolver contract](https://docs.attest.org/docs/core--concepts/resolver-contracts) that is able to enforce that the signature corresponds to an account key registered to the Farcaster account included in the attestation metadata
Attestation consumers are able to verify whether the account key used to issue the attestation is still valid, or if it was revoked by the user

Solution requirements avenue 2

Any application with an account key for a Farcaster user can issue attestations on behalf of the user
They can use a schema with a new resolver contract to prove that they held an account key for the user at the time the attestation was issued
The Farcaster.id of the user is included in the attestation metadata so attestation consumers know on whose behalf the attestation was issued
Third parties consuming the attestations can trust that the attestations were issued by an application that (at the time of issuance) had an account key for the Farcaster user specified in the attestation metadata.
- They can also easily verify whether that account key is still valid

Definition of done

Anyone is permissionlessly able to create an EAS attestation schema that includes Farcaster id as a required field designed to represent the effective issuer of the attestation
Consumers of attestations from this schema can trust that the Farcaster id in the attestation effectively ‘issued’ the attestation, via either of these options:
- The application that issued the attestation had an account key for the Farcaster user
- The Ethereum account of the issuer was associated with the Farcaster account at the time of issuance
Provide a list of example schema UIDs being used that successfully create an attestation with a verifiable Farcaster id associated with it.

How should the Foundation measure progress toward this Mission Request?

Develop a plan and document it as an architecture diagram to be shared with the sponsor for feedback (1 week)
Develop a prototype / testable solution (2 weeks)
Release a production-grade solution that complies with the definition of done and applicable solution requirements above (4 weeks)

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

Number of attestation schemas created with the requirements described above
Number of attestations issued with the requirements described above

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. Submissions will be open until June 15, at which time the Foundation will review all submissions and select one or 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

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:

Foundation Mission (RFP) Application

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

This is a collaboration between RetroList and Opti.Domains team

RetroList has received 49k OP in RetroPGF 3

Opti.Domains has received 22k OP in RetroPGF 3

Alliance Lead: Chomtana Chanjaraswichai
Contact info: [email protected]
L2 recipient address: 0xD42A34E0B5cbBDCA9F23378546DA5EB0023fB738
Please list the members of your Alliance and link to any previous work:

Chomtana Chanjaraswichai - Team Lead, Core Developer

Johnny Phan - Protocol Engineer - Reviewing the feasibility of the solution and developing the backend integration

Poonpetch - UX / UI Designer - Design workflow and user experience

Chinapanda - Frontend Developer

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

We have built RetroList, the first and only Retro Funding 4 Discovery UI available so far. Our platform queries and indexes project data directly from the EAS, while others are still waiting for the Agora API to integrate real data. This showcases our expertise in EAS Attestation and have got retweets from Optimism.

Moreover, we have years of experience in the identity field, demonstrated through the development of Opti.Domains, which integrates social verification with EAS attestation. To date, we have completed over 10,000 attestations related to social and wallet verification linked to domains.

In the domain attestation, we use namehash as the primary identifier, similar to how Farcaster uses Farcaster ID for attestations. We have experience with this non-address-centric attestation system.

Furthermore, as a leading team developing Retro Funding discovery and community voting UI, we already have a high level of understanding of how this Farcaster attestation system can be used. This expertise enables us to cooperate more effectively with the Agora and Gitcoin teams.

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

We are looking to develop Avenue 1 solution

Attesting offchain farcaster wallet verification onchain

We will implement a system that queries off-chain wallet verification from the Hubble API and attests it on-chain through EAS with a resolver that automatically saves and indexes the Farcaster wallet verification status. This enables other contracts, applications, and resolvers to query this data to check if a Farcaster wallet has been verified.

Thanks to the OP Fjord upgrade, which implements "RIP-7212: Precompile for secp256r1 Curve Support," we can verify the Farcaster ED25519 signature on-chain.

We will provide an SDK and Wagmi hook for third-party applications to implement Farcaster attestation. This allows applications to check for wallet verification status and handle wallet verification attestation, so developers do not need to understand the underlying logic and can implement it easily.

Automated wallet verification attestation

We will provide an automated wallet verification attestation. Every time a wallet is verified, we will attest to the Farcaster wallet verification schema. Every time a wallet is revoked, we will revoke the on-chain attestation.

In case the automated wallet verification attestation isn't working, the SDK will automatically handle the situation by letting the user attest the wallet verification manually. The user experience will be similar to token approval, where the user needs to attest to the Farcaster-wallet connection once globally.

Attesting Farcaster Attestation

We will provide core contracts with examples for smart contract developers to easily develop and integrate Farcaster attestation resolvers. These resolvers will verify the Farcaster wallet connection before allowing the attestation to proceed.

Simple attestations that follow our recommended attestation standard can simply set our pre-deployed resolver as the default resolver while creating a schema.

Our SDK allows developers to build Farcaster attestation data with just a few lines of code. Additionally, it supports a Wagmi hook that enables developers to perform attestations with Farcaster in a streamlined manner.

We will also support or collaborate with Agora, Gitcoin, RetroList, and any team working on Farcaster attestations for Retro Funding use cases.

Recommended Attestation Standard

We recommend the following standard for Farcaster attestations to make them more useful and better organized.

NOTE: THIS IS OPTIONAL, OUR SOLUTION CAN WORK WITH ANY SCHEMA

Farcaster Recipient Namespace

Currently, the Retro Funding application attestation is not attested to a recipient. This prevents standard attestation indexers from efficiently indexing the attestation. For example, we can't easily query the EAS GraphQL API to find every project attested by @optidomains. Moreover, integration with guild.xyz is more difficult.

To address this, we introduce the address 0xfa...<Farcaster ID in hex> as a representative of the Farcaster account to be used as the recipient.

However, this is optional, and application developers can choose not to follow it if needed.

Farcaster ID as the First Field

The Farcaster ID should be the first field for seamless integration with our Farcaster attestation resolver SDK and for optimal indexing. However, if the Farcaster ID cannot be the first field, developers can manually decode the Farcaster ID and pass it to our Farcaster attestation resolver SDK during resolver development.

Developer Support Channel

We will host a developer support channel similar to the "Optimism Agora API beta" channel.

We will provide technical resources to TechNerd for answering Farcaster attestation-related questions on the developer forum and Discord. As a fellow TechNerd, I can easily coordinate with the rest of the TechNerd team.

Guild.xyz Support

We will coordinate and collaborate with Guild.xyz to implement support for Farcaster attestation. However, we can't guarantee success in this effort, and it is not a critical requirement, so we don't include it in the critical milestones.

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

Develop on-chain Farcaster wallet verification resolver - 14 July
Develop Farcaster attestation resolver core contracts and examples - 21 July
Develop Farcaster attestation SDK and Wagmi integration - 28 July
Conduct internal testing - 4 August
Support critical teams in integrating Farcaster attestation and fixing bugs - From 4 August onward

Critical teams are those that work on missions dependent on Farcaster attestation, including but not limited to the Retro Funding application and the voting UI development team.

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

The Farcaster wallet verification resolver is deployed and functioning
The Farcaster attestation resolver is developed
The Farcaster attestation SDK is developed
The critical teams have successfully integrated Farcaster attestation

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

Gas fee support on automated wallet verification attestation
Coordination with the OP Foundation
Coordination with the Farcaster and Warpcast teams
Coordination with the EAS team
Coordination with critical teams

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.)

Not a problem

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 --

Jun 11 '24 17:06 Chomtana

Foundation Mission (RFP) Application

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

Alliance Lead: LukeMa
Contact info:
- Email: [email protected]
- Github: lukema95
- L2 recipient address: 0x64637e33fb29fe6fdaf3e78515c805617ddc6188
Please list the members of your Alliance and link to any previous work:
- LukeMa: Experienced blockchain engineer, who has contributed code to several blockchain open source projects including Cosmos-SDK, IBC, ZetaChain, etc., here are some of his most recent open source projects:
- zhouop0: Experienced full stack engineer with 10+ years of web2 experience and several years of web3 experience

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

Extensive Expertise in Web3 Development: Our alliance boasts over three years of comprehensive experience in the Web3 sector, encompassing a broad spectrum of essential skills such as frontend and backend development, smart contract creation, and public blockchain development. This diverse skill set ensures that we are equipped to handle complex challenges across all layers of blockchain technology
Proven Track Record in Blockchain Innovation: We have actively contributed to the advancement of major blockchain ecosystems, including Sui, Cosmos, Ethereum, and ZetaChain. Our involvement has not only propelled these projects forward but also given us unique insights and a robust understanding of various blockchain architectures and consensus mechanisms.
Dedicated Involvement with Farcaster and Optimism: Our enthusiasm for innovative platforms like Farcaster and Optimism has led us to invest significant effort in understanding and contributing to these networks. Our proactive engagement demonstrates our commitment to supporting and enhancing these ecosystems, aligning perfectly with the mission’s goals.

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

We choose [Solution requirement avenue 1], users can issue Attestations through their own Ethereum account (EOA/ Smart Account)

Here are the main key components：

Smart Contracts: Mainly includes key contracts such as Schema and Resolver, which are the core components for users to issue Attestations.
SDK: Provided for application use, it can be directly integrated into the code to quickly register a wallet for Farcaster users, create schema, issue attestation, query attestation, and verify attestation, among other functions.
HTTP API Service: Another service provided for application use to register a wallet for Farcaster users, which can be deployed by anyone.
Front-end Demo: Contains full interactive features, users can use Farcaster login, register Ethereum address, and issue Attestation

Some Preliminary Ideas

The main processing flow is as follows:

Farcaster users or applications call the SDK(or HTTP API Service) to register Ethereum address.
- If users already have a wallet, they can use it to sign transactions and then call the SDK or HTTP service to send the transaction.
- If users do not have a wallet, they can call the SDK to first generate a wallet, then sign and send the transaction.
The process for Farcaster users who have already registered an Ethereum wallet to publish Attestations.

Key Design of Smart Contracts:

The following represents a conceptual design for the key contract and does not represent the final solution

Schema In the schema, the fid is used as the first field to identify the Farcaster account, while other fields can be customized according to business scenarios.

// General
schema {
	fid: uint256 // farcaster id
	// others field
	// ...
}

// Retro Funding 4
schema {
	fid: uint256 // farcaster id
	project_name: string
	project_url: string
	parent_project_ref_uid: uint256
}

Resolver Since the user's signature has already been validated in earlier steps, the Resolver only needs to check if the user's Fid matches the wallet's binding relationship.

contract ForcasterResolver is SchemaResolver {
    // ...
    IIdRegistry idRegistry; // farcaster IdRegistry
    function onAttest(Attestation calldata attestation, uint256 value) internal view override returns (bool) {
        uint256 fid = idRegistry.idOf(attestation.attester);
        require(fid != 0, "Fid does not exist");
        // decode fid from data
        uint256 _fid = abi.decode(attestation.data, （uint256）);
	      require(fid == _fid, "Does not match fid");
    }
}

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

Week 1: Preparation (30/06/2024 - 06/07/2024)

Design and discuss specific plans, and determine the final plan

Weeks 2 - 5: Code development (07/07/2024 - 03/08/2024)

Smart Contract Code Development
SDK Code Development
HTTP API Code Development
Demo Code Development

Weeks 6 - 7: Test & Docs (04/08/2024 - 10/08/2024)

Deploy the contract on multiple chains and conduct testing
Complete developer/user documentation writing and review

Week 8: Acceptance and feedback (11/08/2024 - 17/08/2024)

Gather feedback from key teams and the community, organize it, and make necessary improvements.

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:

A comprehensive SDK/HTTP API Service/Smart Contract that Farcaster users utilize to register Ethereum addresses and issue attestation, query attestation, and verify attestation.
An interactive front-end demo, including a complete interaction process that covers logging into a Farcaster account, registering an Ethereum address, and issuing an Attestation.
Comprehensive documentation, including processes for developers to integrate and users to interact.

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

Coordination with the OP Foundation

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.)

Not required

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](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types)
[x] I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833)
[x] 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 --

Jun 14 '24 06:06 lukema95

Foundation Mission (RFP) Application

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

Alliance Lead: LukeMa
Contact info:
- Email: [email protected]
- Github: lukema95
- L2 recipient address: 0x64637e33fb29fe6fdaf3e78515c805617ddc6188
Please list the members of your Alliance and link to any previous work:
- LukeMa: Experienced blockchain engineer, who has contributed code to several blockchain open source projects including Cosmos-SDK, IBC, ZetaChain, etc., here are some of his most recent open source projects:
- zhouop0: Experienced full stack engineer with 10+ years of web2 experience and several years of web3 experience

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

Extensive Expertise in Web3 Development: Our alliance boasts over three years of comprehensive experience in the Web3 sector, encompassing a broad spectrum of essential skills such as frontend and backend development, smart contract creation, and public blockchain development. This diverse skill set ensures that we are equipped to handle complex challenges across all layers of blockchain technology
Proven Track Record in Blockchain Innovation: We have actively contributed to the advancement of major blockchain ecosystems, including Sui, Cosmos, Ethereum, and ZetaChain. Our involvement has not only propelled these projects forward but also given us unique insights and a robust understanding of various blockchain architectures and consensus mechanisms.
Dedicated Involvement with Farcaster and Optimism: Our enthusiasm for innovative platforms like Farcaster and Optimism has led us to invest significant effort in understanding and contributing to these networks. Our proactive engagement demonstrates our commitment to supporting and enhancing these ecosystems, aligning perfectly with the mission’s goals.

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

We are looking to develop [Solution requirement avenue 2] which encompasses two key processes:

Farcaster User Registration Key - When Farcaster users link their application, the application generates a public-private key pair. The private key is stored on the application side, and the application utilizes Wrapcast's Signer Request API to add the program-generated key for the user.
Issuing Attestation for Farcaster Users - The application uses the private key generated in the previous step to sign the proof request data, then calls the EAS contract to issue the attestation for the user.

Key Components

Farcaster Login UI Component

We will develop a UI component for applications to log in to Farcaster accounts, which will be integrated into ReactJS and NextJS. This integration will allow applications to swiftly incorporate it into their frontend interfaces.

Farcaster/EAS Interaction SDK

We will develop a comprehensive TypeScript SDK for both frontend and backend use, which will later be expanded to other languages like Go and Rust. Its primary functionalities include registering application-side keys for Farcaster users, interacting with the EAS contract to issue proofs, creating schemas, and verifying users' proofs.

Schema Template Contract

We plan to develop a set of schema templates and instances suitable for issuing Farcaster proofs. The schema must contain the Farcaster user's fid and essential fields like the Farcaster account's Key. Here is an example:

// Retro Funding 4
schema {
	fid: uint256 // farcaster id
	key: string // key
	project_name: string
	project_url: string
	parent_project_ref_uid: uint256
}

Resolver Verification Contract

The Resolver contract is used to verify the validity of the attestation, ensuring they are authorized by legitimate Farcaster accounts. Since the attestation has already been verified as signed by a specific Farcaster account key, the Resolver only needs to confirm that this key matches the existing Farcaster account. Below is an implementation example.

contract ForcasterResolver is SchemaResolver {
    // ...
    KeyRegistry keyRegistry; // farcaster keyRegistry
    function onAttest(Attestation calldata attestation, uint256 value) internal view override returns (bool) {
        // decode fid from data
        (uint256 _fid, bytes key) = abi.decode(attestation.data, （uint256, bytes）);
        uint256 fid = keyRegister.keyDataOf(_fid, key);
        require(fid == _fid, "Does not match fid");   
    }
}

Comprehensive Developer Documentation

We will provide complete developer documentation and examples to enable developers to quickly integrate the attestation system into their applications. Week 1: Preparation (30/06/2024 - 06/07/2024)

Design and discuss specific plans, and determine the final plan

Weeks 2 - 5: Code development (07/07/2024 - 03/08/2024)

Development of the Farcaster frontend login component.
Development of the TypeScript SDK.
Development and deployment of core modules like Schema and Resolver contracts.

Weeks 6 - 7: Test & Docs (04/08/2024 - 10/08/2024)

Conduct extensive testing, including smart contracts, SDKs, and frontend UI components.
Compilation of developer documentation.

Week 8: Acceptance and feedback (11/08/2024 - 17/08/2024)

Gather feedback from key teams and the community, organize it, and make necessary improvements.

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

Completion of the Farcaster UI frontend login component development.
Completion of the TypeScript SDK for interaction with Farcaster/EAS.
Development and deployment of the Schema template example contract.
Development and deployment of the Resolver verification contract.
Completion of the development of developer documentation.

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

Coordination with the OP Foundation

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.)

Not required

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](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types)
[x] I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833)
[x] 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 --

Jun 14 '24 07:06 lukema95

Foundation Mission (RFP) Application

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

Alliance Lead: Alexander Balandin
Contact info: [email protected]
L2 recipient address: 0x76ef7734E8c5f84b62e3b8fAae6F4995bFea64AB
Please list the members of your Alliance and link to any previous work:

Marwan Aziz - Core engineer with 30+ years of web2 experience and several years of web3 experience:

https://www.devpost.com/software/fortunity : Was a member of a team that won the Truflation prize in the Chainlink Hackathon of 2022
https://salientyachts.com/ : Worked on the NFT and reward token contracts.
https://www.versafy.co/ : Worked on the DAO factory contract

Alexander Balandin - Full-Stack Engineer, ex Microsoft engineer with 7 years experience in IT and 2 years in Web3 development:

Optimist Dapp Rating System on Optimism
Onyx-SDK SDK for DID methods

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

Our team possesses extensive experience both as creators and consumers in the Web3 space. Our mission is to make Web3 more accessible and user-friendly for newcomers. We believe that enhancing the infrastructure for better compatibility between EAS Attestations and Farcaster accounts will significantly open the protocol for further development, fostering innovation on top of our solution.

As part of our expertise, we have worked extensively with EAS. For our final project in the Expert Solidity course, we built a decentralized application (Dapp) designed for users to rate and review other decentralized applications - Optimist. This project aimed to foster a community-driven reputation system, helping users make informed decisions about which Dapps to trust and use.

We are inspired by Chris Dixon's vision for decentralized social applications and have a deep understanding of Farcaster's mission and we are eager to contribute to its success.

Additionally, we are senior software developers with extensive experience in architecture and development. We believe our skills and dedication make us well-suited to contribute to this project and advance the Web3 ecosystem.

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

We are looking to develop Avenue 2 solution

Solution Proposal

Our solution involves building an application through which users interact with Farcaster contracts. The following outlines our approach:

User Interaction and Authentication

User Requirements: Users must have a valid Farcaster ID (fid) and a blockchain account. They will need to connect their wallet when interacting with the Farcaster contracts.
Authentication: Users authenticate with the application using Farcaster authentication mechanisms.

Fetching Farcaster ID

FID Retrieval: Once authenticated, we retrieve the user's Farcaster ID (fid) using their Farcaster username. We can do this by making a simple GET call to the following URL: https://fnames.farcaster.xyz/transfers?name=<farcaster_username> The response will be in JSON format. The fid will be stored in the "to" attribute.

Account Key Management

Creating and Revoking Account Keys: Users can create and revoke Farcaster Account keys through the application.
- Key Creation: We use the Farcaster "Key Gateway" contract to add new keys.
- Key Removal: We use the Farcaster "Key Registry" contract to remove keys. The same contract will also be used to query the keys of a Farcaster ID.

Attestation Process

Key Requirements: Creating a Farcaster Account key requires the user's authentication and a valid Farcaster ID.
Attestation Schema Requirements: The schema for attestations must include:
- Farcaster ID (fid)
- Farcaster Account key
Resolver Contract: The schema will be linked to a resolver contract that:
- Verifies the Farcaster Account key belongs to the provided Farcaster ID.
- Confirms the key status is "Added".
- Blocks attestation if the conditions are not met.

Verification by Third Parties

Attestation Record: By storing the Farcaster ID and Farcaster Account key in the attestation record, third parties can verify:
- Ownership of the Farcaster ID (and, by extension, the username).
- Validity of the key used at the time of attestation creation.

This approach ensures secure and verifiable attestations, enhancing trust and usability within the Farcaster ecosystem.

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

Step 1: Preparation (2024-06-30 - 2024-07-05)

Design and Planning: Finalize specific plans and design the system architecture. Determine resource allocation and timeline.

Step 2: Development (2024-07-06 - 2024-07-31)

Develop the Resolver Contract
Develop Sample Schemas that can be used for the Attestations.

Step 3: Testing and Documentation (2024-08-01 - 2024-08-31)

Internal Testing:
- Conduct extensive testing of the resolver contract.
- Address any bugs or issues found during testing to ensure reliability.
Developer Documentation:
- Compile comprehensive documentation for developers.
- Include examples, API references, and integration guides.

Step 4: Support (Starting 2024-09-01 and Ongoing)

Community and Developer Support:
- Set up support channels on Discord and Twitter.
- Provide ongoing support and updates to critical teams.
- Gather feedback from the community and incorporate improvements.

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

Development of Farcaster Attestation Resolver:
- Complete the core contracts for Farcaster attestations and ensure they are functional.
Development of Sample Schemas that can be used for the Attestations:
Successful Integration by Critical Teams:
- Critical teams have successfully integrated the Farcaster attestation functionality into their applications.

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

Coordination with the OP Foundation
Coordination with the Farcaster team

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.)

Not required

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 --

Jun 15 '24 01:06 Rainbow1nTheDark

Foundation Mission (RFP) Application

Alliance Lead: Nate
Contact info: [email protected]
L2 recipient address: 0xec2f2284C3bfA30B617aCA643E244815c9D48CeE
Members:
- Krish — full-stack development, SDK, Farcaster Frames GitHub | Warpcast | X (Twitter)
- Peter — full-stack development, smart contracts, EAS schemas GitHub | Warpcast | X (Twitter)
- Nate — technical documentation Warpcast | X (Twitter) | GitHub
- Ting — UX/UI, impact measurement Warpcast | X (Twitter) | GitHub | A universal icon: Asterisk for Attestations
Collaborative work on OTTP:
- Website
- Documentation
- GitHub
- Farcaster: Warpcast
- Community: Warpcast Channel
- Farcaster Frames:
- Lens: Hey
- X (Twitter)
- Zora Collections: OTTP is open | Is it onchain?

Why us? We're already building the solution on the Superchain.

Our team has already shipped tools for Farcaster-native EAS attestations with the goal of benefiting the entire Superchain ecosystem.

Open to the Public (OTTP) is an open collaboration protocol built on Base. It enables any person or organization to attest to any and all collaborations (work) onchain.

Farcaster and EAS:

Farcaster Frames:

We are Day 0 transaction frame builders and have been a part of the Farcaster builder community and bi-weekly dev calls. We are one of the first attestation frames.
Any Farcaster user can create an OTTP ID (OID)—linked to their Farcaster ID (FID)—which they own forever.
Attestation Frame: FID and connected wallet is used to make onchain attestations on EAS and create an OID in one transaction. Users can attest from a different connected wallet, and it’s linked to the same FID and OID.
Verification Frame: Tagged collaborators verify it as true by making onchain attestations.
Share Frame: Users share a frame showing their OTTP ID and basic metrics, such as number of collaborators and attestations made.

OTTP SDK:

SDK v1 929 downloads to date!
- User IDs
- Sign in with Farcaster
- Farcaster ID and EAS attestations
SDK v2 — contract completed, implementation in progress
- Organization IDs
- Objects (projects, proposals, milestones, etc.)
- Sign in with Ethereum address
- User and organization profiles

Basic Web Client:

[coming soon] This is a browser experience similar to the Farcaster Frame. View working prototype

Backdrop Build V3 and V4 Finalists:

Backdrop Build V4 project page
- V4 Finalist announcement
- V4 launch on Farcaster)
Backdrop Build V3 project page
- V3 Finalist announcement
- V3 launch on Farcaster

Gitcoin Grants 20:

OSS Web3 Infrastructure Round: 599 people helped us raise ~$2K, plus ~$4K match. View project page

Proposed solution:

Key Components:

Smart contract: secure contract-level verification of FID and connected Ethereum addresses
SDK: easy implementation
Basic web client: integration demo to use or fork
Graph: interoperable graph of user profiles, organization profiles, project pages, proposals, and more

The RFP goal is to provide assurances that the wallet issuing the EAS attestation for a project page is connected to a given Farcaster ID. We’re doing this and more.

We would like to see a world where a project attestation is not only verifiably linked to social profiles (like Farcaster and Lens) but also grants they have received from Gitcoin, Optimism, hackathons, accelerators, etc.

And even further, we want to enable use of the same project page across multiple clients, such as Gitcoin and Optimism.

ottp-diagram

We are building OTTP for everyone on the Superchain and for many use cases related to collaboration. But in the use case described in the RFP, project attestations created by a user (or an organization) would be linked to their OTTP ID and connected to any social accounts, previous projects or contributions. A project page could be repurposed anywhere and connected to anything else on the open protocol. Anything related to work/collaboration that can be proven onchain, provably connected together through the OTTP ID into a collaboration graph.

For this RFP, we will focus our efforts on strengthening the connection between Farcaster accounts and EAS attestations, including validation at the contract level.

Detailed Flow:

Sign in:
- The user signs in to the app with their Ethereum address, which is connected to their OTTP ID.
Link Farcaster Account:
- The user indicates they want to link their Farcaster account with OTTP.
Generate Signature in Farcaster:
- The app directs the user to a secure location within Farcaster where they can generate a signature using their Farcaster custody address. Note: This can be done through a secure frame within the Farcaster interface.
- Steps in Farcaster:
  - The user generates a signature using their Farcaster custody address.
  - Farcaster provides a text string containing the signature.
  - The user copies this text string.
Return to the App:
- The user navigates back to the app.
- The app prompts the user to input the copied text (signature).
Verification:
- The app verifies the signature: It checks that the signature was generated by the custody address associated with the Farcaster ID.
- Once verified, the app creates an onchain attestation linking the Farcaster account to the user's Ethereum address.
Create a Record:
- The app initiates a transaction to record this attestation onchain.
- The attestation may include an expiration date, allowing the wallet to continue making attestations using a resolver contract with the linked Farcaster address.
Session and Ongoing Verification:
- The smart contract creates a session for the user, allowing them to make further calls without needing reverification for a set period.
- During this session, the contract continuously verifies that the address making calls is still associated with the Farcaster ID.

View overall OTTP user flow

Step-by-step plan and expected deadlines:

Milestone 1 - July 5: Successful Integration of Farcaster Action
- Description: The Farcaster action (likely a Frame) for generating signatures is fully developed and integrated into the Farcaster platform.
- Criteria:
  - Users can initiate the action within Farcaster.
  - The action correctly communicates with the user's Ethereum address.
  - The action generates a valid Ethereum signature using the user's Farcaster custody address.
  - The action provides a clear and user-friendly way for the user to copy the signature.
Milestone 2 - July 10: Signature Verification and Attestation Creation
- Description: The backend of our app is able to verify the signature received from Farcaster and create the onchain attestation linking the Farcaster ID with the user's OTTP-connected Ethereum address.
- Criteria:
  - The app successfully receives and validates the signature from Farcaster.
  - The app creates a valid onchain attestation that includes:
  - The user's Farcaster ID
  - The user's OTTP-connected Ethereum address
Milestone 3 - July 12: Resolver Contract Deployment and Functionality
- Description: A resolver contract is deployed on the blockchain and functions correctly to verify the link between Farcaster IDs and Ethereum addresses.
- Criteria:
  - The resolver contract is deployed to the appropriate Ethereum network (e.g., Optimism).
  - The resolver contract correctly responds to queries about linked Farcaster IDs and Ethereum addresses.
Milestone 4 - July 26: End-to-End User Flow Testing, Using Basic Web Client
- Description: The entire process, from initiating the Farcaster action to the creation of the onchain attestation, is thoroughly tested with real users using the web client.
- Criteria:
  - Users can successfully complete the entire flow without encountering errors or issues.

Notes:

The implementation procedure may vary as we build.
Include a week buffer for each of the milestone dates.

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

None required but would be helpful:

Smart contract review and security audits
Feedback on protocol design for optimal interoperability with the Superchain

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.)

None.

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 --

Jun 16 '24 04:06 nathansvan

@lukema95 @Rainbow1nTheDark @nathansvan @Chomtana

The team at Lighthouse (lighthouse.cx) are very interested in this request as something we would like to implement in our product. We don't have enough resources at the moment to submit our own application for the grant, but we would like to offer to work together with the other teams to build a real-world implementation of their proposed solutions:

Lighthouse can act as a RW attester using your proposed system.
We will attest that a verified address from a Farcaster user was also a token holder at the time of attestation.
This will enable us to prove that when a comment is made via Farcaster on an Optimism proposal, they were a token holder at the time the comment was made.

We invite the teams who win this grant to work with us to test out their solutions with real users and a real-world use case, as a way of dogfooding the results of their work. If anyone would like to discuss this more, please contact myself or @1a35e1. Good luck!

Jun 17 '24 22:06 jmacwhyte

Thank you to all the builders who submitted applications for this project! @Chomtana 's alliance has been selected to carry out this Mission Request.

@Chomtana I will be in touch directly with further instructions

For all the other builders, thanks so much for taking the time to apply 🙏 you can find other ways to get involved via contribute.optimism.io

We also have another open mission request related to attestations here

Jun 18 '24 14:06 C-Emily-Furlong

This is lit

Jun 19 '24 00:06 zacharytyhacz

Hey everyone,

I have spent some time looking at the second solution and here are some of my thoughts:

Goal

First, let me restate the goal as I understood it: allow Connected apps to issue on-chain attestations on behalf of their users, verifiably linking these attestations to their users' Farcaster identities.

When an attestation is issued, it must adhere to the attestation schema. This attestation schema can reference a resolver contract that basically would check if the signature corresponds to a valid account key for the specified Farcaster ID against the Farcaster key registry.

This is basically good because everyone can then trust that an attestation issued by app XXX on behalf of user YYY is actually 'valid' because the app had been granted permission from the user to act on their behalf.

Solution

In terms of Solution (and challenges), this is how I view it:

Step 1: Issuing attestations

A connected app can request an app key from a wallet app (warpcast) - it's called the Farcaster Signer Request process if I am not mistaken.

Each connected app basically generates an Ed25519 key pair which is then approved for use with the user's Farcaster account. This key pair is distinct from the user's main/custody Farcaster wallet.

Theoretically, this key pair could be used for other purposes beyond just posting offchain messages on Farcaster. This flow is described here in the doc: https://docs.farcaster.xyz/reference/warpcast/signer-requests

I believe this was originally designed to allow Connected Apps (e.g. Supercast/Yup/etc) to take offchain actions on Farcaster like writing casts, following accounts and browsing. But I don't think it prevents them from actually doing other stuff (like issuing an attestation, minting an NFT, etc) on behalf of their users. I guess it just needs to be made very clear to the user what the connected app will do on their behalf.

The biggest challenges I see here are:

Using the key for non-Farcaster actions might violate user expectations
There are few connected Apps right now and they all focus on Farcaster (casting, etc). So I am not sure if many would use this solution
We might need additional user consent mechanisms if using the key for actions beyond Farcaster's typical use cases.

Step 2: On-chain verification

To verify the link between the attestation and the Farcaster identity of a user, we need a resolver contract.

This contract would need to verify the Farcaster key against the on-chain Key Registry.

The big challenge here is that Querying the Key Registry is extremely gas-intensive. The Farcaster documentation explicitly warns against calling it on-chain from other contracts due to potential block gas limit issues.

Each time the resolver contract is called, it would need to check with the key registry (1) the Farcaster ed25519 signature against the account keys for the farcaster ID of the user on behalf of which the attestation was issued AND (2) the status of the key (whether it's revoked or not).

(1) is apparently possible thanks to the latest OP Fjord upgrade. The challenge is still that the resolver contract needs to interact with the Key Registry for each verification and this might be prohibitively expensive in terms of gas. And moving the check offchain isn't easy because we still need a way for the resolver contract to call that offchain "verification" service.

I'd really appreciate any thoughts or suggestions on how we might address these challenges or explore different approaches.

Cheers, Maxime

Aug 08 '24 12:08 Maxservais

I'm posting a status update here for transparency. This work is currently being audited

Feb 07 '25 15:02 C-Emily-Furlong

... Completion date: by August 30th 2024 ...

I completely forgot about this

Feb 08 '25 18:02 zacharytyhacz

0x2D815240A61731c75Fa01b2793E1D3eD09F289d0

Sep 08 '25 06:09 must479

ecosystem-contributions ecosystem-contributions copied to clipboard

Foundation Mission Request - Farcaster Attestations [IDENTITY]

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

What is required to execute this Foundation Mission Request?

Problem statement

Use case

Suggested avenues to explore

Avenue 1

Avenue 2

Definition of done

How should the Foundation measure progress toward this Mission Request?

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

Application instructions

Foundation Mission (RFP) Application

Foundation Mission (RFP) Application

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

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

Attesting offchain farcaster wallet verification onchain

Automated wallet verification attestation

Attesting Farcaster Attestation

Recommended Attestation Standard

Farcaster Recipient Namespace

Farcaster ID as the First Field

Developer Support Channel

Guild.xyz Support

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) 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:

Foundation Mission (RFP) Application

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.)

Foundation Mission (RFP) Application

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

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

Key Components

Please define the critical milestone(s) 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.)

Foundation Mission (RFP) Application

Solution Proposal

User Interaction and Authentication

Fetching Farcaster ID

Account Key Management

Attestation Process

Verification by Third Parties

Foundation Mission (RFP) Application

Why us? We're already building the solution on the Superchain.

Farcaster and EAS:

Backdrop Build V3 and V4 Finalists:

Gitcoin Grants 20:

Proposed solution:

Step-by-step plan and expected deadlines:

Goal

Solution

Step 1: Issuing attestations

Step 2: On-chain verification

ecosystem-contributions
ecosystem-contributions copied to clipboard