Just over three years ago, the Optimism Collective embarked on a large-scale experiment in decentralized governance. From the beginning, we’ve been committed to taking “an agile approach to governance—relentlessly iterating until we establish a system which can stand the test of time.” As we experiment, we learn more about the balance of power and other dynamics within our system, an iterative process that allows the Collective to mature and evolve (see Working Constitution).

Systems that are rigidly defined and slow to change struggle to adapt to changing conditions and often stagnate, losing to faster competitors or failing to innovate. Instead, Optimism governance strives to self-destruct, repeatedly, allowing the Collective to adapt, innovate, and continuously evolve as an agile governance system built to last.

Just as we periodically update the OP Stack to ensure the Superchain benefits from the latest and greatest technology, it’s time to update the governance system so that the Collective benefits from best-in-class decision making protocols. We’re excited to introduce several important governance updates that leverage time-tested concepts from traditional political science and corporate governance, combined with three years of cutting edge, practical learnings. Thanks to all of our governance participants for your willingness to experiment and iterate, without which the next phase of Optimism Governance would not be possible.

Over the past three years, Optimism governance has evolved from a group of tokenholders bootstrapping OP Mainnet to a large scale Collective collaboratively executing on the Superchain Vision. During this period, through many conversations with governance participants and major partners, we’ve refined our understanding of the role Optimism governance plays in this vision.

💡 The purpose of Optimism governance is to reduce platform risk for the Collective's stakeholders.

Platform risk is the risk to a business or user that a platform they depend on changes against their interests. It is a common risk of Web 2 platforms and is a key consideration for the largest partners building on the OP Stack.

So how does Optimism governance reduce this risk for businesses and end-users of the Superchain?

Platform risk exists largely due to a lack of accountability. Corporate governance models are primarily accountable to the largest financial interests. Decisions that disadvantage businesses or users are often made in the name of “maximizing shareholder value.” Once platforms achieve market dominance (or monopoly), it is very difficult for businesses or users to actually exit from those platforms as their leverage is limited and viable alternatives may not exist.

Below, we outline an update to Optimism Governance aimed at further reducing platform risk for the major stakeholders of the Superchain. This update includes several core concepts:

• Stakeholder Voting: Empowering the stakeholders of the Collective ensures governance is accountable, and not just to financial interests

  • A Public Definition of Citizenship: Stakeholder voting relies on a verifiable, objective, and scalable definition of Citizenship - a major milestone towards decentralization

• Governance Minimized Decision Making: Optimistic approvals allow us to lower the barriers to participation for important stakeholders while maintaining accountability

Season 8 takes steps to ensure governance is accountable to all major stakeholders of the Collective, not just financial ones (a key weakness of traditional corporate and crypto governance models). The goal is to reduce the platform risk that any one stakeholder dominates decision making at the expense of others.

How do we define being a stakeholder of the Collective?

Stakeholders contribute to shared resources and are directly impacted by governance decisions. Specifically, they are directly affected by protocol upgrades, contribute to the Collective treasury, and/or bear the cost of Collective economic decisions.

This is consistent with Elinor Ostrom’s framework for Governing the Commons which suggests that “Individuals or groups who have a legitimate interest or claim in the use, management, and sustainability of a common-pool resource” should be the ones to govern those resources.

This definition allows us to identify four key stakeholder groups to which the platform should be accountable:

• Tokenholders: Tokenholders share directly in the cost of economic decisions.

  • Please note that tokenholders are distinct from “delegates” as delegates may accumulate voting power without any direct tokenholdings or skin-in-the-game. The system should continue to increase the presence of tokenholders (self-delegated) and reduce the presence of non-or-low tokenholder delegates. In Season 8, we will run several experiments aimed at shifting voting power towards direct tokenholders.

• End-users: End-users contribute revenue to the Collective by paying gas fees on the Superchain. They are affected by protocol changes that impact transaction costs, user experience, security, and application availability. Their representation in governance ensures the Superchain remains optimized for those who use it daily.

• Apps: Applications running on the Superchain contribute Collective revenue in the form of gas fees on their smart contract transactions. They have built their business on the Superchain's reliability, performance, and feature set. Their participation ensures Collective decisions support the interests of the ecosystem's application layer.

