Network Upgrade Overview
This section has information on how to upgrade your Mainnet and Testnet nodes for new network upgrades. The network upgrade naming scheme after the Bedrock upgrade has a geology themed name based on the next letter in the english alphabet.
Activations
Network upgrades are activated by timestamps. Failing to upgrade your node before the timestamp will cause a chain divergence. You will need to resync your node to reconcile the chain. Optimistic activation times refer to times that are pending governance approval.
| Upgrade | Governance Approval | OP Mainnet Activations (opens in a new tab) | OP Sepolia Activations (opens in a new tab) |
|---|---|---|---|
| Fjord (opens in a new tab) | approved (opens in a new tab) | Wed Jul 10 16:00:01 UTC 2024 (1720627201) | Wed May 29 16:00:00 UTC 2024 (1720627201) |
| Ecotone (opens in a new tab) | approved (opens in a new tab) | Thu Mar 14 00:00:01 UTC 2024 (1710374401) | Wed Feb 21 17:00:00 UTC 2024 (1708534800) |
| Delta (opens in a new tab) | approved (opens in a new tab) | Thu Feb 22 00:00:00 UTC 2024 (1708560000) | Fri Dec 22 00:00:00 UTC 2023 (1703203200) |
| Canyon (opens in a new tab) | approved (opens in a new tab) | Thu Jan 11 17:00:01 UTC 2024 (1704992401) | Tue Nov 14 17:00:00 UTC 2023 (1699981200) |
Summary of Changes
These are the summary of each network upgrade changes order by the most recent activation. These are a reflection of the Superchain Upgrades Specifications (opens in a new tab)
Fjord (opens in a new tab)
The Fjord upgrade includes the RIP-7212 precompile, FastLZ gas pricing, Brotli channel compression, and several protocol parameter changes.
- RIP-7212: Precompile for secp256r1 (opens in a new tab)
- Brotli channel compression (opens in a new tab)
- FastLZ gas pricing
- Protocol parameter changes
- Fjord hardfork activation block (opens in a new tab)
Ecotone (opens in a new tab)
The Ecotone upgrade contains the Dencun upgrade from L1, and adopts EIP-4844 blobs for data-availability.
Cancun (Execution Layer):
- EIP-1153: Transient storage opcodes (opens in a new tab)
- EIP-4844: Shard Blob Transactions (opens in a new tab)
- Blob transactions are disabled (opens in a new tab)
- EIP-4788: Beacon block root in the EVM (opens in a new tab)
- The L1 beacon block root is embedded into L2 (opens in a new tab)
- The Beacon roots contract deployment is automated (opens in a new tab)
- EIP-5656: MCOPY - Memory copying instruction (opens in a new tab)
- EIP-6780: SELFDESTRUCT only in same transaction (opens in a new tab)
- EIP-7516: BLOBBASEFEE opcode (opens in a new tab)
- BLOBBASEFEE always pushes 1 onto the stack (opens in a new tab)
Deneb (Consensus Layer): not applicable to L2
- EIP-7044: Perpetually Valid Signed Voluntary Exits (opens in a new tab)
- EIP-7045: Increase Max Attestation Inclusion Slot (opens in a new tab)
- EIP-7514: Add Max Epoch Churn Limit (opens in a new tab)
Data Availability (DA) upgrade:
- Blobs Data Availability: support blobs DA the L1 Data-retrieval stage (opens in a new tab).
- Rollup fee update: support blobs DA in L1 Data Fee computation (opens in a new tab)
- Auto-upgrading and extension of the L1 Attributes Predeployed Contract (opens in a new tab)
(also known as
L1Blockpredeploy)
Delta (opens in a new tab)
The Delta upgrade consists of a single consensus-layer feature: Span Batches (opens in a new tab).
The Delta upgrade uses a L2 block-timestamp activation-rule, and is specified only in the rollup-node (delta_time).
Canyon (opens in a new tab)
The Canyon upgrade contains the Shapella upgrade from L1 and some minor protocol fixes.
- EIP-3651: Warm COINBASE (opens in a new tab)
- EIP-3855: PUSH0 instruction (opens in a new tab)
- EIP-3860: Limit and meter initcode (opens in a new tab)
- EIP-4895: Beacon chain push withdrawals as operations (opens in a new tab)
- Withdrawals are prohibited in P2P Blocks (opens in a new tab)
- Withdrawals should be set to the empty array with Canyon (opens in a new tab)
- EIP-6049: Deprecate SELFDESTRUCT (opens in a new tab)
- Modifies the EIP-1559 Denominator (opens in a new tab)
- Channel Ordering Fix (opens in a new tab)
- Adds the deposit nonce & deposit nonce version to the deposit receipt hash (opens in a new tab)
- Deploys the create2Deployer to
0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2(opens in a new tab)
The Canyon upgrade uses a L2 block-timestamp activation-rule, and is specified in both the
rollup-node (canyon_time) and execution engine (config.canyonTime). Shanghai time in the
execution engine should be set to the same time as the Canyon time.
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.
Devnet
Devnet Upgrade Notice Periodis for core developers to upgrade the node software on an internal devnet prior to the activation timestamp.Upgrade Activates on DevnetBaking on Devnet
Testnet
Testnet Upgrade Notice Periodis to allow testnet node operators to upgrade the node software on testnet prior to the activation timestamp.Upgrade Activates on TestnetBaking on Testnet
Mainnet
Governance Voting Review Periodis when the Optimism Collective's governance system reviews proposals, including network upgrade proposals.Governance Voting Periodis when the Optimism Collective's governance system votes on proposals.Veto Periodis when the Citizens' House of the governance system can veto a protocol upgrade that has been approved by the Token House.Cut Mainnet ReleaseMainnet Upgrade Notice Periodis to allow mainnet node operators to upgrade the node software on mainnet prior to the activation timestamp.Upgrade Activated
More Information
- To check for the latest node software, see the Software Releases.
- For more information on the governance process see the governance documentation (opens in a new tab).