OP Passport | Design Document

I am excited to share with the new project we are working on called OP Passport. This initiative, funded by the OP Season 5 Builder Grant, aims to enhance the privacy, security, and active participation of governance on the Optimism.

Get Involved

We invite the Optimism community to review this design document and provide feedback. Your insights and suggestions will be invaluable in refining and improving the OP Passport project.

Your feedback is crucial to ensure we build a robust and effective platform that meets the needs of all governance participants. We look forward to your thoughts and suggestions!


  • Project Overview: The OP Passport project aims to develop an open-source platform for governance participants on Optimism, utilizing Zero-Knowledge Proof (ZKP) technology for privacy-preserving attestations and on-chain identity passports. The platform enhances privacy, security, and active participation of governance by enabling participants to issue and manage their on-chain identity passports.

  • Purpose of the Document: This design document outlines the framework, badge criteria, visual designs, attestation mechanisms, and integration of ZK technology, providing clear guidance for the development and implementation of the OP Passport system.

System Framework

  • Architecture Overview:

    • The system architecture includes the front-end web interface, back-end services, smart contracts, and a database for tracking user achievements and badge issuance. The architecture is designed to ensure privacy and security through the integration of ZK technology.
  • Core Components:

    • OP Passport Frontend: Web interface for users to interact with the platform.
    • Database: Storage for user data, badge issuance records, and attestations.
    • Back-End Service
      • Curia Indexer: Indexed data from on-chain and off-chain. This indexed data will be stored in the database for the criteria for each badge issuance record.
      • Issuer: The backend service that is responsible for issuing badges to users. It also acts as a relayer for anonymous attestation.
    • Smart Contracts: Blockchain-based contracts for badge minting, identity attributes, and ZK proofs.
      • Resolver: for validate on-chain criteria on endorsement attestation and verify proof & signature on anonymous attestation.
      • Smart Account: smart contract account as passport and act as identity layer for each user.
  • Integration Points:

    • OP Mainnet and OP Sepolia Testnet: Deployment environments for the platform. The lists of the contracts that OP Passport need to interact will be as follows:
      • OP Contract: for votes and delegates data
      • Gov Contract: for governance participation data
      • EAS Contract: to issue new attestation and retrieve existing attestation data (ex. Badgeholder information, etc.)
      • Alligator Contract: for partial delegation information.
      • EAS Schema Registry: to register new schema for OP Passport.
      • Account Factory: to create a new Smart Account for holding OP Passport and act as the identity layer for each user.
    • Governance Database: Integration for reliable data attestation and verification of governance activities.


  • Digital Passports:
    • Functionality for creating and managing digital identity passports.
    • Integration with on-chain identity attributes.
  • Badge Issuance:
    • Mechanism for issuing badges based on predefined criteria.
    • Smart contract integration for badge minting and management.
  • Public and Anonymous Attestations for Endorsement:
    • Options for users to create public or anonymous attestations.
    • Workflow for generating and verifying attestations.
  • User Dashboard:
    • Dashboard for users to view their badges, attestations, and passport status.
    • Analytics and insights on user participation and engagement.

Governance Participant Roles

  • Roles:
    • Delegates: Individuals who receive delegated voting power to participate in governance.
    • Delegators: Individuals who delegate their voting power to delegates.
    • Badgeholders: Members of the Optimism Citizens’ House who vote on the allocation of Retro Funding.


  • Criteria Definitions:
    • Delegate
      • Voting Power: based on the amount of OP controlled:
      • Top Voting Power Ranking:
      • Delegate Address Count: Reflect the breadth of trust
      • Voter Turnout/Participation Rate: Ensure active participation
      • Status: Encourage ongoing activity:
        • Active, Inactive, Ghost
      • Seasonal Participation: Recognize long-term contributors:
        • Badge for each season participated
      • Votes on Proposals: Reward frequent voters:
      • Delegate Expansion: Attracting New Delegator
      • Partial Delegation
        • Receive Partial delegation
    • Delegator Metrics:
      • Duration of Delegation: Reflect commitment:
      • Amount Delegated:Indicates the amount of voting power delegated.
      • Noted that some of the Delegate metric still applicable to Delegator metric since delegator is the one who delegate their voting power
    • Badgeholder:
      • Votes on Proposals: Reward frequent voters:
      • Round Participation: Recognize long-term contributors:
        • Badge for each Round participated
  • Badge Types:
    • Gaming-style, with progressive levels (3-5) based on achievement criteria.
  • Issuance Conditions:
    • Badges are issued by the Curia team each season. Data is collected at the season’s end to determine achievement levels for each metric.