• Chains: Superchain members contribute a share of their revenue to the Collective. They are fundamentally dependent on protocol changes, as their entire infrastructure relies on the core protocol's security, performance, and other features. Their participation ensures protocol development aligns with the needs of the diverse chains that make up the Superchain ecosystem.

⚠️ The key stakeholders of the Collective are the parties to which governance should be accountable (expressed via voting rights). That does not mean these are the only stakeholders that have influence within the governance system.

For example, the Core Development Program is enormously influential to the development of the Superchain. This influence is expressed by authoring protocol upgrade proposals, rather than voting on them. The voting process exists to create accountability for the core development program.

Contributors that are actively creating impact for the Superchain will still be eligible for Retroactive Public Goods Funding (Retro Funding) and other incentive programs.

Identifying the above stakeholder groups, allows us to arrive at a public definition of Citizenship, a major milestones in our path towards decentralization!

Over the course of the past three years, we’ve experimented with many different models of Citizenship. We’d like to thank all Citizens and Guest Voters who participated in these experiments throughout previous Seasons. The invaluable learnings from these experiments have enabled us to establish a transparent, public definition of Citizenship. This milestone is particularly significant as it creates objective criteria that can be verified onchain and ultimately maintained by governance itself—representing a crucial advancement in our journey toward decentralization!

In Season 8, the Citizens’ House will be sub-divided into three categories:

❗️ Citizenship remains an experiment and, as always, Citizenship in one Season does not guarantee Citizenship in future Seasons.

• End-users: Engaged Superchain end-users that meet a specific threshold of sustained activity on the Superchain and have a valid proof-of-personhood (Passport or World Id). Up to 1000 Citizens may register in this category. See here for more details.

  • Based on learnings in Round 6 (see here), we have moved away from evaluating users based on abstract “values”, and instead define the category based on the quantifiable stake they have in the continued success of the Superchain. Therefore, this group may include users of the Superchain that could be considered mercenary. If the group becomes overly skewed towards specific sub-populations, strategies may be taken to form a more representative set of users in future Seasons.

  • Existing Citizens are most likely to fall into this sub-category of the Citizens House. However, if they do not meet the required activity threshold, they will not continue to be Citizens in Season 8.

• Apps: Top Superchain applications based on the gas usage of their smart contracts in the past Season. A minimum of 100 apps will be eligible in this category. See here for more details.

  • Unlike in past experiments, builders of developer and other kinds of tooling are not included in this definition. Onchain apps are contributing to Collective resources and dependent on the protocol in a direct way that other types of builders are not.

Tokenholders will continue to be represented as a key stakeholder group via a token-weighted voting model in the Token House. Just as the Token House will continue to operate as usual, so will the Citizens’ House. The only difference is that the Citizens’ House will now be subdivided into three stakeholder groups.

Importantly, this sub-division isn’t about reducing any one stakeholder’s power— quite the opposite! It’s about representing all impacted stakeholders in a balanced way. This design is informed by academic research (e.g., Steinsson 2025, Bueno de Mesquita 2024, Smith and Hall 2022, Landemore 2020, Hirschman 1972), and conversations with experts and practitioners in political science and corporate governance.

While membership in the Token House and Citizens’ House can overlap, each House is designed to balance power in different ways. The Citizens’ House uses a ‘1 member, 1 vote’ model, which gives greater relative influence to the mid- and long-tail participants compared to the Token House’s token-weighted voting.

As with everything, this is an experiment, and over the next few seasons, the Foundation will continue to iterate on the specifics of implementation (definitions, voting thresholds, overlap, etc.) based on practical learnings.

In order for all stakeholders to hold the system accountable, we need to reduce the burden of participating in governance. Participating in governance should not require spending hours reading forum posts and navigating complex bureaucracy. Being a governance participant should not be a full time, or part time, job. Instead, Optimism governance should be easy enough to interact with that even our busiest stakeholders can provide high leverage inputs as needed.

Stakeholders want the platform to make decisions they are aligned with but that doesn’t necessitate that they participate in making those decisions themselves

Nobody should have to be a politician to participate and all stakeholders should be able to ensure the system reflects the values that are most important to them.

