[Mission Request] Cross Chain Voting

[Gonna.eth]

Delegate Mission Request Summary

Enable cross-chain voting by building a module that allows for voting on an L2 and execution on an L1, contributing to the progress toward decentralization.

Possible implementation (thank you @zachobront):
Any OP stack chain can access the L1 block hash. By utilizing this hash, you can validate a storage value, which can serve as the root for another OP stack chain. This allows you to prove the storage value on that chain. In this setup, you can vote on any chain, and the chain that resolves the voting will require someone to submit evidence of the vote on all other chains, and aggregate them.

Intent 1: Progress Towards Decentralization

Proposing Delegate/Citizen

gonna.eth

Total grant amount

40.000 OP

Should this Mission be fulfilled by one or multiple applicants

Multiple applicants

What is required to execute this Mission Request?

1. Define the requirements for the cross-chain voting module, including user interface, data storage, and data retrieval mechanisms.
2. Design and develop the module architecture, including integration with existing Collective infrastructure.
3. Implement the module, including testing and quality assurance.
4. Deploy the module and provide documentation and training for users.
5. Monitor and evaluate the effectiveness of the module in enabling cross-chain voting.

How should governance participants measure impact upon completion of this Mission Request?

Governance participants can measure the impact of this mission request by tracking the following metrics:

1. Number of votes executed on an L1 via the cross-chain voting module.
2. Increase in the number of addresses participating in governance from L2.
3. Improvement in the decentralization and security of the voting process.
4. Reduction in the time and cost associated with voting and executing proposals.

Milestones

1. Requirements definition completed
2. Module design and architecture completed
3. Module implementation and testing completed
4. Module deployed and integrated with Collective infrastructure
5. Evaluation and monitoring of the module’s effectiveness completed

Metrics

1. Number of votes executed on an L1 via the cross-chain voting module.
2. Increase in the number of addresses participating in governance from L2.
3. Improvement in the decentralization and security of the voting process.
4. Reduction in the time and cost associated with voting and executing proposals.

Impact

This mission request will have a positive impact on the progress toward decentralization by enabling cross-chain voting, making it easier for participants from different chains to participate in governance. This will lead to increased decentralization and security of the voting process, as evidenced by the following measurable outcomes:

• Increased number of votes executed on an L1 via the cross-chain voting module
• Increased number of addresses participating in governance from L2
• Improved decentralization and security of the voting process
• Reduced time and cost associated with voting and executing proposals

Has anyone other than the proposer contributed to this Mission Request?
Consulted with Zach.

Which metric will the success of this Mission Request be evaluated against?

The North star metric against which this Mission Request should be evaluated is # of addresses voting for the first time, as it indicates how this effort contributes to an increase in active voting participation. This metric was suggested by the Foundation and approved by the Grants Council.

[LauNaMu]

Thanks for crafting this proposal!

I have some questions which may be pretty simple, so appreciate the answer.

What is the type of cross-chain voting we are trying to enable here? Or what is the use case?
I first thought that this might be a fractionalized liquidity in which we might have OP sitting in other chains of the Superchain and through this module we’d be able to “activate it” and allow for people to vote with it wherever they had it, but looking at other chains OP only lives in Mainnet (as far as I’ve found, maybe I am wrong). So I’m not sure what this cross-chain voting use case refers to…

Or does this refer to enabling snapshot votes cross-chain? Could you please share some of the examples you had in mind when crafting the proposal?

For example, if we are to look at the Metrics and Impact sections:

1. What type of votes would point 1 refer to (examples)?
2. What is considered as “addresses participating in governance”? Delegating addresses? Voting addresses?

Or is this more of redundancy in which we are not storing governance votes on OPMainnet but on Ethereum Mainnet so if anything were to happen to OP Mainnet other Superchain chains can directly go to Ethereum Mainnet to validate a vote?

Thanks!

[dennison]

Hello!

This is an exciting Mission request!

I wanted to share the work that Tally.xyz has done in the past for the collective for cross-chain voting.

RollCall - a cross chain library for doing cross chain governance built on OP.

Superchain Governance DeepDive - a research project in to implementation techniques for cross chain governance in on Optimism and across the super chain

MultiGov - A powerful product solution built by Tally, Wormhole and ScopeLift that enables universal MultiChain governance.

Tally would be very interested to continue its work in this area and has the expertise on the subject matter. We would be happy to discuss more.

[system]

A North Star Metric has been added at the bottom of this Mission Request in an effort to enable the Collective to make data-driven decisions. By using a single metric for each Mission Request, the Collective is better able to evaluate the performance of all the Season 6 missions in a standardized manner, which will be critical when the Collective makes decisions about Intents, budgets, or other critical components of governance.

