Written by: MVP Workshop

Ethereum Merge – Everything you need to know

The long-awaited transition to so-called “Ethereum 2.0” is almost here. In the upcoming days (~15th September, 2022), the Ethereum blockchain will switch its consensus mechanism from Proof-of-Work (POW) to Proof-of-Stake (POS) during the long-awaited event in the crypto community called The Merge. In this technical blog post, you will find out what precisely The Merge is, what you can expect both as a User and Buidler after it,  and when will it happen.

What is Ethereum Merge (The Merge)?

The Merge is one of the multiple steps toward upgrading Ethereum to be more secure, scalable, and efficient. If you haven’t already noted, the web3 community dropped the term “Ethereum 2.0” in favor of the “consensus layer” to avoid confusion since this process is more of a network upgrade rather than an entirely new blockchain. If you want to learn more about other steps besides The Merge, we highly recommend checking out this tweet from Vitalik Buterin.


It’s important to understand that The Merge will be an upgrade to a consensus layer. On this layer, it will no longer be miners propagating the blocks but staking validators. The execution layer will remain unchanged. The Merge will not solve the “high network fees” problem.

Brief history of Ethereum

Ethereum is a general-purpose blockchain network comprising decentralized computer nodes across the Globe. It differs from Bitcoin in that it has a smart contract functionality, meaning that you can not only send ether as a cryptocurrency but can also create any decentralized software.

It started with the exact consensus mechanism – Proof-of-Work (POW), which consumes too much energy. Ethereum will replace Proof-of-Work (POW) with Proof-of-Stake (POS) when The Merge occurs. You can read more about this change in one of our previous blogs.

Why is it called “The Merge”?

It all started with Phase 0 – The Beacon Chain

In a “post-merge” architecture, the Ethereum block will consist of two components:

  • Beacon Node (Consensus Layer, “Eth2 Client”): in charge of tracking the network head, gossips & attests to blocks; receives validators rewards.
  • Execution Engine (Execution Layer, “Eth1 Client”): in charge of processing new blocks, maintaining mempools, and managing and syncing state.
Post-merge client architecture. NFT. Artist: Danny Ryan
(credits: Tim Beiko)

The Beacon Chain, also known as the “system chain”, introduced staking. It is currently running alongside the main Ethereum POW chain. One of its primary purposes is to store and maintain a registry of validators. To remind us, validators are wallet addresses that locked exactly 32 ethers into the Ethereum Deposit contract. The consensus mechanism of the Beacon Chain is Proof-of-Stake (POS).

The simplified block of the current Ethereum POW chain looks like this:

(credits: Tim Beiko)

The simplified block of the Beacon Chain looks like this:

(credits: Tim Beiko)

For Ethereum to switch to Proof-of-Stake, the simplified block should look like this:

A post-merge block: the consensus layer (a.k.a. Beacon Node) validates all the fields currently part of Beacon Chain blocks. It passes ExecutionPayloads to the execution layer for validation as it receives them on the network.
(credits: Tim Beiko)

Therefore, these two chains need to merge, which is exactly what The Merge event is all about. The Beacon Chain, which currently validates empty blocks, will merge with the main Ethereum POW chain and continue to operate as the main chain, switching Ethereum’s consensus mechanism to Proof-of-Stake (POS).

The Merge refers to the moment when Ethereum’s existing blockchain and the Beacon Chain join together to form one unified chain
PoW blocks stop appearing and Beacon Chain blocks begin to hold ExecutionPayloads after The Merge.
(credits: Tim Beiko)

The Merge will introduce another change. There will be an execution layer responsible for transaction handling, transaction gossip, state management, the Ethereum Virtual Machine (EVM), and a consensus layer responsible for block building & gossiping, and handling consensus logic.

Historically it was enough to run an Ethereum client, such as Geth, to be part of the Ethereum blockchain as a full node. Now there is a need for a consensus client as well.

(credits: consensys.net)

What does “The Merge” mean for dApp and Smart Contract developers?

The Merge is undoubtedly one of the most important events in the history of Web3 and targets every single author in the ecosystem, from developers to end-users. This section covers how it will affect dApp and Smart Contract developers.

Deprecation of some Test Networks

The Merge is a very complex process that includes a lot of testing. Naturally, some of the tests happened on various Ethereum Test Networks. Although the majority of them went to a phase of transitioning to Proof-of-Stake, not all of them will survive The Merge. 

Ethereum Test Networks after The Merge will be Goerli and the newly created Sepolia. Rinkeby, Ropsten, and Kovan are deprecated.
Consider moving away from those test networks because other projects, including Node providers such as Alchemy or Infura, will also stop supporting them.

No more Proof-of-Work

If you are a miner, there will be no more officially supported Ethereum POW chains. It is possible to create a POW fork of the Ethereum mainnet, but the Ethereum Foundation and the majority of the protocols on Ethereum won’t support it. If you want to build on the Proof-of-Work chain, there is Ethereum Classic.

Deprecation of some block fields

Several block fields used for Proof-of-Work will be set to zero (0) because they will become irrelevant and no longer be used. This change was introduced in EIP-3675.

Block fields that will be set to zero, or their data structure’s equivalent:

  • ommers (will be set to [])
  • ommersHash (will be set to keccak256 value of RLP([]))
  • difficulty (will be set to 0)
  • nonce (will be set to 0x0000000000000000)

No further action required for dApp & Smart Contract developers.


When you were writing Solidity code for the Ethereum POW, one of the sources for pseudo-randomness was block.difficulty , which existed as a global variable. This variable was used for getting the current difficulty level of the Proof-of-Work algorithm, named Ethash. That was done via 0x44 opcode, called DIFFICULTY.

