A timeline of all the major milestones, forks, and updates to the Ethereum blockchain.

Forks are when major technical upgrades or changes need to be made to the network – they typically stem from Ethereum Improvement Proposals (EIPs) and change the "rules" of the protocol.

When upgrades are needed in traditional, centrally-controlled software, the company will just publish a new version for the end-user. Blockchains work differently because there is no central ownership. Ethereum clients must update their software to implement the new fork rules. Plus block creators (miners in a proof-of-work world, validators in a proof-of-stake world) and nodes must create blocks and validate against the new rules. More on consensus mechanisms

These rule changes may create a temporary split in the network. New blocks could be produced according to the new rules or the old ones. Forks are usually agreed upon ahead of time so that clients adopt the changes in unison and the fork with the upgrades becomes the main chain. However, in rare cases, disagreements over forks can cause the network to permanently split – most notably the creation of Ethereum Classic with the DAO fork.

The software that underlies Ethereum is composed of two halves, known as the execution layer and the consensus layer.

Execution upgrade naming

Since 2021, upgrades to the execution layer are named according to the city names of previous Devcon and Devconnect locations in chronological order:

Consensus upgrade naming

Since the launch of the Beacon Chain, upgrades to the consensus layer are named after celestial stars beginning with letters that proceed in alphabetical order:

Combined naming

The execution and consensus upgrades were initially rolled out at different times, but after The Merge in 2022 these have been deployed simultaneously. As-such, colloquial terms have emerged to simplify references to these upgrades using a single conjoined term. This began with the Shanghai-Capella upgrade, commonly referred to as "Shapella", and is continued with subsequent upgrades.

Skip straight to information about some of the particularly important past upgrades: The Beacon Chain; The Merge; and EIP-1559

Looking for future protocol upgrades? Learn about upcoming upgrades on the Ethereum roadmap.

More on Fusaka

The Prague-Electra ("Pectra") upgrade included several improvements to the Ethereum protocol aimed at enhancing the experience for all users, layer 2 networks, stakers and node operators.

Staking got an upgrade with compounding validator accounts, and improved control over staked funds using the execution withdrawal address. EIP-7251 increased the max effective balance for a single validator to 2048, improving capital efficiency for stakers. EIP-7002 enabled an execution account to securely trigger validator actions, including exiting, or withdrawing portions of the funds, improving the experience for ETH stakers, while helping strengthen accountability for node operators.

Other parts of the upgrade focused on improving the experience for regular users. EIP-7702 brought the ability for a regular non-smart-contract account (EOA) to execute code similar to a smart contract. This unlocked unbounded new functionality for traditional Ethereum accounts, such as transaction batching, gas sponsorship, alternative authentication, programmable spending controls, account recovery mechanisms and more.

Better user experience:

• EIP-7702 - Set EOA account code
• EIP-7691 - Blob throughput increase
• EIP-7623 - Increase calldata cost
• EIP-7840 - Add blob schedule to EL config files

Better staking experience:

• EIP-7251 - Increase the MAX_EFFECTIVE_BALANCE
• EIP-7002 - Execution layer triggerable exits
• EIP-7685 - General purpose execution layer requests
• EIP-6110 - Supply validator deposits on chain

Protocol efficiency and security improvements:

• EIP-2537 - Precompile for BLS12-381 curve operations
• EIP-2935 - Save historical block hashes in state
• EIP-7549 - Move committee index outside Attestation

• How Pectra will enhance the staking experience
• Read the Electra upgrade specifications
• Prague-Electra ("Pectra") FAQ

The Cancun upgrade contains a set of improvements to Ethereum's execution aimed towards improving scalability, in tandem with the Deneb consensus upgrades.

Notably this includes EIP-4844, known as Proto-Danksharding, which significantly decreases the cost of data storage for layer 2 rollups. This is achieved through the introduction of data "blobs" which enables rollups to post data to Mainnet for a short period of time. This results in significantly lower transaction fees for users of layer 2 rollups.

• EIP-1153 - Transient storage opcodes
• EIP-4788 - Beacon block root in the EVM
• EIP-4844 - Shard blob transactions (Proto-Danksharding)
• EIP-5656 - MCOPY - Memory copying instruction
• EIP-6780 - SELFDESTRUCT only in same transaction
• EIP-7516 - BLOBBASEFEE opcode

• Layer 2 rollups
• Proto-Danksharding
• Danksharding
• Read the Cancun upgrade specification