Optimism has never taken a one-size-fits-all approach to governance. Instead, we approach each governance question as a decision module with unique properties.

Each decision module is designed with the following principles in mind:

• Minimize governance overhead: Stakeholders should only be asked to actively make a decision when their buy-in is essential to implementation. In all other cases, they should be able to disagree with a decision but will not be asked to make the decision themselves.

• Optimize for expertise: When a decision does need to be actively made, the most knowledgeable parties should be entrusted with making those decisions.

• Maximize accountability: Those impacted by a decision should be able to veto or override a decision that directly impacts them.

This means many decision modules will leverage optimistic approvals. Optimistic approval assumes a vote is passed unless stakeholders explicitly reject it. Optimistic approvals lower platform risk in three major ways:

• They reduce the burden of participation for busy, but high context, stakeholders

• They ensure accountability by allowing stakeholders to reject a decision they disagree with

• They increase the operational efficiency of the Collective, increasing our ability to remain competitive

Here is how this approach will be implemented in Season 8:

• Resource Allocation Modules (Mission Budgets)

  • Who proposes? The Budget Board will be entrusted to propose budgets for token allocations. Given their expertise (or the accuracy of the infrastructure they bootstrap for the Collective), the Collective can defer to their decisions. However, each stakeholder group will retain a veto if they believe budget proposals unfairly disadvantage their stakeholder group.

  • Who approves? Nobody, it’s optistimically approved!

  • Who can veto? Any of the four stakeholder groups represented in the Token House and Citizens' House may veto a decision they’re impacted by if they believe a proposal unfairly disadvantage their stakeholder group.

  • Full details here

• Protocol Upgrade Modules

  • Please note this new process will go into effect on August 1st

  • Who proposes? Core Devs

  • Who approves? Approval of Protocol Upgrades will be delegated to an independent Developer Advisory Board, which acts on behalf of both the Token House and the Citizens’ House. The Developer Advisory Board will vote on all protocol upgrades (or veto maintenance upgrades) based on technical merit (see here for our learnings on technical expert voters here.)

Joint House optimistic approvals will leverage dynamic veto thresholds, in which thresholds are adjusted lower as consensus among stakeholders increases. This is a mechanism to reduce gridlock, creating bridging incentives for stakeholder groups to achieve mutually beneficial outcomes rather than act unilaterally. If a proposal is veto’d, it will proceed to an appeals process. Full details here.

The following decisions will continue to require active approval, as they require a high level of buy-in among participants for implementation:

• Collective Intent Ratification (Token House and Citizens’ House)

• Elections (Token House and/or Citizens’ House)

• DAO Operating Budget (Token House)

• Council and Board Budgets (Token House)

Full details about optimistic approvals, dynamic vetos, and the appeals process, can be found here.

As the Collective decentralizes, we must consider that there are ways to decentralize that actually increase platform risk. We remain committed to decentralization in so much as it also reduces platform risk. Accordingly, we’ve updated our thinking on our decentralization milestones to reflect this very important nuance.

✳️ For example: Consider a GitHub repository where push access is open to all. This is decentralized, but has extremely high platform risk.

Now consider a Github repository where push access is limited to a small, group of core development maintainers, and contributions are publicly managed through pull requests. This isn’t as centralized as a private repo owned by one devco, which would present platform risk. However, it is less decentralized than a completely open repo. The repo described introduces decentralization without also introducing platform risk, which is the Collective’s goal.

With this in mind, we will continue to make progress towards a refined set of Decentralization Milestones in S8.

Season 8 introduces a momentous update to the Collective’s governance system, reflecting a new level of maturity. This update refines involvement for those most impacted by governance decisions, shifts the focus from short-term incentives to long-term sustainability, and minimizes the governance surface area while making progress towards decentralization in so much as it reduces platform risk.

The goal has always been to create a governance model designed for a new internet; now we understand that means lowering platform risk by creating accountability where corporate governance models have failed to do so.

We could have only arrived at this stage of maturity with the help of all the contributors that dared to experiment with us over the past three years. As always, we will move forward as a Collective. Here’s to the next phase ✨

Want to dive deeper?

Check out the full Guide to Season 8, Operating Manual, and our FAQ on Citizenship.