To keep the backwards compatibility, the Ethereum Foundation introduced EIP-4399 which supplanted the DIFFICULTY opcode with the PREVRANDAO opcode, since in the “post-merge” world, the difficulty field in the block must be set to zero.

If you used block.difficulty, there is no need for action in general – your code should work. However, keep in mind that the range of this variable is now 0-2^256 while previously it was 0-2^64.

Keep in mind that PREVRANDAO is not truly random! Even if you used block.difficulty  previously, you should really stop with that practice because contracts that use pseudo-random values are vulnerable to MEV attacks.

For example, validators who are chosen to propose new blocks will be able to know the value of the PREVRANDAO opcode. Therefore, they can calculate the pseudo-random value using the same logic from your smart contract. 

The solution to this problem is to use existing VRF infrastructures such as Chainlink VRF.

Avoid using BLOCKHASH opcode

The BLOCKHASH (0x40) opcode will still be available. However, given that it will no longer be forged through the proof of work hashing process, the pseudo-randomness provided by this opcode will be much weaker. Of course, as already said, pseudo-randomness on the blockchain should be avoidable whenever possible.

BLS Signatures supplanted ECDSA Signatures

After The Merge, Ethereum will switch from Elliptic Curve Digital Signature Algorithm (ECDSA) to Boneh-Lynn-Shacham (BLS) cryptographic signatures because they are more efficient for aggregation of validators’ signatures.

This change is important because one million BLS signatures on the same message can be verified in about the same amount of time as a single signature on that message, which is an essential optimization.

Block time will be shorter

The Merge will impact the average block time on Ethereum. Currently, this value on a Mainnet is around 13 seconds per block. After The Merge, this value will be exactly 12 seconds.

If your smart contracts assume a particular average block time in their calculations, you should consider this change.

Finalized Blocks

The good practice when deploying smart contracts to the blockchain is to wait for a couple of blocks to be mined on top of the head because of the potential chain reorgs. After that, we considered that it is safe to use this contract and proceed with further actions such as Etherscan verification or transferring smart contract ownership to multisigs.

After The Merge, the finalized block will be the one that has been accepted as canonical by >2/3 of validators. It will be exposed via JSON RPC with the “finalized” tag. A safe head block will be the one which, under normal network conditions, we expect to be included in the canonical chain.

It will be exposed via JSON RPC with the “safe” tag. Safe head blocks are similar to POW head blocks, which are being exposed via JSON RPC with the “latest” tag, but are less likely to be reorganized.

If you use the “latest” tag in your tests or scripts, consider switching to the “safe” tag. Also, notice that a new tag is created, called “finalized”.

How to use Hardhat with The Merge

Hardhat, the framework for developing smart contracts, introduced new features in the latest release to support writing test scenarios for projects that will be deployed to the Mainnet after The Merge. To try it, you should first upgrade to the 2.11.0 version or greater. Then you should set your network configuration as described:

networks: {
    hardhat: {
        hardfork: “merge”

Your code should work fine without any further modifications. However, you can now try new changes, such as triggering the PREVRANDAO opcode. You can manually set it in your tests using the setPrevRandao network helper function or the hardhat_setPrevRandao RPC method.

Hardhat Network’s JSON RPC now accepts the new “safe” and “finalized” block tags, which in Hardhat Network are just aliases for the “latest” tag and correspond to the latest block.

If you want to read more about how The Merge will impact Ethereum’s Application Layer, this article is a good source.

Ethereum merge date?

There is no official merge date per se. The Merge has been scheduled for TTD 58750000000000000000000, which will happen approximately in the middle of September 2022 but the time can’t be precisely predicted.

Terminal Total Difficulty (TTD) specifies the final, terminal Proof of Work block, after which the PoS consensus (implemented in the Beacon Chain) takes over. When TTD is reached or exceeded, the final block will be mined, and then Proof of Stake will take over block production.

(source: github.com/ethereum/annotated-spec

What’s the Ether price prediction after The Merge?

As a user or holder of ETH or any other digital asset on Ethereum, you do not need to do anything with your crypto or wallet before The Merge.

However, you should take into consideration that the current annual ether issuance is 5.4 Million ETH per year which is expected to drop to about 500,000 ETH per year after The Merge.

On top of that, EIP-1159 introduced a new way of ETH burning mechanism, which removes a small portion of ethers used for a gas fee from circulation permanently.

Are there any risks?

There are always risks when making a significant change to a protocol that many people use. As said on ethmerge.com:

The Merge can be thought of as replacing the engine of an airplane while it is still flying.

However, the Beacon Chain is operated without issues so far. The Merge happened on many shadow forks and test networks, therefore being well tested.

There are several consensus clients to increase client diversity and decentralization. And the Ethereum community is actively participating in the process since everything is publicly available and the codebase is open-sourced.

Guides, articles, and news

RWA Marketplace Validation Use Case – Tokenized RWAs are yet to take off

As the bull market kicks off, we are seeing exciting new trends taking over the market from DePINs, tokenized RWA,


ZKSIM – Revolutionizing ZK Circuit Testing

The development of zero-knowledge (ZK) circuits is an intricate process, with testing posing a considerable challenge that often extends timelines


FHE Project comparison

As the adoption of this transformative technology continues to grow, so does the emergence of innovative projects harnessing its capabilities.

get in touch

Contact us

Whether you are a web3 builder with a new project to show the world, or a talent looking to contribute to our team, we are always open to new collaborations.

Please enable JavaScript in your browser to complete this form.