Visual Designs

UI/UX Design

Attestation flow

Attestation Mechanisms

We support peer to peer message attestation with customized identity roles with realtime roles validity check through EAS resolver, our design is compatible with existing EAS mechanism.

  • Attestation Types:
    • Message attestation with customized identity roles
      • Badgeholders
      • Delegates
      • Delegators
  • Workflow:
    • Users submit attestation through our passport-frontend or directly through smart contract on Optimism at our EAS schema contract.
    • The EAS schema contract call role resolver contract.
    • The role resolver contract call customized role validity checker for each customized role
      • Badgeholders are identified by on-chain address registry which is also viewable and challengeable by third party
      • Delegates and Delegators are identified by OP token contract inside getVotes and delegates view functions
    • If the resolver returns true, then emit the attestation. The transaction is completed per user perspective.
    • Curia Indexer picks all attestations for the schema up.
    • The attestation can be viewed through our passport-frontend in both attester and attested address.
  • Schema Definitions:
    • The attester and attested are already included in EAS attestation info by default so we omit this in the data part.
    • {role: string, message: string}

Anonymous Attestation Mechanism

Anonymous Attestation Mechanism

In addition to normal attestation we also aim to support anonymous attestation in the same manner, in this case, peer to peer message attestation with customized identity roles. Anonymous in this case refers to instead of revealing attester we hide them instead while valid identity roles are still shown.

  • ZKP Overview:
    • To achieve this, we utilize a cryptographic primitive called zero knowledge proof, this allows us to hide some information while guaranteeing an enforced correct statement for such information. In this case, identity roles.
  • Chosen ZKP Protocols:
    • We choose UltraPlonk (zkSNARK) to be our ZK scheme and will be implemented using Noir (https://noir-lang.org/) due to ease of development, community support, and tooling.
  • Implementation Details And Workflow:
    • We came up with 2 possible variants of the anonymous attestation mechanism, each having different pros and cons. In the sense of user perspective, other workflows other than the ZK part would still be the same.

    • ZK Proof Generation

      • Curia Signature
        • Identity role proof is generated by verifying Curia signature. The signature and address verification is obtained off-chain from passport-frontend. Address verification process is done through either ECDSA signature verification (native signature), or EDDSA signature verification (derived signature from registered keypair, intended for AA account)
          • User request to do anonymous attestation to target address on some message
          • User send signature verifying their ownership of address to Curia through passport-frontend (signature can be ECDSA or registered EDDSA)
          • Curia gives back a signature that guarantees ownership of the address with the identity role. This signature is signed on address and identity role.
          • Calculate revoker using hash of address and signature
          • User generate ZK Proof that proof that
            • User know a valid Curia signature that sign on the specific address
            • Signature signed by that specific address on “CURIA_ANONYMOUS_ATTESTATION_V1” message is valid
            • Attestation message is attached in public input
            • Random nonce is attached in public input
            • Revoker hash (hash of revoker) is correctly calculated and is attached in public input
        • Pros:
          • Support real time role update
          • Infinite identity group (We can support arbitrary identity groups ex. Top 10 Delegate, etc.)
          • Very fast and not heavy computation dependent.
          • Curia also has zero knowledge to link which attestation has been done if the requested signature pool is large enough.
        • Cons
          • Rely on Curia infrastructure.
          • Building blocks are not designed to be composable.
      • Semaphore Group
        • Identity role proof is generated by verifying Semaphore group’s merkle tree inclusion of the address and the address ownership verification similar to Curia Signature method (ECDSA and EDDSA). The Semaphore group of each identity role is updated on-chain by Curia every 2-months interval (corresponding to Passport’s season).
          • User request to do anonymous attestation to target address on some message
          • User fetch all semaphore merkle tree leafs
          • User generates a signature verifying their ownership of the account.
          • Calculate revoker using hash of address and signature
          • User generate ZK Proof that proof that
            • User knows the merkle path from their address leaf to the root.
            • Signature signed by that specific address on “CURIA_ANONYMOUS_ATTESTATION_V1” message is valid
            • Attestation message is attached in public input
            • Random nonce is attached in public input
            • Revoker hash (hash of revoker) is correctly calculated and is attached in public input
        • Pros:
          • Very decentralized.
          • Proof and attestation transactions can be generated without interacting with Curia.
          • All addresses in each group are verifiable.
        • Cons:
          • Computationally and communicationally expensive.
          • Not real-time at all.
          • Group membership update is very costly due to the large membership size nature.
    • Then the proof is submitted to the relayer which the relayer then will call the “Curia Anonymous Attestation” contract. This contract will then verify the zk proof and call attestation function at EAS on behalf of the user.

    • Result of attestation would be “Curia Anonymous Attestation” contract attest to target address.

    • Anonymous attestation can be revoked by calling “Curia Anonymous Attestation” contract and providing uid of the attestation and preimage of “Revoker hash” submitted in the attestation. If the contract can correctly verify Revoker hash preimage, then the contract will call revoke at EAS on behalf of the user.

9. Smart Account Wallet:

The smart account wallet serves as a comprehensive digital repository, designed to securely store and manage each participant’s on-chain identity passport along with their related attestations, providing an accessible record of their governance roles, contributions, and achievements within the Optimism collective.

  • Smart Account Wallet Overview:
    • A smart contract wallet is a type of Ethereum account that is managed by a smart contract instead of an externally owned account (EOA) private key. They can have benefits like multi-signature capability, and can be customized to serve more specific use cases.
  • Chosen Smart Account Wallet
    • We chose Safe (CORE) to be our base implementation for our smart wallet account. Safe (CORE) is modular, battle-tested, and has been used by many projects. It also has great tooling and community support. We explored the Account Abstraction approach, but we think it may not be needed for the first version.
  • Implementation Details And Workflow:
    • Users create OP Passport from OP Passport frontend.
    • System will create new smart account, add user address to signer and register this smart account address to the system
    • System will create attestation and badge to this smart account address (and additional fields like ens, user EOA address for reference.)

Thanks for sharing this @v3naru_Curia ! Assuming this was discussed more in the original Mission Request, but can you share a bit more about how this differentiates from the function served by this page on your guys’ current dashboard: Delegate | Optimism Governance Dashboard by curiaLab.? After reviewing the designs, it appears the primary new feature is the ability to endorse a delegate; are we correct in that understanding? Additionally, if that is the case, how are you thinking about the flow/incentive to attract community members to endorse other members? Purely good will, or is there something else?

Thanks again for your guys’ great work. Looking forward to hearing more here.

1 Like

You’re doing a great job @v3naru_Curia and team!

I just have some questions that would be good to resolve and I would appreciate your comments.

  1. It is not very clear to me the main focus of the solution or the problem it would be solving, is it focused on building a reputation of delegates based on comments/feedback from voters? Or is it a way for voters to provide us with feedback on the proposals according to the voting period so that we can analyze and vote considering their feedback and building a reputation with the more people get involved in this process?.

  2. The other thing is, and following to @AnthiasLabs question, what would be the ways to attract more users to the platform? It is clear to me that there will be rewards for delegates, but for voters will they be given some incentive or is it the passport that will count too?.

  3. The Stamp Metrics are badges that are earned when you have more endorsements?, or under which parameters?, How it’s the dynamic to win it?. It is not very clear to me.

  4. It is quite clear to me about Zero Knowledge, I worked on a solution with that and it is a good strategy to maintain people’s anonymity. But what happens if some anonymous person writes unkind words to delegates? It would be good to have guidelines for conduct and respect.

  5. The attestations would be generated every time a voter generates an endorsement, and/or a revoke, a good use would also be to generate it as a stamp credential. (but first I would have to understand the dynamics of stamps metrics.:sweat_smile:)

I greatly appreciate your feedback and congratulations on this project!


1 Like

Thank you, @AnthiasLabs and @Liliop.eth, for your thoughtful questions and support! We appreciate your engagement and are happy to provide more details on the OP Passport project.

The OP Passport project is a separate initiative that utilizes the data infrastructure built for the Optimism Governance Dashboard. The primary new features include:

  1. Endorsement Mechanism: Beyond endorsing a delegate, OP Passport integrates Zero-Knowledge Proof (ZKP) technology for privacy-preserving on-chain attestations, offering a more secure and private way to endorse and verify roles and contributions without compromising anonymity.
  2. Digital Identity Passports: This feature allows users to manage their on-chain identity, which includes tracking governance participation and achievements through digital passports.
  3. Badge Issuance and Management: Users can earn badges based on predefined criteria, which are then securely managed through smart contracts.
  1. Reputation Building: The OP Passport project primarily focuses on building and maintaining the reputation of delegates through on-chain endorsements and attestations. Endorsements provide immediate social validation, while badges offer a long-term record of achievements and contributions that can support additional use cases, such as gated-attestation. This system encourages governance participation, transparency, and accountability.

  2. Building a Distributed Trust Network and Identity: It allows governance participants to validate and attest to the contributions of other participants. This mechanism is crucial for building an on-chain identity and a network of trust in the OP Collective and Web3 in general. By providing a verifiable record of each participant’s contributions and endorsements, it helps establish a more robust reputation system where users can trust the credentials and achievements attested on-chain by a network of other users. This, in turn, encourages more meaningful and trustworthy interactions within the community, reinforcing the integrity and effectiveness of the governance process.

  3. Privacy-Preserving Governance: The privacy aspect of the OP Passport project is specifically focused on anonymous attestations, ensuring that users can provide on-chain attestations without revealing their identity while still maintaining the integrity and validity of the endorsement/attestation.

Incentives and User Attraction:

  • Incentives for Participation:

    • Achievements for governance participants: Participants can earn badges and build their reputation through active governance participation, including endorsements and contributions to governance processes.
    • Gamification Elements: Introducing gamified elements such as levels and achievements to encourage active participation and endorsements.
    • Community Recognition and Other Rewards: We are exploring additional incentives to increase recognition within the community. Please share any ideas you might have on this.

Badge Parameters:

  • Badge As Achievement: Badges are earned based on a variety of parameters, including but not limited to voting participation, delegations, endorsements, and other seasonal contributions. For example:

    • Voting Participation: Frequency and consistency of participation in votes.
    • Endorsements: Number of endorsements received and given.
    • Voting Power: Number of voting power received via delegation

We will release more details on the badge criteria soon.

Thank you once again for your feedback and support. We are committed to building robust and providing effective governance tools with the OP Passport project and look forward to further discussions and improvements based on your insights!

Feel free to ask if you need further clarifications or have additional suggestions!

1 Like

Thanks for your answer!!
If you want to invite user testing, I’m happy to help. :smiling_face:

It’s great to see op passport products!
Hi,@v3naru_Curia, we are also working on an EAS based project, Fairsharing!

Fairsharing is a protocol for recording contributions on a chain to help record them more fairly, and is currently being used by over 30 organisations. We’ve recently been thinking about the next steps for the product, which also includes a lot of EAS modifications, and we’d love to talk to you about it. my telegram @marcuszheng

1 Like