Profile of v3naru_Curia in Optimism

Posts by v3naru_Curia

• Optimism Governance Survey - We Want to Hear from You! by v3naru_Curia - No Role
  Posted on: Oct. 29, 2024, 4:31 a.m.
  Content: Thanks so much for participating, @ismailemin and @Marcus 01
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• Optimism Governance Survey - We Want to Hear from You! by v3naru_Curia - No Role
  Posted on: Oct. 25, 2024, 4:26 a.m.
  Content: Hey Optimism Community! I’m running a quick survey to get your thoughts on all things Optimism Governance. Whether you’re a delegate, builder, contributor, voter, or just keeping an eye on things, your input is super valuable in helping us improve governance tools and processes. What’s the Survey About? I’m hoping to hear from you to: Improve Governance Tools: Your feedback helps shape better analytics and platforms. Boost Participation: Spot any engagement barriers so we can make governance more accessible. Shape Future Decisions: Understand which topics are most significant to you, influencing future proposals and discussions. What to Expect in the Survey The survey has three parts: Demographics: A bit about your role in Optimism Governance. Your Interests: What topics are you into, and how do you stay informed? Product Experience & Data: Feedback on the tools you use and any issues with accessing or understanding data. [Click Here to Take the Survey] 6 Estimated time: Just 5 - 10 minutes! Your Privacy All responses are confidential and used only to to improve the Optimism Governance experience for all community members. Thank you for taking the time to help out! If you have questions or need a hand, feel free to reply here or reach out to me directly.
  Likes: 2 Replies: 0
  Likers: Pumbi, eugenia
  No replies yet.
• Optimism Governance Survey - We Want to Hear from You! by v3naru_Curia - No Role
  Posted on: Oct. 25, 2024, 4:26 a.m.
  Content: Hey Optimism Community! I’m running a quick survey to get your thoughts on all things Optimism Governance. Whether you’re a delegate, builder, contributor, voter, or just keeping an eye on things, your input is super valuable in helping us improve governance tools and processes. What’s the Survey About? I’m hoping to hear from you to: Improve Governance Tools: Your feedback helps shape better analytics and platforms. Boost Participation: Spot any engagement barriers so we can make governance more accessible. Shape Future Decisions: Understand which topics are most significant to you, influencing future proposals and discussions. What to Expect in the Survey The survey has three parts: Demographics: A bit about your role in Optimism Governance. Your Interests: What topics are you into, and how do you stay informed? Product Experience & Data: Feedback on the tools you use and any issues with accessing or understanding data. [Click Here to Take the Survey] Estimated time: Just 5 - 10 minutes! Your Privacy All responses are confidential and used only to to improve the Optimism Governance experience for all community members. Thank you for taking the time to help out! If you have questions or need a hand, feel free to reply here or reach out to me directly.
  Likes: 2 Replies: 0
  Likers: Pumbi, eugenia
  No replies yet.
