Hi again Optimism Collective 
I’m back to share our Superchain Governance Deep Dive Research Proposal! This deliverable fulfills all of our critical milestones, including:
- Summary and technical evaluation of at least 3 promising technical implementations of Superchain decentralized governance.
- Explanation of process, including summary of all contributions from the Optimism Collective and links to source.
- Recommendation on most promising technical implementation of Superchain decentralized governance including key requirements and key risks.
We’ve enjoyed working on this Mission Proposal on behalf of the Optimism Collective. Pending positive feedback on our proposal and recommended technical implementation, we would like to submit a proposal in an upcoming season of Optimism governance to develop a production version of Superchain Governance 
Without further ado, I present Tally’s Superchain Governance Research Proposal 
=====================================================
Table of Contents
-
Introduction
-
Methodology
-
Technology Solutions Analysis
3.1 Message Passing
3.2 Storage Proofs
3.3 Zk-SNARKs -
Comparative Analysis and Recommendation
-
References
1. Introduction
As the Superchain continues to take shape and grow, the question of how to scale Optimism governance across the Superchain becomes increasingly relevant. While several teams in the Ethereum ecosystem have attempted multichain governance, a common standard has yet to emerge. Optimism Superchain governance poses unique challenges that are not addressed by existing solutions.
Superchain governance is subject to special requirements as outlined in the Law of Chains, including the ability to manage common technology standards while protecting the economic sovereignty of individual chain governors and users. The Superchain requires a technical implementation of governance with the flexibility and scalability to support a future of hundreds or even thousands of Superchain member chains. What will governance look like in a world where members of a DAO have their voting power split across tens, hundreds, or thousands of networks and in just as many smart contract services? How will users coordinate to manage their participation in the Superchain? How will users delegate their voting power? These are all questions we address in our technical analysis.
In this paper, we investigate the technical design space around decentralized Superchain governance and produce a document that can serve as a research-based foundation for technical implementation. We include an analysis of the available technology, detail the user experience of each possible implementation, and discuss implementation considerations, including high-level implementation timelines. We conclude with a recommendation of the technology stack that is most promising.
We considered three technologies: Message Passing, Storage Proofs, and zk-SNARKs.
In this paper, we also make several assumptions on the future of Optimism Governance:
- Optimism Mainnet is the home of Superchain Governance.
- Users may hold OP tokens on Optimism or any number of member Superchains.
- Users should be able to vote with OP tokens on non-OP mainnet chains (e.g., tokens held on Base, ZoraChain, Public Goods Network, etc.).
- A user’s voting power is the sum of their voting power across the Superchain.
While our objective is to recommend a single implementation, depending on the final constraints of Optimism Superchain governance, it might be possible to combine the strengths of multiple implementations to arrive at an even more ideal solution. If there is an appetite for this exploration, we would happily follow up on this project with additional research.
2. Methodology
We evaluated implementations based on the following criteria.
-
Technical Feasibility
- Is the solution possible today? If not, what confidence do we have that it will be possible soon?
- Is the solution already in use somewhere else?
-
Trust Minimization
- Does the solution alter the trust assumptions of the Optimism stack itself?
- Can users interact with the system independently in a self-sovereign way?
-
User Experience
- How closely do the solutions fulfill the modern expectations around governance features?
- Are there trade-offs required for delegation and voting?
- How smooth an experience is the solution for users?
Although we remark on the ballpark cost of various solutions, we decided not to use cost in our methodology matrix as we cannot benchmark it accurately as part of this project scope. We also reason that coming infrastructure improvements around DankSharding and possible implementations of ZK Proofs will drastically reduce the cost of using the OP Stack.
3. Technology Solution Analysis
3.1 Message Passing
The message passing solution uses the native bridge architecture of the OP stack to shuttle information about user participation in governance between the various chains in the Superchain. It requires passing smart contract calls from each OP stack chain down to L1 via the L2 messaging bridge, waiting for the seven-day challenge to combine the information on the L1 Mainnet, and bridging it back up to the OP Mainnet for the final calculation.
This solution is the simplest to implement with the modern form of OpenZeppelin Governor using Flexible Voting, an extension designed for this purpose.
For each governance proposal, a user must vote on each Superchain chain where they hold voting power. Voting can be done via signature aggregation with an onchain service such as Tally, or by calling each smart contract directly via a governance portal.
Proposing
Proposals are initiated either on OP Mainnet and bridged down to L1 Ethereum (from there, they are bridged to each Superchain member), or they can be initiated on L1 Ethereum and pushed up to all Superchain members, including OP Mainnet, simultaneously.
To minimize the impact of the seven-day challenge period if the proposal starts on OP Mainnet, we can optimistically start the proposal across all L2 Superchains by sharing a hash of the proposal data as the proposal identifier and ensuring at the finalization of the proposal that the hash of the proposal data matches across the Superchain.
It is somewhat difficult to solve the problem of identifying who has the authority to kick off new proposals in this design without needing to wait the entire seven-day challenge period, as the token holder who has sufficient voting power and wishes to create a proposal might not necessarily be on OP Mainnet. In this case, the most trust-minimized solution would be to allow any user with sufficient voting power to kick off a proposal on any Superchain (including OP Mainnet) and then use the seven-day challenge period as an opportunity for voters to finalize their voting power and delegations.
Once a proposal has been created and bridged to L1 Mainnet and the challenge period has concluded, it is bridged to each Superchain member network, where voting starts without delay.
Delegation and Voting
In the message-passing framework, delegation works but can quickly become unwieldy as the Superchain expands. Today, all delegation happens on the OP Mainnet, and all voting power is calculated on the OP Mainnet. In the wider Superchain however, delegation is a bit of an open question: Does Jane’s delegation to John on OP Mainnet also apply on Base Network? Or Zora Chain? Delegation state is chain-scoped. When a user makes a delegation to an address on one network, it’s not readable on another. In the message-passing solution we assume that Jane is required to delegate to John on every network where Jane holds OP tokens. That way, wherever John votes, he will be voting with the full power of Jane’s delegation. With the current limited number of Superhcain participants, this is still somewhat practical. A delegation by Jane to John would only require a small number of transactions, and the process could be batched by a 3rd party after collecting Jane’s signature. What gets complicated, however, is when the Superchain expands, and Jane needs to recreate her delegation to John for each new member chain.
For example:
- If Jane bridges her tokens from Chain A, where she has a delegation to John, to Chain B, where she is currently undelegated, how does Jane’s delegation get propagated to Chain B?
- If Jane delegates her tokens on Chain A to John, and the delegation is propagated via a 3rd party service to Chain B, what should happen if Jane delegates her tokens on Chain B to Lucy? Should the delegation on Chain A also be updated to Lucy?
- Actions unrelated to governance (such as bridging) materially affect a user’s delegated voting power. If Jane has delegated 100 tokens to Rob on OP Mainnet but has delegated only 10 tokens to Lucy on Base, if Jane bridges her 100 tokens from OP Mainnet to Base, she is effectively simultaneously delegating 100 more tokens to Lucy on Base.
For each proposal, a user can vote on a smart contract on each Superchain where they hold voting power. If a user holds voting power on many networks, in order to get the benefits of their complete voting power, it would be necessary to vote on each network. The cost of voting scales as users expand across chains.
Finalization
Once a proposal has completed the voting duration (on each network) a finalization function is called, which tallies up all the votes and kicks off a process to bridge the final results to L1 Ethereum, where they would then either be aggregated on L1 Ethereum or sent up to OP Mainnet for aggregation. It is necessary to wait seven days for the results from each chain to finalize, adding to the total duration of a proposal.
Pros
- The system is simple and practical to implement today
- Trust assumptions are identical to the OP stack itself.
- Optimizations are easy to offload to 3rd party services
- Users can always interact in a self-sovereign way
Cons
- The system is slow, assuming a seven-day voting period, seven-day wait to initiate proposal, and seven-day wait to finalize a proposal
- Delegation becomes impractical as the number of participating Superchain networks scales
- Governance smart contract infrastructure needs to be deployed on each member Superchain
User Experience
In the current state of the OP Superchain the User Experience would be identical to what exists today. However, the UX would decay as the Superchain expands and users bridge their tokens between chains. It would become increasingly complicated for users to track and manage their voting power. The costs for users would also linearly increase as delegation and voting require an increasing number of steps to complete. The most likely outcome would be reduced participation and orphaned voting power.
Implementation Considerations and Timeline
The Construction of a message-passing solution is straightforward. The working implementation of the smart contracts could be constructed in 4-6 weeks, excluding auditing, security, and feedback reviews. Existing governance interfaces could be incrementally updated to account for the growth of the Superhcain and the diffusion of tokens. A simple approach would be a table that lists voting power and delegation across chains. Users would need to send an identical transaction per network for voting and delegation. Third-party services could simplify this, but users would still be required to sign many sequential transactions and hold a balance to cover the gas cost on each network. The process would be repetitive and obnoxious for many participants.
3.2 Storage Proofs
Storage Proofs offer a mechanism for cross-chain voting within the Optimism Superchain by creating proofs of voting power rather than bridging voting power. Various teams have explored this technology, including Tally, Herodotus, Snapshot, LimeChain, and Aave. Using storage proofs, we can imagine a unification of the OP Superchain governance by abstracting away the underlying network and replacing smart contract calls and transactions with proofs of state instead.
With storage proofs, we can build a system where a user does their delegation and voting on OP Mainnet, but the user can vote with their combined power across the superchain. Storage proofs also bring additional flexibility beyond the message-passing solution. With storage proofs, governance can allow for the different ways users may hold OP tokens on Superchain networks. For example, a storage proof could prove the balance of a user’s OP tokens inside a DeFi protocol, allowing users to vote with tokens locked in smart contracts they do not directly control. Storage proofs allow for a more straightforward UX experience, greater third-party automation, and greater flexibility over how voting power is computed.
For our Storage Proof implementation, all delegations are made on OP Mainnet and are definitive across the Superchain. Voting happens on OP Mainnet. There is no governance smart contract infrastructure deployed on any of the non-OP Mainnet Superchains.
The Storage Proof implementation has four components:
- L1 Proposal Orchestrator
- L1 Shared Finality Oracle
- L2 OP Mainnet Governor + Proof Verifier
- Off-chain script for collecting Storage Proofs
The L1 Proposal orchestrator contract is responsible for kicking off new pending proposals, collecting the Superchain finalized state roots from the L1 Shared Finality Oracle and sending a message to the L2 OP Mainnet governor to start a new proposal. Users collect their proofs of voting power via the off-chain service, (which they could run themselves) and provide them to the L2 OP Mainnet Governor when voting.
Proposing
The governance process begins when a user provides the L1 Proposal Orchestrator with the request to create a proposal. This contract collects the state roots of the member Superchains from the L1 Shared Finality oracle and bridges the pending proposal and list of stateroots to OP Mainnet. Once the pending proposal has reached OP Mainnet (this process is quick), the user submits an array of storage proofs collected offchain proving that they have sufficient voting power to initiate a proposal. The governance contract on OP Mainnet verifies the users provided storage proofs against the pending proposals attached state roots and initiates the proposal.
Delegation and Voting
The Delegation UX is simpler in the storage proof example because all delegations are done on OP Mainnet governance contracts. In this system, it is also possible to support features like liquid delegation, where users can split their delegation across multiple addresses. Only one transaction is required for users to delegate, and they do not need to worry about their actions on other networks affecting their delegation status.
The process of voting for many users is simple and smooth. The governance UI abstracts away the offchain services to collect the necessary storage proofs, and the UX should be identical to the voting process today. For users who don’t want to use a hosted governance UI, it would be possible to run simple open-source scripts to collect the necessary storage proofs and submit them to the smart contract when voting.
As the superchain expands or a user receives many delegations, the system quickly reaches scalability limits. Users are required to provide storage proofs for each delegation they receive, for each network a voter has delegated to them. The process can require many transactions and is not cheap by current L2 standards, as the call data for the storage proofs still eventually settles to L1 Ethereum. For power users, this solution would be unacceptable.
Pros
- Trust assumptions are the same as Optimism
- Allows for aggregate voting power across multiple chains.
- Voting interfaces can make the experience simple and seamless
- Storage proofs are easy to generate, meaning users are not locked into 3rd party vendors
- Users with Voting power exclusively on OP Mainnet can vote directly via smart contract
- Users can vote with tokens locked in DeFi smart contracts
- Ability to add custom voting logic in smart contracts
Cons
- Storage proofs can be large, leading to higher costs when all calldata must land on L1
- Impractical for top delegates with numerous delegations due to the computational and financial costs of proving each delegate’s voting power.
Implementation Considerations and Timeline
Storage proofs are more complicated to implement because offchain services are necessary to power the process of gathering the required data (storage proofs). Fortunately, the design and implementation of storage proofs is well understood.
- 3-6 weeks for offchain components to collect storage proofs + index all networks
- 4-8 weeks for onchain components for smart contracts
The UX is more straightforward than in the message passing example, as the UI can effectively hide the complexity of the operations happening in the background. The UI should look the same as current voting portals with minimal UI changes. Delegation works the same as it currently does, and when a user votes, the heavy lifting is done behind the scenes.
3.3 Zk-SNARKs
Zk-SNARKs offer a flexible, cost-effective, and simple solution for cross-chain voting within the Optimism Superchain.
One of the most compelling advantages of zk-SNARKs over solutions like storage proofs is their efficiency. In a typical blockchain setting, each storage proof must be individually verified by a smart contract, which can be computationally expensive. zk-SNARKs, on the other hand, can aggregate multiple storage proofs, validate them individually, and then consolidate the results into a single proof. A smart contract can verify this aggregated proof much more efficiently, often at a significantly reduced computational cost. (A primer by LimeChain on zk-SNARKs and zk-STARKS)
zk-SNARKs can do any amount of arbitrary computing offchain, such as proving voting power across hundreds of Superchains, splitting voting power between delegations, and applying custom vote types, and still return a single zk-SNARK that is easy and cheap to verify onchain.
zk-SNARKs offer an improvement over storage-proof implementations by keeping the onchain verification cost relatively constant (and very low), regardless of the number of delegations or Superchain chains involved.While zk-SNARKs can make smart contract verification cost-efficient, the time needed to generate the proof off-chain can vary. Current improvements in proof generation mean that the time required to generate a proof is already well within the bounds of a convenient user experience, but will vary based on the number of delegations a user has. For users with very large proving sets, their proofs can be generated in advance, broken into smaller chunks, or simply take longer to process. This process can also be automated. Our design ensures that users are able to vote immediately without needing to wait for a proof generation.
The ability to perform arbitrary computation within a SNARK provides a broad design space for scalability improvements. Our solution employs a modular smart contract architecture that can adapt to future advancements in zk technology.
The nature of zk-SNARK technology also opens up the opportunity for robust expressive proofs that can accommodate future demands of the Optimism governance system. Offchain programs can be written to aggregate the voting power of users and transform the value through arbitrary computation. For example, a SNARK could calculate voting power that was time-weighted, accounting for users that might have only recently purchased tokens for the purpose of swinging a vote. Quadratic voting or conditional voting schemes can also be implemented without any increase in proving cost for the final output.
As part of this research project, we’ve spoken with three zero knowledge teams that are pioneering work in the space: RISC ZERO, 0(1) Labs, and Axiom. All of these teams are building exciting solutions that promise to bring incredible user experiences to the Superchain in a variety of ways.
For our proposed solution, we have chosen to focus on the tech stack of RISC Zero as it appears to be the closest to providing the working tools necessary to build a practical implementation of unified Superchain Governance. RISC Zero has a working showcase of governor-based voting using a design that reduces the gas cost of voting with the governor smart contract by 66%.
Our suggested implementation of RISC Zero is different, focusing on massive scalability rather than gas efficiency. Our implementation is still in the design phase and has yet to be benchmarked on gas costs.
We also spoke with the Axiom team on Sept 14th to preview their zk-SNARK based Governance tool. While we saw their working implementation too late to be included in this document’s recommendation, it is very exciting. Their implementation improves on our design, works natively with OpenZeppelin Governor, and removes the need to watch for finalized votes without slowing down the user’s experience when voting. Seeing their design reinforces our conviction that the zk-SNARK solution is the correct path for Optimism Superchain governance and that there will be multiple high-quality partners providing zk proof services.
Vendor lock-in and censorship resistance
It is important to note that the zk infrastructure ecosystem is growing, and it is possible to build the Superchain governance infrastructure in such a way that it is agnostic to zk infrastructure providers. Users would be free to collect offchain data and generate a proof in any way they choose. For convenience reasons, in this paper, we assume that Tally has built an offchain indexing service to produce the data required for the zk-SNARK proofs, that proofs are generated via the RISCZero Bonsai network, and that the cost of the proof generation service is paid for by the Optimism Collective. However, there is no hard vendor lock-in for this solution, and our particular implementation lets anyone submit proofs for users in a permissionless way.
Our Implementation
Our implementation of a zk-SNARK based solution has five components:
- L1 Proposal Orchestrator
- L1 Shared Finality Oracle
- L2 OP Mainnet Governor + SNARK Verifier
- Offchain process for collecting Storage Proofs
- RISCZero Bonsai Network for Proof Generation and Vote finalization
The L1 Proposal orchestrator is responsible for kicking off new pending proposals, collecting the Superchain finalized state roots from the L1 Shared Finality Oracle and sending a message to the L2 OP Mainnet governor to start a new proposal.
When a User casts a vote, they cast it directly on the smart contract which emits an event that is picked up by an offchain process. The offchain process collects the relevant storage proofs and submits them to the RiscZero Bonsai network. The Bonsai network creates the SNARK proof and submits it to the L2 OP Mainnet Governor via callback which finalizes the cast vote. Long term, we imagine an incentive system will ensure that an ecosystem of 3rd parties create proofs for votes in a decentralized way.
Proposing
A user wishing to start a proposal kicks off a process using the L1 Proposal Orchestrator by submitting a pending proposal request. The L1 Proposal Orchestrator collects the finalized state roots for the Superchain member networks and sends the pending proposal to L2 OP Mainnet Governor. An offchain process makes a request to the RiscZero Bonsai network to generate a proof that proves the proposer’s voting power, and the Bonsai network calls a callback on the L2 OP Mainnet Governor to activate the proposal.
Delegation and Voting
Delegation is done on OP Mainnet via a regular smart contract call. No changes are necessary. New features such as liquid delegation or partial delegation can be easily added with external smart contracts, without any changes to how the OP governance token currently works.
To vote, the user makes a normal smart contract call on the L2 OP Mainnet Governor with their vote. They are not required to provide their voting power as this will be proven later. The cost for the user is extremely low, perhaps a few cents, as this smart contract call only emits an event and adds to a mapping that their vote is pending.
When a user casts a vote, a voteCast event is emitted by the smart contract with the user’s address. The smart contract saves the vote with a status of “pending”. An offchain process catches the event and collects all the storage proofs from each L2 Superchain network necessary to build up the voting power. The offchain process then submits the list of storage proofs to the RiscZero Bonsai network to generate the ZK-SNARK proof. Once the proof is created, the Bonsai network uses a callback function on the L2 OP Mainnet governor to submit the proof and finalize the vote, which emits a voteFinalized event.
Finalization
At the end of the proposal voting period the vote enters a challenge period for finalization. During this time offchain processes that watch for voteCast and voteFinalized events can prove that a vote was not included by submitting to the smart contract a list of “pending” votes.
To incentivize correct behavior we imagine long term there is a competitive market of offchain services seeking to generate proofs, and users are also able to generate their own proofs to submit. We also can imagine there is a financial incentive for the creation of proofs beyond a user’s own self-interest in having their vote counted as well as a slashing system for third-party services that fail to submit proofs
The Axiom team presented to us on Sept 14th a very smart design for a zk-SNARK based governor that eliminates the need for the finalization process. We did not have time to include it in this report, but we are confident that the finalization process can be removed from the implementation using elements of their design.
Pros
-
Flexibility in accommodating arbitrary computations.
-
Massive scalability opportunities
-
Cost-effectiveness in smart contract verification.
-
No vendor lock-in; the system can be agnostic to ZK infrastructure providers.
-
Scalability improvements through modular smart contract architecture.
Cons
- Time variability in proof generation, especially for users with numerous delegations.
User Experience
Zk-SNARKs offer the best user overall experience compared to the alternatives. Users pay a consistent, low transaction fee for voting and they only need to vote once, in one place, with their voting power properly calculated from the entire Optimism Superchain. The system is equally enjoyable for power users with many delegations and small independent voters.
Implementation Considerations and Timeline
The implementation of the zk solution builds on the work of storage proofs, but the various zk tech stacks promise near term improvements to make the process vastly simpler. In particular, RISCZero has planned the ability to read state directly from public view functions, meaning it might not be necessary to manually collect storage proofs ahead of time. This functionality is still early in the pipeline so our implementation does not take it into consideration.
The zk implementation is simpler to implement on the smart contract level, since the heavy lifting is done inside the creation of the proof and RISCZero provides pre-built components for SNARK verification.
- 4-6 weeks for smart contracts
- 4-6 week for offchain support components
- 6-8 weeks for zk proof generation code (in Rust)
The user experience with Optimism governance will remain largely the same as it is today. Under the hood, the front-end tools will use APIs provided by RISCZero or other ZK providers. Although more complicated than in the storage-proof version, it would be possible for users to vote without dependence on a centralized UI.
4. Comparative Analysis and Recommendation
Based on scalability, cost-effectiveness, and flexibility, we recommend the adoption of a zk-SNARK-based solution for Optimism Superchain governance. This technology not only aligns with the current trends in cryptographic proofs but also offers a future-proof architecture that can adapt to the evolving needs of the Optimism ecosystem.
As the Superchain scales to hundreds of chains and millions of users, zk-SNARKs will shine while the alternatives will not be able to provide an acceptable user experience. With a zk-SNARK implementation, arbitrary compute can be executed offchain for a proposal. This would open the door to custom proposal types, custom voting calculations, trustless inclusion of offchain reputation data, and enable voting with tokens inside DeFi protocols.
The Optimism Superchain is growing rapidly, and users are only beginning to discover the possible use cases. With the zk-SNARK solution, Optimism governance would be set up to scale for the foreseeable future with predictable operational costs.
5. References
Zero-knowledge proofs explained, Limechain
Extractoor, LimeChain
Governance Example, RISCZero
RollCall, Tally.xyz
SnapshotX Announcement, Snapshot
Herodotus.dev
AAVE Governance V3
Axiom.xyz (public release of Governance example pending)
O(1) Labs x Tally: Private, Flexible, and Anonymous Voting