# Introduction
## Project Overview The OP Passport project, funded by the OP Season 5 Builder Grant, aims to develop an open-source platform for governance participants on Optimism. By leveraging Optimism Governance data for secure, private on-chain endorsements using Zero-Knowledge Proof (ZKP) technology and the Ethereum Attestation Service (EAS). ## Purpose of the Document This design document outlines the framework, badge criteria, visual designs, attestation mechanisms, and integration of ZK technology. It provides clear guidance for the development and implementation of the OP Passport system. ## Get Involved We invite the Optimism community to review this document and provide feedback. Your insights and suggestions are invaluable for refining and improving the OP Passport project. Your feedback is crucial to ensuring we build a robust and effective platform that meets the needs of all governance participants. # Why OP passport? ## **Enhancing Privacy and Security** **Privacy-Preserving Attestations**: Our platform utilizes Zero-Knowledge Proof (ZKP) technology, allowing participants to issue governance-related attestations without revealing their identities, ensuring robust privacy. **Secure Identity Management**: Smart account wallets enable participants to securely manage their on-chain identity passports, minimizing risks of identity theft and fraud in the governance process. ## **Empowering Governance Participants** **Role Verification and Transparency**: Participants, including Delegates, Delegators, and Badgeholders, can issue and manage attestations that verify their roles, enhancing transparency and trust within the ecosystem. **User-Friendly Interface**: Our platform features an intuitive UI, making it accessible for participants of all technical backgrounds to manage their attestations and identities effectively. ## **Driving Ecosystem Growth and Engagement** **Ecosystem Expansion**: The deployment of identity, attestation, and ZK primitives on the OP Mainnet promotes ecosystem growth by encouraging active participation. **Builder Engagement and Interoperability**: The platform supports seamless integration of on-chain passports and attestations across various applications, attracting builders and expanding the utility and relevance of on-chain identities. ## **Commitment to Decentralized Governance** **Advancing Governance**: Our project aims to advance decentralized governance by providing secure, privacy-focused tools that promote active participation. **Broader Applications**: The innovative use of ZKP and secure identity mechanisms paves the way for high-stakes governance applications, transforming the governance landscape and setting new standards for privacy and security in decentralized systems. # Passport The Digital Passport functionality allows for the creation and management of digital identity passports, empowering users to issue their own on-chain identity passports using smart account wallets. These digital passports act as a comprehensive record of each participant's governance roles, contributions, and achievements within the Optimism ecosystem. ## **My Passport** "My Passport" is a feature that showcases detailed profile information about governance participants, including delegates, delegators, and badgeholders. This section provides a clear and concise overview of each participant's involvement and status within the governance framework.
**Role:** Displays the participant's role as a Delegate, Delegator, or Badgeholder. **Since:** The date when the user first joined the governance platform. **Voting Power:** The amount of voting power controlled by the delegate, reflecting their influence in governance decisions. **Delegated Token:** The total number of tokens delegated to the participant, indicating the trust placed in them by the community. **Partial Delegate:** Information about any partial delegations received, highlighting the granularity of delegated power. **Delegator:** The number of unique delegators who have delegated their voting power to the participant, showcasing their support base. **Voting Turnout:** The participant's voting participation rate, reflecting their engagement and activity level in governance. **Delegated To:** The address(es) to which the participant has delegated their voting power, if applicable. **Referred By:** The address of the entity or individual who referred the participant. **Join Via:** Indicates the method of joining, whether as a badgeholder choice or through project selection. ## Boarding Pass The concept of the Boarding Pass is used to represent participation periods, similar to "seasons" in the Token House and "rounds" in the Citizens' House. Each Boarding Pass encapsulates the start and end dates of a governance period and includes a metaphorical "class" designation that reflects the level of engagement and contribution during that period. The classes, inspired by seat classes on a flight, are as follows:
**Start and End Dates:** The specific timeframe of the governance period, indicating when the participation began and concluded. **Class Level:** The assigned class based on the participant's level of engagement and contribution. This classification serves as an indicator of the participant's involvement and dedication. **Total Points Received/All Points:** A summary of the total points earned by the participant, expressed as a ratio or percentage of the total possible points. This metric provides a quantitative measure of the participant's performance and contribution relative to the maximum achievable. ## Stamps or Badge Stamps, or badges, are awarded based on the data collected during the governance season or round, reflecting the participant's accomplishments and milestones. Each badge has a unique design and specific criteria that must be met to earn it. At the end of each season or round, these achievements are attested to, and badges are awarded accordingly. The badges vary in levels and are associated with different XP or points, indicating the degree of achievement.
**Level:** Each badge can have 1-4 levels, visually represented as stars on the stamp. The criteria for each metric and level will be detailed in the "**Badge Tier & XP**" section. **XP:** Each badge level contains a specific amount of XP or points, which represent the level of achievement or contribution. **Status:** Badges are categorized into three statuses: 1. **Eligible:** The participant has met the criteria to earn the badge. 2. **Ineligible:** The participant has not met the necessary criteria. 3. **Bonus:** Special badges awarded for extraordinary achievements or contributions outside the standard criteria. **Details:** Each badge includes detailed information on how it can be earned, outlining the specific actions or milestones required. # Public and Anonymous Endorsement The Public and Anonymous Endorsement feature allows users to endorse other governance participants using the Ethereum Attestation Service (EAS). This service enables the creation of verifiable attestations on the Ethereum blockchain, providing a secure and transparent way to recognize and validate contributions. Participants can endorse others publicly or choose to keep their endorsement anonymous, depending on their preference for privacy. ## **Public Endorsement:** Public endorsements are openly visible on the blockchain, allowing the endorser's identity to be seen by others. This type of endorsement helps build trust and transparency within the community, as participants can publicly recognize each other's contributions. ## **Anonymous Endorsement** Anonymous endorsements enable users to share their support without revealing their identity. This is achieved by utilizing advanced cryptographic techniques, such as Zero-Knowledge Proofs (ZKP), to hide the endorser's identity while still providing a valid endorsement. This feature encourages candid feedback and support without the fear of social repercussions, fostering a more open and supportive environment. ## **How It Works** 1. **Creating an OP Passport:** After creating an OP Passport, users can search for any address, currently limited to delegates, delegators, and badgeholders. 2. **Accessing the Endorsement Feature:** Navigate to the "Endorsement" button. 3. **Filling Out Endorsement Details:** Users can fill out the title and details of the endorsement they wish to give. 4. **Selecting the Role:** Choose to endorse the participant as a Delegate, Delegator, or Badgeholder, depending on the role applicable. 5. **Anonymous Endorsement Option:** Users can choose to endorse anonymously by selecting the "Hide your identity" option, allowing them to support others without revealing their name. * **Password Setup for Anonymous Endorsement:** If opting for an anonymous endorsement, users must set a password. This password is required to revoke the endorsement later. If the password is forgotten, the endorsement cannot be revoked in the future. ## **Revoking an Endorsement** Users can revoke their endorsements, a feature provided by the attestation system. The revocation process is straightforward: * **Public Endorsement:** For public endorsements, users can simply click the "Revoke" button on the specific endorsement they wish to withdraw. * **Anonymous Endorsement:** To revoke an anonymous endorsement, users must enter the password they set during the endorsement process. This password ensures that the endorsement can only be revoked by the original endorser. The Public and Anonymous Endorsement feature offers a versatile and secure way for community members to recognize each other's contributions, whether openly or privately. This functionality enhances the overall governance experience by promoting transparency, accountability, and supportive engagement among participants. # 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. # 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.
## OP Passport Creation Flow The creation of an OP Passport involves several steps, integrating both off-chain and on-chain processes to ensure a secure, verifiable, and privacy-preserving digital identity. Here's a summarized flow: 1. **User Eligibility & Initiation:** * A user eligible for creating an OP Passport initiates the process through the Passport frontend. 2. **Passport Creation Request:** * The request is sent to the OP Passport API, which creates the passport, updates the database, and sends a task to GCP Cloud Task for further processing. 3. **Safe Wallet Creation:** * A Safe wallet is created for the user, which will store their digital identity. 4. **Attestation Process:** * The Attestation API constructs the necessary EAS schemas for the passport and user achievements. * The system attests the passport and achievements on-chain using the Ethereum Attestation Service (EAS). 5. **Finalization:** * The passport and associated achievements are recorded on-chain with their respective EAS IDs and transaction hashes (TxHash). * The OP Passport API updates the passport with all relevant on-chain data, completing the process. This flow ensures that each user's governance participation and achievements are securely documented, providing a verifiable and transparent on-chain identity.
# 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 Point **OP Mainnet and OP Sepolia Testnet:** Deployment environments for the platform. **Contracts:** * **OP Contract:** For votes and delegates data. * **Gov Contract:** For governance participation data. * **EAS Contract:** To issue new attestation and retrieve existing attestation data. * **Alligator Contract:** For partial delegation information. * **EAS Schema Registry:** To register new schema for OP Passport. * **Account Factory:** To create new Smart Accounts for holding OP Passports and acting as the identity layer for each user. **Governance Database:** Integration for reliable data attestation and verification of governance activities.
# Badge Tier & XP ## Delegate
Badge TitleTier 1Tier 2Tier 3Tier 4
Voting Power10 XP
(100-1K)		20 XP
(1,000-10K)		30XP
(10K-100K)		40 XP
(>100K)
Top Voting Power Ranking 10 XP
(1,001-10K)		20 XP
(101-1K)		30 XP
(11-100)		40 XP
(1-10)
Delegate Address10 XP
(2-10)		20 XP
(11-100)		30 XP
(101-1K)		40 XP
(>1K)
Voter Turnout / Participation Rate10 XP
(0-50%)		30 XP
(50-70%)		50 XP
(70-90%)		70 XP
(90-100%)
Vote With Rational10 XP
(0-50%)		30 XP
(50-70%)		50 XP
(70-90%)		70 XP
(90-100%)
Voting Power Increase10 XP
(20-40%)		25 XP
(40-60%)		40 XP
(60-80%)		55 XP
(>80%)
Received Partial Delegation
(Bonus)		10 XP
(100-1K)		25 XP
(1,000-10K)		40XP
(10K-100K)		55 XP
(>100K)
## Delegator
Badge TitleTier 1Tier 2Tier 3Tier 4
Duration of Delegation10 XP
(1-100)		30 XP
(100-500)		50XP
(500-700)		70 XP
(>700)
Amount Delegate10 XP
(0-100)		20 XP
(100-1K)		30 XP
(1K-10K)		40 XP
(>10K)
Quality of Delegate Supported0 XP
(Ghost Delegate)		10 XP
(Inactive Delegate)		70 XP
(Active Delegate)
Partial Delegation (Delegate)10 XP
(100-1K)		20 XP
(1K-10K)		30 XP
(10K-100K)		400 XP
(>100K)
## Badgeholder
Badge TitleTier 1Tier 2Tier 3Tier 4
Voter Turnout / Participation Rate10 XP
(0-50%)		30 XP
(50-70%)		50 XP
(70-90%)		70 XP
(90-100%)
#### Delegate Metrics **Voting Power:** The amount of tokens delegated to a delegate, determining their influence in governance votes. **Top Voting Power Ranking:** The rank of a delegate based on the total voting power they have received compared to others. **Delegate Address Count:** The number of unique delegators who have delegated their voting power to a delegate. **Voter Turnout/Participation Rate:** The percentage of governance proposals in which a delegate has participated by casting votes, calculated based on seasons. **Vote with Rational:** The percentage of votes where a delegate has provided a reason or rationale for their decision, calculated based on seasons. **Voting Power Increase:** The percentage increase in a delegate's voting power from the initial amount delegated to them, calculated based on seasons. **Partial Delegation:** The amount of voting power a delegate receives from delegators who delegate only a portion of their total tokens. #### Delegator Metrics **Duration of Delegation:** The length of time a delegator has continuously delegated their voting power to a delegate. **Amount Delegated:** The total amount of tokens a delegator has delegated to a delegate. **Quality of Delegate Supported:** An assessment metric based on the performance and participation quality of the delegates a delegator supports. **Partial Delegation (Delegate):** The amount of voting power a delegator assigns through partial delegation to different delegates. #### Badgeholder Metrics **Voter Turnout/Participation Rate:** The percentage of governance proposals in which a badgeholder has participated by casting votes, calculated based on rounds. # Issuance Condition Badges are issued by the Curia team each season. Data is collected at the season's end to determine achievement levels for each metric. | Seasons/Rounds | Date Start | Date End | | -------------- | ---------- | ---------- | | Season 1 | 2022/6/9 | 2022/8/4 | | Season 2 | 2022/8/25 | 2022/11/11 | | Season 3 | 2022/12/9 | 2023/4/6 | | Season 4 | 2023/4/28 | 2023/9/20 | | Season 5 | 2023/10/13 | 2024/5/8 | | Season 6 | 2024/5/24 | 2024/12/11 | \*\* Note that some seasons might start before the announcement from [Optimism Doc](https://community.optimism.io/docs/governance/token-house-history/#seasons-and-voting-cycles) since the events include reflection periods. # Attestation Mechanism 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 1. Users submit attestations through the passport frontend or directly through the smart contract on Optimism at our EAS schema contract. 2. The EAS schema contract calls the role resolver contract. 3. The role resolver contract calls the customized role validity checker for each customized role. 1. Badgeholders are identified by on-chain badgeholder attestation () from OP Foundation attestor addresses (0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9, 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F) \*\*Users must also submit the badgeholder attestation id as a reference. The attestation is only valid for the latest RetroPGF round. 2. Delegates and Delegators are identified by OP token contract () inside `getVotes` and `delegates` view functions 4. If the resolver returns true, then emit the attestation. The transaction is completed per user perspective. 5. Curia Indexer picks up all attestations for the schema. 6. The attestation can be viewed through the passport frontend in both the 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. * Data part: `{role: uint256, title:string, message: string, ref: bytes}`
# Anonymous Endorsemnt 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 () due to ease of development, community support, and tooling. ### Implementation Details And Workflow: #### ZK Proof Generation: 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), The AA account signature can be later replaced with ERC-6492 signature. * User request to do anonymous attestation to target address on some message * User input password for the revocation of the attestation * User send signature verifying their ownership of address to Curia through frontend or directly to api (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 the address, identity role, and timestamp of the generation . * Calculate revoker using hash of timestamp and the password * User generate ZK Proof that proof that * User know a valid Curia signature that sign on that specific address * 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. #### Cons: * Rely on Curia infrastructure. 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.
# 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.)