The Deneb upgrade contains a set of improvements to Ethereum's consensus aimed towards improving scalability. This upgrade comes in tandem with the Cancun execution upgrades to enable Proto-Danksharding (EIP-4844), along with other improvements to the Beacon Chain.

Pre-generated signed "voluntary exit messages" no longer expire, thus giving more control to users staking their funds with a third-party node operator. With this signed exit message, stakers can delegate node operation while maintaining the ability to safely exit and withdraw their funds at any time, without needing to ask permission from anyone.

EIP-7514 brings a tightening to the issuance of ETH by capping the "churn" rate that validators can join the network to eight (8) per epoch. Since ETH issuance is proportional to total ETH staked, limiting the number of validators joining caps the growth rate of newly issued ETH, while also reducing hardware requirements for node operators, helping decentralization.

• EIP-4788 - Beacon block root in the EVM
• EIP-4844 - Shard blob transactions
• EIP-7044 - Perpetually valid signed voluntary exits
• EIP-7045 - Increase max attestation inclusion slot
• EIP-7514 - Add max epoch churn limit

• Read the Deneb upgrade specifications
• Cancun-Deneb ("Dencun") FAQ

The Shanghai upgrade brought staking withdrawals to the execution layer. In tandem with the Capella upgrade, this enabled blocks to accept withdrawal operations, which allows stakers to withdraw their ETH from the Beacon Chain to the execution layer.

• EIP-3651 – Starts the COINBASE address warm
• EIP-3855 – New PUSH0 instruction
• EIP-3860 – Limit and meter initcode
• EIP-4895 – Beacon chain push withdrawals as operations
• EIP-6049 - Deprecate SELFDESTRUCT

• Read the Shanghai upgrade specification

The Capella upgrade was the third major upgrade to the consensus layer (Beacon Chain) and enabled staking withdrawals. Capella occurred synchronously with the execution layer upgrade, Shanghai, and enabled staking withdrawal functionality.

This consensus layer upgrade brought the ability for stakers who did not provide withdrawal credentials with their initial deposit to do so, thereby enabling withdrawals.

The upgrade also provided automatic account sweeping functionality, which continuously processes validator accounts for any available rewards payments or full withdrawals.

• More on staking withdrawals.
• Read the Capella upgrade specifications

The Paris upgrade was triggered by the proof-of-work blockchain passing a terminal total difficulty of 58750000000000000000000. This happened at block 15537393 on 15th September 2022, triggering the Paris upgrade the next block. Paris was The Merge transition - its major feature was switching off the proof-of-work mining algorithm and associated consensus logic and switching on proof-of-stake instead. Paris itself was an upgrade to the execution clients (equivalent to Bellatrix on the consensus layer) that enabled them to take instruction from their connected consensus clients. This required a new set of internal API methods, collectively known as the Engine API, to be activated. This was arguably the most significant upgrade in Ethereum history since Homestead!

• Read the Paris upgrade specification

• EIP-3675 – Upgrade consensus to Proof-of-Stake
• EIP-4399 – Supplant DIFFICULTY opcode with PREVRANDAO

The Bellatrix upgrade was the second scheduled upgrade for the Beacon Chain, preparing the chain for The Merge. It brings validator penalties to their full values for inactivity and slashable offenses. Bellatrix also includes an update to the fork choice rules to prepare the chain for The Merge and the transition from the last proof-of-work block to the first proof-of-stake block. This includes making consensus clients aware of the terminal total difficulty of 58750000000000000000000.

• Read the Bellatrix upgrade specification

The Gray Glacier network upgrade pushed back the difficulty bomb by three months. This is the only change introduced in this upgrade, and is similar in nature to the Arrow Glacier and Muir Glacier upgrades. Similar changes have been performed on the Byzantium, Constantinople and London network upgrades.

• EF Blog - Gray Glacier Upgrade Announcement

• EIP-5133 – delays the difficulty bomb until September 2022

The Arrow Glacier network upgrade pushed back the difficulty bomb by several months. This is the only change introduced in this upgrade, and is similar in nature to the Muir Glacier upgrade. Similar changes have been performed on the Byzantium, Constantinople and London network upgrades.

• EF Blog - Arrow Glacier Upgrade Announcement
• Ethereum Cat Herders - Ethereum Arrow Glacier Upgrade

• EIP-4345 – delays the difficulty bomb until June 2022

The Altair upgrade was the first scheduled upgrade for the Beacon Chain. It added support for "sync committees"—enabling light clients, and increased validator inactivity and slashing penalties as development progressed towards The Merge.

• Read the Altair upgrade specification

