Looking Ahead: Long-term Onchain Governance Architecture

Looking ahead: Long-term Onchain Governance Architecture

We’re thrilled to share some updates and our vision for the future of onchain governance within our ecosystem. As many of you know, Agora has been instrumental in moving the governance fund onchain, and their upcoming proposal [link when available] marks a significant milestone for us. This move not only aligns with our commitment to transparency and decentralization but also opens up a conversation about the future of onchain governance within our ecosystem.

As we navigate this transition, we’re looking ahead at the longer-term future of onchain governance and how it can evolve to better serve our community. Currently, the Operating Manual serves as a robust framework guiding our governance processes. Translating its full functionality onchain presents challenges and opportunities that we believe are crucial to address in the open.

Proposal Permissioning: Balancing Innovation with Prudence

As we move the Governance Fund onchain, an important next step to consider is proposal permissioning.

Industry Standard vs. Current Model

The industry standard for onchain governance involves minimal barriers to proposal submissions, relying on token-based thresholds to filter proposals.

Our current model, which requires delegate approvals and adheres to voting cycles, offers a more granular system that we believe is crucial for maintaining the quality and relevance of proposals. However, this is enforced at the social layer by the Optimism Foundation—meaning only the OF is authorized to propose onchain, and offchain proposers must trust the OF to post their votes onchain:

Why a Direct Move to Permissionless Could be Problematic

Most DAOs use a token-based threshold requirement for permissionless proposal submission to prevent spam or malicious proposals from entering the voting process. A low barrier to entry can lead to an overwhelming number of proposals, many of which may lack substance or relevance to the community’s goals. This not only clutters the governance process but also dilutes the attention and resources that could be directed towards more impactful proposals. The main issue with using minimum token-based thresholds as a filtering mechanism is that it reduces participation relative to our current system (which allows the top 100 delegates to provide approvals) and creates plutocratically-gated proposal rights, which is antithetical to the principles outlined in our Working Constitution.

Additionally, the industry’s standard proposal structures don’t allow for logic encoded in our Operating Manual, which protects against common attack vectors including vote buying or borrowing, bribery, non-standard voting periods that can take advantage of voter apathy or advantageous ordering, malicious proposals, etc.

While these concerns could be partially mitigated by increasing the token-based thresholds required to propose, this presents a fundamental, plutocratic-favoring tradeoff—the higher the threshold, the less participatory governance can be, and the more “agenda-setting powers” are concentrated into the hands of large token holders. This means that proposal thresholds are an active subject of contention in many other communities, and go against the principle of anti-plutocracy outlined in the Working Constitution of the Optimism Collective.

Our Vision: A More Granular Approach

As we consider the future of onchain governance, we believe that we should strive for a system which mirrors the sophistication and nuance of our Operating Manual. This means creating an onchain governance model that allows for different types of proposals, and for rules and requirements which can be dependent on the specifics of the proposals in question.

As an illustrative example, imagine the following:

We believe that such a system would not only preserve the integrity of our governance process but also set a new standard for DAOs and onchain communities.

Next Steps: Bridging the Gap

To achieve this vision, we believe that initial focus should be on replicating the full functionality of the Operating Manual onchain, with a focus on Gov Fund proposals first. This work includes:

  • Delegate Approvals: Implementing the ability to gate proposals on multiple delegate approvals, as currently specified in the Operating Manual, with thresholds not reliant on token-based balances.
  • Voting Cycles: By requiring that proposals are only submitted within [1] day of voting cycles, we can preserve the current cadence of voting cycles specified in the Operating Manual.
  • Type-aware Permissioning: By implementing these rules with an awareness of proposal types, we can incrementally bring permissionless proposals online for additional proposal types.

Short-term Open Questions

While the above work is straightforward enough, some questions do remain which we’d like to open up for community discussion:

  • Ossification of Voting Cycles: In the past, we have changed voting cycles’ and seasons’ dates. Moving this onchain opens the question of how to proceed: either we permanently set voting cycles, or introduce a permissioned role which can change them. We propose that, to start, since the Optimism Foundation will retain a veto right over Gov Fund allocations that the Optimism Foundation can just hold this role to start.
  • Additional Size-based Safeguards: One open design question is: are there benefits to implementing more stringent requirements for proposal submissions, such as requiring more delegate approvals for proposals allocating higher amounts of OP? This would be a divergence from the Operating Manual today, but could be appropriate given the transition to permissionlessness.
  • Proposal Edits: How can we accommodate changes to proposals during the review period without compromising the voting process? Is it sufficient to allow arbitrary edits, but have any edits to reset delegate approvals?

Future Work: Expanding Our Governance Toolkit