[LauNaMu]

Is there a reason why the North Star metric is not specific to addresses voting in other chains?
If we focus on OP Mainnet new voting addresses this could be a causality from any of the other Mission Requests that look to increase number of voting addresses.

@Gonna.eth can you please explain? Would also be useful to have more details on the logic behind the Mission even if it’s already been approved.

Thanks!

[aurelianoBuendia]

Hello,

I’m Guillem from Snapshot Labs, and I’m excited to express our interest in the Cross Chain Voting mission on behalf of both Snapshot Labs and Herodotus. Our collaboration brings together two highly relevant projects that have the experience to significantly contribute to this mission’s goals.

Relevant Experience

1. Storage Proofs on Optimism: Herodotus previously received a grant for developing Storage Proofs on Optimism[1]. We’re proud to note that Herodotus went above and beyond the initial scope, adding support for all OP Stack chains. This expansion is now just a matter of deploying to new networks as they emerge. This experience provides us with a solid foundation in working with Optimism’s infrastructure and understanding its unique challenges across the entire OP Stack ecosystem.

2. Snapshot X: Snapshot Labs has developed Snapshot X, an on-chain protocol for decentralized governance that aligns well with this mission[2]. Besides its modularity and advanced governance features, it can post storage proofs as arbitrary metadata in votes, natively facilitating cross-chain voting. Execution payloads can also be sent from L2 to L1, allowing for cross-chain execution of proposals. Importantly, we’ve already implemented this in production on Starknet, demonstrating a proven synergy with Herodotus’ solutions. Additionally, we can directly engage more than 2,000 DAOs within Snapshot from Optimism, Base and other OP Stack chains, offering them a seamless transition to this new cross-chain solution. Since increasing voter participation is Snapshot’s North Star, we believe this mission is a natural fit for us.

These combined experiences ensure that we can execute the cross-chain voting solution tailored for OP Stack chains efficiently and with minimal risk.

Proposed Approach

We envision leveraging the strengths of both Storage Proofs and Snapshot X to create a robust cross-chain voting module. Our high-level approach includes:

1. L1 Block Hash Utilization: Implementing a secure method of utilizing L1 block hashes for validating storage values across chains, part of the Storage Proof Workflow.
2. Cross-Chain Voting Mechanism: Developing a system that allows voting on any chain while securely aggregating votes, building upon Snapshot X’s existing infrastructure.
3. User Interface: Integrating into Snapshot’s UI, with custom white-label interfaces for those who need them. Also making it accessible to developers building alternative UIs through an SDK.
4. Documentation: Providing comprehensive documentation to facilitate adoption and use of the module.

Budget

We are interested in applying for the full grant amount of 40,000 OP tokens to cover development, testing, and deployment costs of both teams. We’re open to discussing the budget allocation and milestones in more detail as the project progresses.

Next Steps

We’re excited about the potential of this project and its impact on advancing decentralization in the Optimism ecosystem. Both our teams are prepared to develop a more detailed project plan, including specific milestones and timelines, based on feedback from the community and delegates.

We welcome any questions, suggestions, or requests for additional information. We’re committed to working closely with the Optimism Collective to ensure this project meets the needs of the community and advances the goals of cross-chain governance.

[1] [Cycle 11] - Herodotus - Storage Proofs
[2] https://docs.snapshot.box/

[brichis]

GM @aurelianoBuendia! Please submit your application to the Grants Council Charmverse Space. You can join the space with this link: https://app.charmverse.io/invite/5e28cc.

Please pay special attention to the application guide, the rubrics, and the North Star metric of this MR.

@Gonna.eth

of addresses voting for the first time

Good luck!

[aurelianoBuendia]

Hey @brichis! Yes, we’ll make sure to submit our application before tomorrow’s deadline and follow the guidelines.

Thanks!

[LauNaMu]

I understand the Council is probably pretty busy getting ready to go through applications so maybe @lavande or @maxwell can share why this North Star metric was suggested by the Foundation.

[Gonna.eth]

This is my own opinion and does not represent the GC or Govnerds.

In an effort to make this season more transparent and have a way to track the progress of every mission request, a comparable metric was added to every mission.

@LauNaMu

can you please explain? Would also be useful to have more details on the logic behind the Mission even if it’s already been approved.

The ultimate goal is to facilitate more involvement in OP governance. The ideal metric for this is the number of new addresses voting, as it promotes fresh perspectives and ideas. Features like cross-chain voting would trace the decision-making process on-chain from other chains back to the token house. I keep all my mission requests open-ended, hoping that more skilled individuals will propose ideas that I might not have considered.

