Introducing improvements to the Protocol Upgrade process

Updates and Announcements 📢
,
1

As communicated in the Season 8 announcements, we launched significant improvements to the Protocol Upgrade process on August 1st. Here’s what you need to know:

TL;DR

  • Protocol upgrades now require approval by the Developer Advisory Board (DAB), who were elected by the Token House and Citizens’ House ahead of Season 8. This doesn’t apply to maintenance upgrades

  • Delegates are no longer required to post approvals of proposals on the forum, or actively vote to approve upgrades.

  • Instead, delegates and Citizens have the power to veto upgrades that they believe harm their interests during a 1-week Joint House veto period. They may also override the DAB’s decision to reject an upgrade.

  • This shift ensures an efficient, low-overhead, technically rigorous path to mainnet upgrades.

The improved upgrade process

protocol upgrades diagram
protocol upgrades diagram1600Ă—900 116 KB

Step 1: Developer Advisory Board Approval

  • An elected group of 7 independent protocol developers (the DAB) is looped in early to provide feedback on upcoming releases, and reviews upgrades during the final testing phase.

  • They assess each proposal for (among other things):

    • Technical content: does the proposal do what it says it will? Is it complete? Does call data match?

    • Technical merit: Is the justification of changes clear? Are the described benefits accurate? Are there unmentioned technical tradeoffs?

    • Collective impact: does the proposal violate the Law of Chains or Working Constitution?

    • The full list of the DAB’s responsibilities can be found here

  • Once the betanet phase is complete, the upgrade can be pushed to Sepolia.

  • If the DAB rejects a proposal, the upgrade continues to Sepolia and enters the 7 day stakeholder veto period. This allows stakeholders to choose whether to override the DAB decision.

Step 2: 7-Day Veto Period

  • Once on Sepolia, the upgrade enters a 1-week veto window.

  • If the DAB has approved the upgrade, stakeholders are voting to block the upgrade.

  • If the DAB has rejected the upgrade, stakeholders are voting to override the DAB’s decision and allow the upgrade to be executed.

  • Four stakeholder groups can object:

    • Delegates (Token House)

    • Chain Operators (Citizens’ House)

    • Application Developers (Citizens’ House)

    • End Users (Citizens’ House)

  • The full eligibility criteria for Citizens’ House membership can be found here

  • A veto is triggered if 2 or more groups cross the applicable below thresholds:

    • 2 groups: 17% of each group must support a veto

    • 3 groups: 14% each

    • 4 groups: 11% each

  • If veto threshold is not met → :white_check_mark: upgrade proceeds according to DAB decision.

  • If veto threshold is met → :stop_sign: DAB decision is overridden

  • If a proposal is rejected, it enters an appeals and discussion phase

What this means for delegates

Delegates continue to play their meaningful role in governance with a streamlined focus:

  • Delegates elect the Developer Advisory Board (DAB) to represent their interests on technical matters.

  • Delegates are no longer required to actively vote on every upgrade.

  • Delegates may engage in the veto process if a proposed upgrade appears misaligned with the interests of tokenholders, or they disagree with the DAB’s rejection of the upgrade.

  • If no concerns are raised, no action is needed—upgrades proceed by default according to the DAB’s decision.

  • This model preserves real oversight power, without demanding delegates’ time for every technical release.

Timeline

  • This process is live as of August 2025.

  • All Season 8 protocol upgrades will follow the new DAB approval + veto model.

  • Maintenance upgrades will follow a shortened version of the process without DAB approval, as defined here

  • Delegates will receive alerts on Telegram when an upgrade enters the veto period.

Continued improvements to the Protocol Upgrade process will be made ahead of Season 9

5 Likes
4

Given that both the Security Council and the DAB are both elected by the same governance and both required to implement an upgrade, would it make sense to merge the two bodies? Or are they distinct enough to stay as separate bodies?

5

Hi @GFXlabs

The Developer Advisory Board and Security Council have distinct roles in the system.

The goal of the Security Council“is to turn admin keys for OP Mainnet, and eventually, all OP Chains in the Superchain, over to a public, decentralized set of individual actors (“participants”) accountable to Optimism Governance.”

“During normal operations, the Council simply implements the upgrade and role permission decisions made by Governance, rather than making decisions itself.”

On the other hand, the “Developer Advisory Board (DAB) exists to provide independent, expert technical judgment to secure and advance the Optimism Collective.”

Their primary function is to vote on Protocol Upgrades on behalf of the Collective. In doing so, they are responsible for assessing the upgrade’s technical content, technical merit and Collective Impact.

More details can be found in the Security Council and Developer Advisory Board charters.

1 Like