Updated Voting Process: Introducing Minor Upgrades

🏛 Governance
1

Hi all,

Following up on our previous post on the voting process, we’re sharing an update that introduces a Minor Upgrade path alongside the existing Major and Emergency flows.

Our goal remains the same: make Starknet governance more predictable, inclusive, and transparent. This update formalises how different types of upgrades move through the process, giving the community clarity on timelines, requirements, and what to expect.

Every Starknet upgrade requires at least one SNIP. A single Starknet release can include multiple Core SNIPs, but governance votes on the full version as a package, tied to a specific GitHub commit hash.

The Three Upgrade Types

Starknet now has three distinct upgrade paths:

Type When it’s used
Major Significant protocol changes requiring full community review and Security Council involvement
Minor Smaller improvements with a shorter timeline; Security Council not required
Emergency Critical fixes that bypass voting; handled by the Security Council with post-mortem reporting

Major Upgrade Process

Major upgrades require a SNIP to be submitted before the process begins and involve Security Council review.

image
image825×172 6.14 KB

Phase Duration What happens
Announcement Start Upgrade announced and shared via social posts and a Community Forum post. SNIP required before this point.
Deliberation 2 weeks Community deliberates. Voting content finalized. Upgrade should be deployed on testnet. Commit hash available.
Review 1 week Final review before voting opens.
Voting 1 week Community votes. Security Council is involved.
Freeze Min. 7 days Upgrade cannot go live for at least 7 days after vote closes.
Deployment — Upgrade deployed to Mainnet.

Minor Upgrade Process

Minor upgrades follow a shorter timeline. A SNIP is still required, but it does not need to be published before the process starts and can be submitted in parallel.

image
image609×170 5.32 KB

Phase Duration What happens
Announcement Start Upgrade announced. Upgrade should be on testnet. Commit hash available.
Review 1 week Community reviews the upgrade on testnet.
Voting 1 week Community votes.
Freeze Min. 5 days Upgrade cannot go live for at least 5 days after vote closes.
Deployment — Upgrade deployed to Mainnet.

Key differences from Major:

  • Shorter overall timeline
  • SNIP can be submitted in parallel (not required upfront)
  • Security Council involvement not required
  • 5-day freeze instead of 7 days

Emergency Upgrade Process

Emergency upgrades (bugfixes, critical maintenance) bypass the standard voting process entirely.

  • Scope is kept open and flexible
  • Falls under the Security Council’s mandate
  • A post-mortem report is required after the fix
  • After resolution, the community can be polled on whether the change should have been handled as a minor or major upgrade

Summary Comparison

Major Minor Emergency
SNIP required Yes, before announcement Yes, but can be parallel No (post-mortem required)
Voting period 1 week 1 week None
Minimum freeze 7 days 5 days None
Security Council Involved Not required Initiates action

Communications

For all upgrade types, announcements will be shared via social posts and a Community Forum post. StarkWare and the Starknet Foundation each designate one person responsible for coordinating upgrade communications.

What this means for you

  • More flexibility: Not every upgrade needs the full major process
  • Faster iteration: Minor improvements can ship more quickly while still being community-approved
  • Same transparency: All upgrades are tied to a specific commit hash; all votes happen on the Governance Hub

We believe this structure strikes the right balance between speed and community oversight. As always, we welcome your questions, suggestions, and feedback below.

Best,
Robert

2

Thanks for this update, Robert! This is a really thoughtful evolution of the governance process.

The introduction of the Minor Upgrade path is something I have been hoping to see for a while. As someone who has been active in the Starknet ecosystem for over three years now, one of the recurring frustrations in the community has been watching smaller, non-controversial improvements get bottlenecked by the full Major upgrade timeline. This change directly addresses that without compromising on transparency or community involvement and that balance is exactly right.

A few things I particularly appreciate:

The commit hash requirement across all upgrade types is a strong trust anchor. It keeps everything verifiable and on-chain accountable regardless of which path an upgrade takes.

The 5-day freeze for Minor upgrades still gives the community a meaningful window to respond if something unexpected surfaces post-vote. That is a smart safeguard to keep even on the faster track.

The Emergency post-mortem requirement is also worth highlighting requiring a retrospective and giving the community the option to reclassify the upgrade afterward shows real commitment to accountability even when speed is the priority.

One question I would love clarity on: For Minor upgrades where the SNIP is submitted in parallel rather than upfront is there a defined deadline within the Review phase by which the SNIP must be published? Or can it technically be submitted any time before the Voting phase opens? Knowing that cutoff would help community members like myself plan our review and feedback cycles more effectively.

Looking forward to seeing this in action with the next release. Great work to the team on formalising this.

3

For Minor upgrades where the SNIP is submitted in parallel rather than upfront is there a defined deadline within the Review phase by which the SNIP must be published? Or can it technically be submitted any time before the Voting phase opens?

The SNIP will be required at the time of the announcement to give enough time to the voters to engage, review and discuss. I will make this change in the above post as it may not be clear enough.

Thank you for your reply.