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.
| 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
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