• Retro Funding 5: OP Stack - round details by v3naru_Curia - No Role
  Posted on: Sept. 30, 2024, 1:48 p.m.
  Content: Thanks for bringing this up, especially regarding the “impact time considered for rewards.” I think this is a crucial aspect to consider, as it adds depth to understanding the scope of contributions eligible for retro funding. I agree that for Retro 5 , the period considered for the impact (from Retro 3 up to Retro 5 ) justifies a cap lower than 10 M, given the relatively shorter duration compared to previous rounds. To further refine our approach in future rounds, I’d like to propose an additional requirement for applicants: providing the project inception date when applying, in addtion to their previous retro funding reward rounds. This will allow us to assess not only the recent impact but also provide a more comprehensive view of a project’s contribution over time, especially for projects that haven’t applied in previous rounds. This adjustment would ensure a fairer and more transparent evaluation process, helping us align the allocation of rewards with the full scope of each project’s impact.
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• Retro Funding 5: OP Stack - round details by v3naru_Curia - No Role
  Posted on: Sept. 26, 2024, 7:03 a.m.
  Content: Disclaimer: The views expressed here are my own and do not represent the Grants Council or any other governance entity I am involved with. I think it makes sense to reconsider the allocation for Round 5 since fewer applications were approved this time. I wanted to share my thoughts on what might be a fair OP token allocation for Retro Funding 5 . I did some number-crunching based on data from Retro Funding 3 , and I thought it’d be helpful to share as a reference for others. Here’s the Breakdown: 1 . Looking Back at Retro Funding 3 (OP Stack Category): 146 projects received allocations in the OP Stack category during Retro 3 . 2 . Checking Out Resubmitted Projects for Retro Funding 5 : I went through the list of projects that got approved for Retro 5 . Found that 21 projects from Retro 3 have reapplied and got approved for Retro 5 . 3 . Allocation for the Resubmitted Projects: Let’s assume these 21 projects have continued to make a consistent impact since Round 3 , so they’d get around the same allocation they got back then. The total allocation they received was 4 , 429 , 911 OP. 4 . Allocation for New Projects Using Averages: That means 125 projects from Retro 3 didn’t reapply. For Retro 5 , there are 58 new projects that didn’t participate in Retro 3 . I’m thinking we can use the average (mean) and median allocations from those 125 projects to estimate what the 58 new projects might receive. From those 125 projects in Retro 3 : Average allocation per project: ~ 65 , 459 OP Median allocation per project: ~ 49 , 689 OP 5 . Estimating Allocation for the New Projects in Retro 5 : Using the Average: Total estimated allocation: 65 , 459 OP * 58 = 3 , 796 , 622 OP Using the Median: Total estimated allocation: 49 , 689 OP * 58 = 2 , 881 , 962 OP 6 . Calculating the Total for Retro Funding 5 : With the Average: Resubmitted projects: 4 , 429 , 911 OP New projects: 3 , 796 , 622 OP Total: 4 , 429 , 911 OP + 3 , 796 , 622 OP = 8 , 226 , 533 OP With the Median: Resubmitted projects: 4 , 429 , 911 OP New projects: 2 , 881 , 962 OP Total: 4 , 429 , 911 OP + 2 , 881 , 962 OP = 7 , 311 , 873 OP Additional Note: Based on data we gathered from the on-chain application attestations, the total allocation for Retro Funding 3 allocated to the OP Stack was actually 12 million OP. This includes projects with overlapping categories. If we only count projects that were exclusively in the OP Stack category, the number is 2 . 72 million OP. These numbers are different from the benchmark number provided by the OP Foundation, which was ~ 6 . 5 million OP. This discrepancy might be due to differences in categorization or counting methods. I’ve included the sheet here 7 with all the calculations for those who want to dive deeper into the numbers. So, What’s my takeaway? Based on these calculations: Using the Average: Total comes to about 8 . 2 million OP Using the Median: Total comes to about 7 . 3 million OP I think it makes sense to adjust the OP allocation to somewhere between 7 . 3 million and 8 million OP (due to the cap). This way, we’re aligning the rewards with the potiential impact and participation in this round, keeping things consistent with past rounds.
  Likes: 8 Replies: 3
  Likers: Jonas, joanbp, eugenia, dmars300, timbeiko, ccerv1, habacuc.eth, 0x666
  Replies:

  • joanbp: Nice to see some number crunching. In the spirit of putting our thoughts out where everyone can see them and discuss them: Let’s assume these 21 projects have continued to make a consistent impact since Round 3, so they’d get around the same allocation they got back then. This assumption might hold true if RPGF3 and RPGF5 both operated with a specific and comparable time span for the impact that is to be rewarded, say, if they both rewarded impact within the last 12 months. However, RPGF3 was open ended back in time - applicants were free to apply based on impact created over multiple years. Also, it is my impression that not all returning applicants are careful to only report fresh, not-previously-rewarded impact or to argue clearly for why previously rewarded work has in the meantime become more impactful so as to merit new rewards. For these reasons, I would actually expect careful analysis to show that at least some returning applicants should receive significantly less this time around than they did in RPGF3. That means 125 projects from Retro 3 didn’t reapply. For Retro 5, there are 58 new projects that didn’t participate in Retro 3. I’m thinking we can use the average (mean) and median allocations from those 125 projects to estimate what the 58 new projects might receive. On the other hand, I would expect at least some of the new applicants to be high achievers. It is worth noticing that the 21 returning applicants received a lot more than the average OP Stack project in RPGF3, meaning that the 125 not returning projects must have received less. I would not assume that the new applicants are more like the latter group than like the first without any evidence. Who will pick up the baton next? Let’s just see where this can take us.
  • grapebaba: I am very pleased to see such detailed statistics, as there are some projects that did not choose OP Stack in retro 3, such as go-ethereum, and there are also some projects whose application names are different from those in retro 3, such as test in prod, and some that were applied for individually in retro 3, which have now been changed to projects. In fact, the number of resubmitted projects is at least greater than 5M.
  • OPUser: Thank you for sharing this. Discussions based on metrics are always a step in the right direction. However, one important factor missing here is the time frame considered. RPGF3 was not time-bound, and when rewards were allocated, at least to me, this was a crucial aspect. Some projects had been live for over a year, publicly available, operational, and generating impact. Round 3 was the first time these projects participated in RPGF. eg,65,000 OP for two years of contribution less than half of that, under 30,000 OP? This round is time-bound, as others have already mentioned, and it makes it difficult to make an informed decision based solely on past data, although it does provide a point of reference. I understand that building in public is challenging, and countless hours of work cannot be sustained on charity alone. Looking back, the primary goal of RPGF was to bridge the gap between impact and reward. My intention isn’t to contradict your points but to offer a new perspective. Personally, I’d prefer to allocate 10% more rather than risk allocating 2% less. Another point to consider is the treasury. While we have a significant amount of OP set aside for the next few rounds, without impacting the treasury, if we continue spending without considering revenue, we could potentially hurt our long-term sustainability. Between October 2023 and August 2024, the current round’s time frame, Optimism’s revenue is approximately $11.37M ( + $1.25M from Base) Source Round 4: 10M OP Round 5: Between 2-8M OP Round 6: 3.5M OP We can calculate the inflow/outflow ratio based on these figures. Optimistically, we could run approximately 80 more rounds, each with 10M OP, just from the treasury (with 799.99M OP remaining from the initial RPGF allocation), without relying on revenue. However, our current focus is narrow, limited to the Superchain ecosystem. It would be unfortunate if we couldn’t extend this experiment beyond Superchain to support open-source contributions, public goods, and potentially common goods as well. There are many ways to approach this, and different strategies could be implemented in future rounds but I believe I am branching out from the discussion point so holding my train of thoughts here. However, I wanted to emphasize that, while it’s important to review past rounds to assess rewards, we should also try to look into future.
