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.

​
One upgrade per activation timestamp

Two network upgrades must never be configured to activate at the same L2 block timestamp after genesis. Every upgrade’s activation-block behavior — the upgrade transactions it deposits, the state it changes, the block attributes it derives — is only defined against a chain on which every earlier upgrade is already active, so two upgrades sharing an activation block is an unsupported configuration whose combined behavior no specification covers. Activation timestamps must be strictly increasing in upgrade order, and op-node rejects a rollup config that schedules two upgrades to activate together. See the activation rules in the superchain upgrades specification. Chains that launch after an upgrade already exists activate that upgrade in their genesis block instead, conventionally by setting its activation timestamp to 0 — so upgrades that are active from genesis do share a timestamp, and that is the one case the rule allows. This restriction covers OP Stack upgrades only: it does not constrain an OP Stack upgrade timestamp against an L1 fork timestamp on the same chain, which may coincide.

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