Skip to main content
This page is the index of the hardfork registry: every OP Stack hardfork has one permanent page recording its activation timestamps, governing specification, governance approval, and minimum component versions. Governance-approved contract upgrades that carry no hardfork are listed separately below. Network upgrade names after Bedrock follow a geology theme based on the next letter of the English alphabet. The table below is generated from the registry pages’ structured frontmatter and validated against the superchain-registry — it is never hand-edited. See How this registry is maintained.

​
Activations

Network upgrades activate by L2 block timestamp. Failing to upgrade your OP Stack software before the activation timestamp causes a chain divergence, and you will need to resync the chain. Operator action items for each upgrade are published in Notices. Activation timestamps are the superchain-wide defaults from the superchain-registry. Timestamps are the canonical activation mechanism — block heights differ per chain, so no block numbers are listed. Individual chains outside those defaults set their own activation times in their chain config. All of the above build on Bedrock, the governance-approved 2023 re-genesis of OP Mainnet at block 105235063 (L2 timestamp 1686068903) that the hardfork series starts from. Sepolia OP Stack chains launched on Bedrock directly.

​
Contract upgrades

Not every governance-approved upgrade is a hardfork: hardforks activate by L2 block timestamp on every chain, while contract upgrades ship as op-contracts releases and are executed on each chain’s L1 contracts after governance approval. Contract-only upgrades have no activation timestamp, so they do not get hardfork registry pages — their permanent record is the op-contracts release history and the operator notice. Hardfork-carrying upgrades (for example Upgrade 15 / Isthmus, Upgrade 17 / Jovian, Upgrade 19 / Karst) are listed in the activations table above and link to their notices from their registry pages.

​
Upgrade process

Network upgrades follow this general process in which the features included in the upgrade are put into a release version cut from the develop branch and then the software is deployed on production networks.
“Baking” on a network means the node software has been deployed and is live. Engineers take this time to observe the behavior of the software on production networks.
1

Devnet

  • Devnet Upgrade Notice Period is for core developers to upgrade the node software on an internal devnet prior to the activation timestamp.
  • Upgrade Activates on Devnet
  • Baking on Devnet
2

Testnet

  • Testnet Upgrade Notice Period is to allow testnet node operators to upgrade the node software on testnet prior to the activation timestamp.
  • Upgrade Activates on Testnet
  • Baking on Testnet
3

Mainnet

  • Governance Voting Review Period is when Optimism governance reviews proposals, including network upgrade proposals.
  • Governance Voting Period is when Optimism governance votes on proposals.
  • Veto Period is when the Citizens’ House of the governance system can veto a protocol upgrade that has been approved by the Token House.
  • Cut Mainnet Release
  • Mainnet Upgrade Notice Period is to allow mainnet node operators to upgrade the node software on mainnet prior to the activation timestamp.
  • Upgrade Activated

​
How this registry is maintained

Each hardfork page keeps its machine-readable facts (lifecycle, activation timestamps, spec link, minimum component versions) in structured frontmatter. scripts/generate-hardforks.ts validates that data against the superchain-registry and renders the activation tables — a frontmatter edit followed by regeneration is the only way to change an activation row. The schema is documented in scripts/hardfork-registry.md.