• Agora Updates & Feedback thread by v3naru_Curia - No Role
  Posted on: Sept. 11, 2024, 7:35 a.m.
  Content: Hi @yitong @zcf , I hope you’re doing well! Earlier this week, we started using the Agora API as an alternative data source for our platform. While working with the data, we noticed some discrepancies between Agora’s and Curia 1 ’s start and end dates for several proposals. To avoid potential confusion or misinformation for other platforms building on top of this data, I wanted to bring these to your attention. Voting Cycle: Special Voting Cycle # 12 a Proposal: Protocol Delegation Program Renewal Agora: April 7 , 2023 – April 7 , 2023 Curia: April 27 , 2023 – May 11 , 2023 View Proposal 1 Proposal: Intent # 3 Budget Proposal Agora: April 7 , 2023 – April 7 , 2023 Curia: April 27 , 2023 – May 11 , 2023 View Proposal Proposal: Intent # 2 - Council Intent Budget Proposal Agora: April 7 , 2023 – April 7 , 2023 Curia: April 27 , 2023 – May 11 , 2023 View Proposal Proposal: Intent # 4 Budget Proposal Agora: April 7 , 2023 – April 7 , 2023 Curia: April 27 , 2023 – May 11 , 2023 View Proposal Proposal: Intent # 1 Budget Proposal Agora: April 7 , 2023 – April 7 , 2023 Curia: April 27 , 2023 – May 11 , 2023 View Proposal Voting Cycle: Special Voting Cycle # 12 b Proposal: Inflation Adjustment Proposal Agora: May 4 , 2023 – May 5 , 2023 Curia: May 18 , 2023 – May 31 , 2023 View Proposal 2 Proposal: Council Reviewer Elections: Growth Experiments Grants Agora: May 5 , 2023 – May 5 , 2023 Curia: May 18 , 2023 – May 31 , 2023 View Proposal Proposal: Treasury Appropriation (Foundation Year 2 Budget Approval) Agora: May 4 , 2023 – May 5 , 2023 Curia: May 18 , 2023 – May 31 , 2023 View Proposal Proposal: Council Reviewer Elections: Builders Grants Agora: May 5 , 2023 – May 5 , 2023 Curia: May 18 , 2023 – May 31 , 2023 View Proposal Voting Cycle: Voting Cycle 11 Proposal: Upgrade Proposal: Bedrock Agora: January 30 , 2023 – January 30 , 2023 Curia: March 23 , 2023 – April 5 , 2023 View Proposal 4 Proposal: Delegate Suspension: Fractal Visions Agora: January 30 , 2023 – January 30 , 2023 Curia: March 23 , 2023 – April 5 , 2023 View Proposal 1 We believe it’s important to fix this issue as soon as possible to prevent misinformation on other platforms using this data. Ensuring accurate and consistent data is crucial for the governance ecosystem, especially for platforms building on top of the Agora API. Please feel free to reach out if you need more details. Thank you for your attention to this, and we appreciate the great work from the team so far!
  Likes: 0 Replies: 2
  No likes yet.
  Replies:

  • yitong: Thanks for reporting! DM’ing you to investigate
  • kent: Re: Time discrepancy issue . We’re estimating the time data based on the block number which can lead to slight discrepancies from the actual block timestamp. We have an item on our roadmap to start using timestamps instead but that requires significant surgery to Agora’s data layer. The specific request that got brought up above has to do with the fact that Curia was using our old GRAPHQL API that we built in 2023. Our updated API, the REST based API found here: Agora API has more accurate data. However, this issue is only present for older proposals (before the Bedrock) and will not affect newer ones. In the longer term, we’ll be switching to using actual block timestamps instead of estimated timestamps. Thanks for the feedback and keep it coming!