Altair was the first major network upgrade that had an exact rollout time. Every upgrade prior had been based on a declared block number on the proof-of-work chain, where block times vary. The Beacon Chain does not require solving for proof-of-work, and instead works on a time-based epoch system consisting of 32 twelve-second "slots" of time where validators can propose blocks. This is why we knew exactly when we would hit epoch 74,240 and Altair became live!

• Block time

The London upgrade introduced EIP-1559, which reformed the transaction fee market, along with changes to how gas refunds are handled and the Ice Age schedule.

Before the London Upgrade, Ethereum had fixed-sized blocks. In times of high network demand, these blocks operated at full capacity. As a result, users often had to wait for demand to reduce to get included in a block, which led to a poor user experience. The London Upgrade introduced variable-sized blocks to Ethereum.

The way transaction fees on the Ethereum network were calculated changed with the London Upgrade of August 2021. Before the London upgrade, fees were calculated without separating base and priority fees, as follows:

Let's say Alice had to pay Bob 1 ETH. In the transaction, the gas limit is 21,000 units, and the gas price is 200 gwei.

The total fee would have been: Gas units (limit) * Gas price per unit i.e 21,000 * 200 = 4,200,000 gwei or 0.0042 ETH

The implementation of EIP-1559 in the London Upgrade made the transaction fee mechanism more complex, but made gas fees more predictable, resulting in a more efficient transaction fee market. Users can submit transactions with a maxFeePerGas corresponding to how much they are willing to pay for the transaction to be executed, knowing that they will not pay more than the market price for gas (baseFeePerGas), and get any extra, minus their tip, refunded.

This video explains EIP-1559 and the benefits it brings: EIP-1559 Explained

• Are you a dapp developer? Be sure to upgrade your libraries and tooling.
• Read the Ethereum Foundation announcement
• Read the Ethereum Cat Herder's explainer

• EIP-1559 – improves the transaction fee market
• EIP-3198 – returns the BASEFEE from a block
• EIP-3529 - reduces gas refunds for EVM operations
• EIP-3541 - prevents deploying contracts starting with 0xEF
• EIP-3554 – delays the Ice Age until December 2021

The Berlin upgrade optimized gas cost for certain EVM actions, and increases support for multiple transaction types.

• Read the Ethereum Foundation announcement
• Read the Ethereum Cat Herder's explainer

• EIP-2565 – lowers ModExp gas cost
• EIP-2718 – enables easier support for multiple transaction types
• EIP-2929 – gas cost increases for state access opcodes
• EIP-2930 – adds optional access lists

The Beacon Chain needed 16384 deposits of 32 staked ETH to ship securely. This happened on November 27, and the Beacon Chain started producing blocks on December 1, 2020.

Read the Ethereum Foundation announcement

The staking deposit contract introduced staking to the Ethereum ecosystem. Although a Mainnet contract, it had a direct impact on the timeline for launching the Beacon Chain, an important Ethereum upgrade.

Read the Ethereum Foundation announcement

The Muir Glacier fork introduced a delay to the difficulty bomb. Increases in block difficulty of the proof-of-work consensus mechanism threatened to degrade the usability of Ethereum by increasing wait times for sending transactions and using dapps.

• Read the Ethereum Foundation announcement
• Read the Ethereum Cat Herder's explainer

• EIP-2384 – delays the difficulty bomb for another 4,000,000 blocks, or ~611 days.

The Istanbul fork:

• Optimised the gas cost of certain actions in the EVM.
• Improved denial-of-service attack resilience.
• Made Layer 2 scaling solutions based on SNARKs and STARKs more performant.
• Enabled Ethereum and Zcash to interoperate.
• Allowed contracts to introduce more creative functions.

Read the Ethereum Foundation announcement

