# Updated Voting Process: Introducing Minor Upgrades
**URL:** https://community.starknet.io/t/updated-voting-process-introducing-minor-upgrades/116148
**Category:** 🏛 Governance
**Tags:** decentralization
**Created:** [March 23, 2026, 11:39am UTC](https://community.starknet.io/t/updated-voting-process-introducing-minor-upgrades/116148 "2026-03-23T11:39:58Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@robertkodra](https://community.starknet.io/u/robertkodra)
#### Post date: [March 23, 2026, 11:39am UTC](https://community.starknet.io/t/updated-voting-process-introducing-minor-upgrades/116148/1 "2026-03-23T11:39:58Z")
Hi all,
Following up on our [previous post on the voting process](https://community.starknet.io/t/starknet-governance-updated-voting-process/116081), 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.
| 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.
| 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](https://governance.starknet.io/)
* * *
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
---
### Author:  [@Immanuelolivia1](https://community.starknet.io/u/Immanuelolivia1)
#### Post date: [April 3, 2026, 7:16am UTC](https://community.starknet.io/t/updated-voting-process-introducing-minor-upgrades/116148/2 "2026-04-03T07:16:33Z")
* * *
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.
---
### Author:  [@robertkodra](https://community.starknet.io/u/robertkodra)
#### Post date: [April 10, 2026, 8:20am UTC](https://community.starknet.io/t/updated-voting-process-introducing-minor-upgrades/116148/3 "2026-04-10T08:20:36Z")
> 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.