[lavande]

I can speak to the general concept behind having specific metrics by which to evaluate the success of all Mission Requests in Season 6 but will tag in @thbialek to comment on the reasoning behind individual metrics.

Transitioning more governance responsibilities to the community will require governance to be able to make data-driven decisions. For example:

Robust data infrastructure and analysis capabilities must be developed to enable the Collective to set Intents. Ideally, this system would allow the Collective to derive something that looks like a KPI tree stemming from a north star metric (ie. network usage) so that Collective Intent setting looks more like a calculation than a subjective brainstorming session.

Part of the Foundation’s role to bootstrap the governance system is to help establish a standardized data infrastructure that can support this type of decision making. Meaningful analysis of past Governance Fund grants has been limited due to a lack of standardization and pre-defined success metrics. This limits the Grants Council’s ability to further refine their own grant making and it also limits the Collective’s ability to understand how the Governance Fund drives progress towards the Intents relative to other mechanisms, like the Partner Fund or Retro Funding (for example.)

To start to lay to the groundwork for the Collective to be able to do meaningful analysis on allocation mechanisms, and how they drive impact towards the Intents, we’ve suggested a metric that ties back to the target metric for the corresponding Intent for each Mission Request. The goal is to enable standardized evaluation of the contribution of Season 6 Missions towards the Intent metrics.

Mission Request authors were given the opportunity to object to the suggested metrics and/or suggest an alternate metrics (from a menu of metrics provided by the Foundation) for their Mission Request. We recognize the assignment of standardized metrics to each Mission Request should have happened earlier in the process to ensure all Mission Requests are drafted in a way that corresponds to one of the relevant metrics. This is a clear learning for next Season.

I consider it a step forward for the Collective that the conversation can progress from unmeasured assessments of success/failure to a more targeted discussion about the best measurements to use to evaluate success.

[thbialek]

The north star metric for this Mission Request was primarily chosen, because it best encapsulates the scope of this Mission Request, that is, lowering the barriers to active governance participation through cross-chain voting. In general, the main goal of the suggested menu of metrics is to encourage the community to rally behind a shared set of success metrics that are aligned with the Collective’s Intents and help standardize any retrospective impact analysis. Naturally, this necessitates a delicate balancing act between the right level of standardization and customization in order to for these metrics to be sufficiently versatile yet consistent.

In this particular case, the north star metric was selected based on the premise that it gets to the heart of what this Mission Request is trying to achieve, which is to boost the number of executed votes, to reduce costs typically associated with casting votes onchain, and to increase active governance participation. In addition, this metric was deliberately designed in a broad enough manner to facilitate cross-chain use cases. Therefore, depending on the exact details of the grantee’s implementation, a causal relationship between the implementation of this Mission Request and the resulting increase in the number of addresses voting for the first time should be achievable through onchain attribution via interactions with the grantee’s contracts.

[Leuts]

Gm everyone!

Anthony from Aragon here. We’re thrilled to see an appetite for cross-chain voting, something we’ve been working on since our Multi-chain V1 launch with LayerZero in November 2023.

We, in partnership with RISC Zero have published our proposal via Charmverse and would very much like to work with the Optimism and Superchain ecosystem to bring the most aggressive and trustless solution to date using Storage Proofs.

We envision a solution that will enable seamless and trustless cross-chain voting, and:

1. Remove the need to bridge to vote; reducing a poor UX, removing risks associated with bridging, and eliminating fragmented liquidity.
2. Allow any type of token to vote, especially those not following the ERC20Votes standard. This is a giant industry pain point where currently most projects only using ERC20 without the votes standard are incapable of governing onchain. Democratizing onchain voting to the entire industry.
3. Preserve delegation when bridging across chains. As currently this is lost when a token holder bridgers from one chain to another. Increasing voter participation and decreasing lost delegations.
4. Automate the dispatch of votes from the voting chain as it currently needs to be executed, meaning there is a risk that votes are not bridged before a vote ends.
5. Enable gasless voting by abstracting it away using Coinbase Wallet, similar to the implementation that we currently have with zkSync, so users’ votes are free.

We welcome any questions, suggestions, or requests for additional information. We can’t wait for next steps and to hopefully to begin building this solution for OP and its ecosystem! Thank you!

[brichis]

GM @Leuts! Please submit your application to the Grants Council Charmverse Space . You can join the space with this link: https://app.charmverse.io/invite/5e28cc .

Please pay special attention to the application guide, the rubrics, and the North Star metric of this MR.
Good luck!

cc. @dennison

[Bunnic]

Tagging @op_julian, to inform this Mission Request was closed at the end of Cycle 26.