• EIP-152 – allow Ethereum to work with privacy-preserving currency like Zcash.
• EIP-1108 – cheaper cryptography to improve [gas](/glossary/#gas) costs.
• EIP-1344 – protects Ethereum against replay attacks by adding CHAINID [opcode](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
• EIP-1884 – optimising opcode gas prices based on consumption.
• EIP-2028 – reduces the cost of CallData to allow more data in blocks – good for [Layer 2 scaling](/developers/docs/scaling/#layer-2-scaling).
• EIP-2200 – other opcode gas price alterations.

The Constantinople fork:

• Reduced block mining rewards from 3 to 2 ETH.
• Ensured the blockchain didn't freeze before proof-of-stake was implemented.
• Optimised the gas cost of certain actions in the EVM.
• Added the ability to interact with addresses that haven't been created yet.

Read the Ethereum Foundation announcement

• EIP-145 – optimises cost of certain onchain actions.
• EIP-1014 – allows you to interact with addresses that have yet to be created.
• EIP-1052 – introduces the EXTCODEHASH instruction to retrieve the hash of another contract's code.
• EIP-1234 – makes sure the blockchain doesn't freeze before proof-of-stake and reduces block reward from 3 to 2 ETH.

The Byzantium fork:

• Reduced block mining rewards from 5 to 3 ETH.
• Delayed the difficulty bomb by a year.
• Added ability to make non-state-changing calls to other contracts.
• Added certain cryptography methods to allow for layer 2 scaling.

Read the Ethereum Foundation announcement

• EIP-140 – adds REVERT opcode.
• EIP-658 – status field added to transaction receipts to indicate success or failure.
• EIP-196 – adds elliptic curve and scalar multiplication to allow for [ZK-Snarks](/developers/docs/scaling/zk-rollups/).
• EIP-197 – adds elliptic curve and scalar multiplication to allow for [ZK-Snarks](/developers/docs/scaling/zk-rollups/).
• EIP-198 – enables RSA signature verification.
• EIP-211 – adds support for variable length return values.
• EIP-214 – adds STATICCALL opcode, allowing non-state-changing calls to other contracts.
• EIP-100 – changes difficulty adjustment formula.
• EIP-649 – delays [difficulty bomb](/glossary/#difficulty-bomb) by 1 year and reduces block reward from 5 to 3 ETH.

The Spurious Dragon fork was the second response to the denial of service (DoS) attacks on the network (September/October 2016) including:

• tuning opcode pricing to prevent future attacks on the network.
• enabling “debloat” of the blockchain state.
• adding replay attack protection.

Read the Ethereum Foundation announcement

• EIP-155 – prevents transactions from one Ethereum chain from being rebroadcasted on an alternative chain, for example a testnet transaction being replayed on the main Ethereum chain.
• EIP-160 – adjusts prices of EXP opcode – makes it more difficult to slow down the network via computationally expensive contract operations.
• EIP-161 – allows for removal of empty accounts added via the DOS attacks.
• EIP-170 – changes the maximum code size that a contract on the blockchain can have – to 24576 bytes.

The Tangerine Whistle fork was the first response to the denial of service (DoS) attacks on the network (September/October 2016) including:

• addressing urgent network health issues concerning underpriced operation codes.

Read the Ethereum Foundation announcement

• EIP-150 – increases gas costs of opcodes that can be used in spam attacks.
• EIP-158 – reduces state size by removing a large number of empty accounts that were put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol.

The DAO fork was in response to the 2016 DAO attack where an insecure DAO contract was drained of over 3.6 million ETH in a hack. The fork moved the funds from the faulty contract to a new contract with a single function: withdraw. Anyone who lost funds could withdraw 1 ETH for every 100 DAO tokens in their wallets.

This course of action was voted on by the Ethereum community. Any ETH holder was able to vote via a transaction on a voting platform. The decision to fork reached over 85% of the votes.

Some miners refused to fork because the DAO incident wasn't a defect in the protocol. They went on to form Ethereum Classic.

Read the Ethereum Foundation announcement

The Homestead fork that looked to the future. It included several protocol changes and a networking change that gave Ethereum the ability to do further network upgrades.

Read the Ethereum Foundation announcement

• EIP-2 – makes edits to contract creation process.
• EIP-7 – adds new opcode: DELEGATECALL
• EIP-8 – introduces devp2p forward compatibility requirements

The frontier thawing fork lifted the 5,000 gas limit per block and set the default gas price to 51 gwei. This allowed for transactions – transactions require 21,000 gas. The difficulty bomb was introduced to ensure a future hard-fork to proof-of-stake.

• Read the Ethereum Foundation announcement
• Read the Ethereum Protocol Update 1

Frontier was a live, but barebone implementation of the Ethereum project. It followed the successful Olympic testing phase. It was intended for technical users, specifically developers. Blocks had a gas limit of 5,000. This ‘thawing’ period enabled miners to start their operations and for early adopters to install their clients without having to ‘rush’.

Read the Ethereum Foundation announcement

Ether officially went on sale for 42 days. You could buy it with BTC.

Read the Ethereum Foundation announcement

The Yellow Paper, authored by Dr. Gavin Wood, is a technical definition of the Ethereum protocol.

View the Yellow Paper

The introductory paper, published in 2013 by Vitalik Buterin, the founder of Ethereum, before the project's launch in 2015.