Starknet Mainnet Upgrade History

The Starknet Mainnet Upgrade History provides a canonical, chronological index of every protocol-level state transition on Starknet mainnet. Each entry documents the activation date, block number, core Starknet Improvement Proposals (SNIPs) included, and a technical summary of breaking changes. This record serves as the primary reference for infrastructure operators, exchange security teams, and application developers to audit the network's upgrade cadence, verify the sequence of state transitions, and plan migration work.

Starknet upgrades are currently coordinated by the core development team and activated via sequencer-coordinated forks, a model that will eventually transition to on-chain governance votes with time-locked protocol upgrades. Each fork can introduce changes to the state transition function, Cairo virtual machine behavior, fee market mechanics, or system call interfaces. Operators running full nodes (Pathfinder, Juno, Papyrus) must monitor this history to ensure their client versions are compatible with the canonical fork chain, while bridge validators and light client implementers rely on it to verify state proofs against the correct block hash lineage.

Breaking changes documented here span multiple layers: the JSON-RPC API for RPC providers, the peer-to-peer layer for node operators, the contract execution environment for dApp developers, and the account contract interface for wallet teams like Argent and Braavos. A fork may deprecate older Cairo versions, alter fee estimation logic, or require state re-syncs from genesis or a snapshot. Teams responsible for integration security should cross-reference each upgrade with the corresponding testnet timeline to validate their staging environments before mainnet activation. Chainscore Labs provides upgrade readiness reviews, integration impact assessments, and node operator migration support for teams navigating these state transitions.

Starknet mainnet upgrades follow a sequencer-coordinated activation model, distinct from the on-chain governance votes or miner-signaled forks common in other L1s. A network upgrade is defined by a new set of protocol rules—typically a combination of a Cairo compiler version, a Sierra-to-Casm verifier, and an OS/state transition program hash. The Starknet sequencer, operated by StarkWare, initiates the fork by producing blocks under the new protocol rules at a pre-announced block height. All full nodes, RPC providers, and provers must have upgraded their software to the declared versions before this activation point to remain in consensus.

This model places a high operational coordination burden on infrastructure operators. There is no on-chain signaling mechanism or automated activation trigger; the fork is effectively a flag-day event. Operators monitor official Starknet communication channels for the announcement of an upgrade's target block number and the required software versions for Pathfinder, Juno, or other node clients. Failure to upgrade results in a node diverging from the canonical chain, requiring a resync. The sequencer's unilateral ability to trigger the fork is a deliberate architectural choice for the current 'Starknet Alpha' era, prioritizing rapid iteration over decentralized activation.

The planned transition to a decentralized sequencing and proving model will fundamentally alter this activation mechanism. Future eras are expected to introduce on-chain governance votes, time-locked upgrade contracts, and potentially a Security Council with emergency intervention powers, similar to the patterns seen in Arbitrum and Optimism. For operators, this means the current operational workflow of monitoring a single sequencer's upgrade schedule will evolve into tracking governance proposal lifecycles, analyzing on-chain timelocks, and preparing for multi-party coordinated activations. Teams running Starknet infrastructure should already be modeling the operational and risk-control changes required for a governance-driven upgrade model.

For exchanges, custodians, and bridge operators who verify Starknet state, the activation model directly impacts their security and reconciliation procedures. A sequencer-coordinated fork requires these entities to trust the sequencer's declaration of the new state transition program hash. In a decentralized future, they will need to independently verify governance outcomes and monitor timelock contracts. Chainscore Labs assists infrastructure teams in building upgrade readiness checklists, verifying state transition integrity across forks, and designing monitoring systems that detect chain divergence events during activation windows.