Looking ahead, we’re excited about the possibilities of further enhancing our onchain governance architecture, which extends beyond proposal permissioning. We wanted to share what we see as some of the big architectural challenges in the long-term:

  • Onchain Citizens’ House Voting: Integrating Citizens’ House voting directly into our onchain processes, allowing for bringing multi-house decisions fully onchain. While there is some bare-bones work which needs to be done no matter what, we believe that further testing and refinement of the Citizens’ House Veto mechanism is required before we can finalize this architecture.
  • Onchain Citizenship Selection: Allowing for onchain governance to expand the Citizen set over time presents an extremely large design space, with less prior industry work to draw from than token voting systems. Because of how complex this design space is, more experimentation and clarity is needed before any productionization could begin.
  • Emergency Off-cycle Votes: We think the community should consider developing mechanisms for addressing urgent matters outside of the regular voting cycles.
  • Delegation Programs: Moving delegation programs like the Protocol Delegation Program and Chain Delegation Program to onchain mechanisms presents an opportunity to provide stronger guarantees to stakeholders.

In conclusion, the move to onchain Gov Fund execution represents a significant milestone for us, but it’s just the beginning. We’re committed to building a governance model that is not only robust and transparent but also flexible and inclusive. We look forward to engaging with the community as we embark on this exciting journey together.

18 Likes

Glad to see some more communication about moving on-chain. Much of the design challenges come from attempting to uphold the value of “anti-plutocracy”, which I generally agree with. However, requiring that a proposal gets 4 approvals from top-100 delegates, is effectively a gating mechanism on the basis of token weight. To put it more concretely:

The traditional token-governance model (unideal):
Proposals can only be listed on-chain by delegates with enough voting power. Thus, the delegate must have enough tokens to delegate the required voting power to themselves, or be connected to someone with sufficient tokens to delegate. In practice, delegates with high voting power can “sponsor” proposals on the forum on behalf of those with low voting power.

The model used by Optimism:
Anyone can list a proposal, but they must be approved by top 100 delegates. In other words, there is a threshold of voting power required to approve a proposal, and this threshold is the voting power of the 100th most powerful delegate. But since token house delegates can be anonymous (especially if approvals happen on-chain), a wealthy token holder can just split their delegations across 4 wallets. Thus, this system, although an improvement on the traditional model, still privileges the whales.

I don’t think we should delay the move towards on-chain governance in order to solve for this. Trying to come up with a more sophisticated model may be over-engineering. But I do want to point it out so that we don’t live under this illusion that this mechanism is somehow “anti-plutocratic.”

3 Likes

I fully support the recent efforts of moving governance on-chain and making it as decentralized as possible. While permissionless systems come with some risks, I believe the concerns mentioned in this thread—such as ‘spam and vote buying’—are overstated. These issues already exist and are manageable, so they shouldn’t be a major concern. My biggest concern is gatekeeping through delegate approvals, which concentrates power and undermines the spirit of decentralization. We need more inclusive systems, like reputation-based mechanisms or quadratic voting, to filter proposals without relying too heavily on a select few.

As for the short-term questions:

  1. I’m fine with a permissioned role for changing voting cycles, and I agree that the Optimism Foundation can hold this role initially. However, this should not be a permanent solution. Over time, this position should transition to being elected by the community to ensure it remains accountable and decentralized.
  2. I strongly oppose requiring higher amounts of OP for larger proposals. This safeguard would introduce more gatekeeping and put power in the hands of those with more tokens, discouraging broader participation and pushing us towards a more centralized system.
  3. Proposal edits should reset delegate approvals. Allowing edits without resetting would undermine the integrity of the process, as delegates need to review any changes to ensure the proposal still aligns with their original approval. This step is crucial to maintaining transparency and trust.
3 Likes

Excellent to see the progress here, and we appreciate the transparency from the Foundation’s side. As mentioned in convos with other Optimism contributors, we support the notion of focusing not only on who can propose certain proposals but also what type of proposal is being proposed and setting delineations there. Proposal type is key here, and it is great to see the Foundation moving in this direction.

Regarding the open questions:

On 1:We propose that, to start, since the Optimism Foundation will retain a veto right over Gov Fund allocations that the Optimism Foundation can just hold this role to start.” - We agree with this path.

On 2: We think the initial top-100 delegate approval suggestions in the second graphic above in the proposal are a bit low, but we support the direction. 5 top-100 delegate approvals for small gov fund allocations and 15 top-100 delegate approvals for large gov fund allocations would be more secure to start with and still would not be too much lift. We think our research around governance attack risk in the Optimism Collective supports this: Accelerated Decentralization Proposal For Optimism - #31 by AnthiasLabs

We additionally think the “small” and “large” allocation numbers should be adjusted slightly as they currently are aggressive. We would put small at <2% and large at 2%<=X<=5%. Any initiative looking to spend more than 5% of the treasury should require multiple stagged proposals with proven milestones / accomplishments demonstrated for the Collective given that level of spend.

On 3: No edits within 24 hours before the voting period makes sense here. This also fits with the suggestion of no new proposals within 24 hours before the voting period. Keep processes streamlined.

1 Like

Updating this thread with a link to the proposal to turn on onchain Gov Fund execution, as mentioned in the parent post:

4 Likes