• Voting Cycle Roundup #23b by v3naru_Curia - No Role
  Posted on: June 19, 2024, 6:48 a.m.
  Content: I would like to know if future citizen house veto proposals will have the third options of “I do not feel confident enough to vote” like the most recent one 2 ? Since I’m building the dashboard for this, it will affect my plan on how I design the data pipeline and compute the metrics to show on our citizen house dashboard 1 going forward. Thanks
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• Voting Cycle Roundup #23b by v3naru_Curia - No Role
  Posted on: June 19, 2024, 6:48 a.m.
  Content: I would like to know if future citizen house veto proposals will have the third options of “I do not feel confident enough to vote” like the most recent one? Since I’m building the dashboard for this, it will affect my plan on how I design the data pipeline and compute the metrics to show on our citizen house dashboard going forward. Thanks
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• OP Passport | Design Document by v3naru_Curia - No Role
  Posted on: June 11, 2024, 5:41 p.m.
  Content: 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. AnthiasLabs: can you share a bit more about how this differentiates from the function served by this page on your guys’ current dashboard The OP Passport project is a separate initiative that utilizes the data infrastructure built for the Optimism Governance Dashboard. The primary new features include: 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. Digital Identity Passports: This feature allows users to manage their on-chain identity, which includes tracking governance participation and achievements through digital passports. Badge Issuance and Management: Users can earn badges based on predefined criteria, which are then securely managed through smart contracts. Liliop.eth: 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? 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. 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 Web 3 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. 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: AnthiasLabs: how are you thinking about the flow/incentive to attract community members to endorse other members? Purely good will, or is there something else? 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. Liliop.eth: 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. 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!
  Likes: 1 Replies: 0
  Likers: Liliop.eth
  No replies yet.
• OP Passport | Design Document by v3naru_Curia - No Role
  Posted on: June 7, 2024, 9:23 a.m.
  Content: 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! Introduction 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: 1600 × 890 186 KB 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. Features 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. Badge 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 image 1420 × 922 198 KB image 1260 × 818 157 KB image 1260 × 818 122 KB image 1260 × 818 110 KB image 1260 × 818 129 KB image 1260 × 818 156 KB Attestation flow image 1260 × 377 59 . 7 KB image 1260 × 364 53 . 6 KB 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_V 1 ” 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_V 1 ” 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.)
  Likes: 2 Replies: 0
  Likers: Liliop.eth, femtechglobal
  No replies yet.