• Note: on July 5, 2022, the recommended releases for go-ethereum and Erigon were modified. See “Client Releases” for details.
• Sepolia will be the second of three public testnets to run through The Merge.
• The network will transition to proof-of-stake when the total difficulty on the proof-of-work chain exceeds 17,000,000,000,000,000, which is expected to occur around in the next few days.
• Post-merge, Sepolia will have a permissioned validator set, like existing proof-of-authority testnets. Goerli/Prater, which will merge at a later date, will maintain an open validator set to allow for stakers to test the transition.

Background

After years of work to bring proof-of-stake to Ethereum, we are now well into the final testing stage: testnet deployments!

With Ropsten already transitioned to proof-of-stake and shadow forks continuing regularly, Sepolia is now ready for The Merge. After Sepolia, only Goerli/Prater will need to be merged before moving to mainnet. Other testnets will be considered deprecated post-merge, as explained in a recent post.

The Merge is different from previous Ethereum upgrades in two ways. First, node operators need to update both their consensus layer (CL) and execution layer (EL) clients in tandem, rather than just one of the two. Second, the upgrade activates in two phases: the first at an epoch height on the Beacon Chain and the second upon hitting a Total Difficulty value on the execution layer.

Sepolia has already run through the Bellatrix upgrade on the Beacon Chain. We now announce the details of the second phase of the transition: hitting the Terminal Total Difficulty.

Upgrade Information

Timing

The Merge is a two-step process. It starts with a network upgrade on the consensus layer, triggered by an epoch height. This is followed by the execution layer’s transition from proof-of-work to proof-of-stake, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).

On June 20, 2022, at epoch 100, the Bellatrix upgrade prepared the Sepolia Beacon Chain for The Merge. At that point, CL clients began listening for a TTD value to be hit on the proof-of-work chain.

Because the hash rate of proof-of-work testnets is very volatile, the TTD value was first set to an exceedingly high value, 100000000000000000000000. At Sepolia’s current hash rate, it would take hundreds of years to reach this value.

With Bellatrix now live, an updated TTD value of 17000000000000000 has been chosen for the transition. It is expected to be hit within the next few days. When this new TTD is hit or exceeded, the execution layer part of the transition, codenamed Paris, will start. Again, note that hash rate on Sepolia is notoriously variable, so the actual time at which the Terminal Total Difficulty takes place may fluctuate.

Once the execution layer has exceeded the TTD, the next block will be solely produced by a Beacon Chain validator. We consider The Merge to have been completed once the Beacon Chain has finalized this block. Assuming normal network conditions, this should happen 2 epochs, or approximately 13 minutes, after the first post-TTD block is hit!

A new JSON-RPC block tag, finalized, returns the latest finalized block or an error if no such post-merge block exists. This tag can be used for applications to check if The Merge has been completed. Similarly, smart contracts can query the DIFFICULTY opcode (0x44), renamed to PREVRANDAO post-merge, to determine if The Merge has happened. We recommend infrastructure providers monitor overall network stability in addition to finalization status.

Client Releases

The following client releases support The Merge on the Sepolia testnet. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

When choosing which client to run, validators should be especially mindful of the risks of running a majority client on both the EL and CL. An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.

Consensus Layer

Execution Layer

Besu Note: to be compatible with the Sepolia merge, Besu users will need to perform a manual Terminal Total Difficulty override. To do so, users should run the latest Besu release, 22.4.3 as of the publication of this post, and do the following:

• If using TOML configuration files, add the following line: override-genesis-config=[“terminalTotalDifficulty=17000000000000000”]
• If starting the node using the CLI, add the following flag: –override-genesis-config=”terminalTotalDifficulty=17000000000000000″

More information about overriding the TTD can be found in the Ropsten TTD Announcement.

Geth Note: a regression introduced in go-ethereum v1.10.20 makes it unsuitable for use as part of the Sepolia merge. Users of Geth should instead run the master branch until a new release is out. Instructions to do so are available here.

Upgrade Specifications

Consensus-critical changes for The Merge are specified in two places:

• The consensus layer changes, under the bellatrix directory of the consensus-specs repository
• The execution layer changes, under the Paris spec in the execution-specs repository

In addition to these, two other specifications cover how the consensus and execution layer clients interact:

• The Engine API, specified in the execution-apis repository, is used for communication between the consensus and execution layers
• Optimistic Sync, specified in the sync folder of the consensus-specs repository, is used by the consensus layer to import blocks as the execution layer client is syncing and to provide a partial view of the head of the chain from the former to the latter

FAQ

As a node operator, what should I do?

Post-merge, an Ethereum full node will combine a consensus layer client, which runs the proof-of-stake Beacon Chain, and an execution layer client, which manages the user-state and runs the computations associated with transactions. These communicate over an authenticated port using a new set of JSON RPC methods called the Engine API. The EL and CL client authenticate each other using a JWT secret. Node operators should refer to their clients’ documentation for instructions about how to generate and configure these.

In other words, if you were already running a node on the Beacon Chain, you now also need to run an execution layer client. Similarly, if you were running a node on the current proof-of-work network, you will need to run a consensus layer client. For them to communicate securely, a JWT token must be passed to each client.

It is worth emphasizing that while they are both part of consensus layer client releases, running a Beacon Node is distinct from running a Validator Client. Stakers must run both, but node operators only need the former. This post explains the difference between both components in more detail.

Also, note that each layer will maintain an independent set of peers and expose its own APIs. The Beacon and JSON RPC APIs will both continue working as expected.

As a staker, what do I need to do?

Sepolia’s validator set is permissioned, so unless you have already been included as a Sepolia validator, no action is required.

Goerli/Prater’s transition to proof-of-stake, which will be announced at a later date, will be open to all validators. Below are some notes to prepare for this. Again, no action is required now.

As explained above, validators on the Beacon Chain will need to run an execution layer client after The Merge, in addition to their consensus layer clients. Pre-merge, this was strongly recommended, but validators could have outsourced these functions to third-party providers. This was possible because the only data required on the execution layer were updates to the deposit contract.

Post-merge, validators need to ensure that transactions in blocks that they create and attest to are valid. To do this, each beacon node must be paired with an execution layer client. Note that multiple validators can still be paired to a single beacon node & execution layer client combo. While this expands validators’ responsibilities, it also gives a validator who proposes a block the right to its associated transaction priority fees (which currently go to miners).

While validator rewards accrue on the Beacon Chain and will require a subsequent network upgrade to be withdrawn, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can specify any Ethereum address as a recipient for transaction fees.

After updating your consensus client, be sure to set the fee recipient as part of your validator client configurations to ensure transaction fees are sent to an address you control.

If you have staked using a third-party provider, it is up to your selected provider to specify how these fees are allocated.

If you would like to test running a validator on post-merge Ethereum, instructions are available on the Ropsten staking launchpad.

As an application or tooling developer, what should I do?

With The Merge going live on Sepolia, now is the time to ensure that your product works as expected through the proof-of-stake transition and in a post-merge context. As explained in a previous post, The Merge will have only minimal impact on a subset of contracts deployed on Ethereum, none of which should be breaking. Additionally, the lion’s share of user API endpoints remain stable (unless you use proof-of-work specific methods such as eth_getWork).

That said, most applications on Ethereum involve much more than on-chain contracts. Now is the time to ensure that your front-end code, tooling, deployment pipeline and other off-chain components work as intended. We strongly recommend that developers run through a complete testing & deployment cycle on Ropsten (or Kiln) and report any issues with tools or dependencies to those projects’ maintainers. If you are unsure where to open an issue, please use this repository.

Additionally, you should note that all testnets aside from Sepolia and Goerli will be deprecated post-merge. If you are a user of Ropsten, Rinkeby or Kiln, you should plan to migrate to Goerli or Sepolia. More information about this can be found here.

As an Ethereum user or Ether holder, is there anything I need to do?

No. The Ethereum mainnet is not affected by this testnet. Subsequent announcements will be made on this blog before mainnet’s transition.

As a miner, is there anything I need to do?

No. If you are mining on the Ethereum mainnet or Sepolia, you should be aware that each network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.

This is expected in the next few days on Sepolia and later this year for the Ethereum mainnet.

As a validator, can I withdraw my stake?

No. The Merge is the most complicated upgrade to Ethereum to date. To minimize risks of network disruptions, a minimal approach was taken which excluded any non-transition changes from this upgrade.

Withdrawals from the Beacon Chain will likely be introduced in the first upgrade after The Merge. Specifications for both the consensus and execution layers are in progress.

I have more questions, where can I ask them?

A Merge Community Call is scheduled for July 15, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members.

wen merge?

As of the publication of this post, the date for the Ethereum mainnet proof-of-stake transition has not been set. Any source claiming otherwise is likely to be a scam. Updates will be posted on this blog. Please stay safe!

Assuming no issues are found with Sepolia, once client testing is complete, Ethereum’s other EL testnet, Goerli, will run through The Merge with the Prater CL testnet. Once Goerli/Prater have successfully transitioned and stabilized, an epoch will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a difficulty value will be set for the mainnet transition. Clients will then make releases that enable The Merge on mainnet. These will be announced on this blog and in other community publications.

This assumes no issues are found. However, if issues are found at any point in the process or test coverage is judged to be insufficient, these things will be addressed before continuing with the deployment process.

Only then will it be possible to estimate the exact date for The Merge.

In other words, .

---

Thank you to Justin Chrn for the cover image.

• The Sepolia testnet will undergo a post-merge execution layer (EL) upgrade at block 1735371, expected on August 17, 2022
• The upgrade will cause EL clients on the network to disconnect from peers which have not transitioned to proof-of-stake. It does not add additional functionality beyond this.
• Sepolia node operators must upgrade their execution layer client prior to block 1735371.
• A similar upgrade is expected on Goerli and the Ethereum mainnet once these networks have transitioned to proof-of-stake

Background

In order to maintain a healthy peer list, nodes on Ethereum’s execution layer will automatically disconnect peers who do not have the same upgrade sequence as them. On the Ethereum mainnet, this means checking whether a peer upgrded to Frontier Thawing at block 200,000, then Homestead at block 1,150,000, and so on all the way to the latest upgrade, Gray Glacier, which happened at block 15,050,000. EIP-2124 specifies how this is handled. In typical network upgrades, which are triggered by a block height, this happens automatically as nodes use the block height of upcomming upgrades to filter peers.

For The Merge, this was not possible because the upgrade was triggered using a total difficulty value rather than a block number. The rationale for this choice is explained in EIP-3675:

Using a pre-defined block number for the hardfork is unsafe in this context due to the PoS fork choice taking priority during the transition.

An attacker may use a minority of hash power to build a malicious chain fork that would satisfy the block height requirement. Then the first PoS block may be maliciously proposed on top of the PoW block from this adversarial fork, becoming the head and subverting the security of the transition.

To protect the network from this attack scenario, difficulty accumulated by the chain (total difficulty) is used to trigger the upgrade.

To minimize changes to the protocol during its most complex upgrade since launch, the design for The Merge excluded EIP-2124 compatibility. This means an additional upgrade must now be done to add this. It is important to note that the only change introduced as part of this upgrade is specifying a block number that nodes can use to identify peers who have gone through The Merge. No other functionality is introduced or deprecated as part of this upgrade.

Upgrade Information

Timing

This upgrade will happen on Sepolia at block 1735371, expected on August 17, 2022.

Note that a similar upgrade will be announced for Goerli and mainnet after these networks have transitioned to proof-of-stake.

Ropsten will not be upgraded since it is now considered deprecated, along with Rinkeby and Kiln. See this post for more details on their deprecation schedule.

Client Releases

Only execution layer clients need to be updated for this upgrade. Node operators can keep running their current consensus layer client release on Sepolia through the transition.

Note that client releases used for the Goerli/Prater merge all support this upgrade on Sepolia. In other words, if you already downloaded a release for the Goerli/Prater merge, you can use that same version on Sepolia for this upgrade.

Execution Layer

Upgrade Specifications

The specification for this change is tracked as part of the Paris specifications, under the FORK NEXT Upgrade section.

FAQ

As a node operator, what should I do?

You should upgrade your execution layer client to one of the versions listed above before August 16, 2022. Your consensus layer client does not need to be upgraded.

As a staker, what do I need to do?

The validator set on Sepolia is permissioned. If you are part of the current Sepolia validators, you must update your execution layer client to one of the versions listed above on August 16, 2022 at the latest.

If you are not part of the current Sepolia validator set, you do not need to do anything at this time.

Goerli/Prater and mainnet validators will need to follow the same steps when this upgrade is announced on those networks.

As an application or tooling developer, what should I do?

Nothing, unless you are also running a node. If so, please upgrade your execution layer client to one of the versions listed above before August 16, 2022.

As an Ethereum user or Ether holder, is there anything I need to do?

No. The Ethereum mainnet is not affected by this upgrade. Even when this upgrade will be applied to mainnet, there won’t be any action needed.

---

Thank you to Justin Chrn for the original cover image and Tomo Saito for the modifications.

• Withdrawals are coming! The Shapella network upgrade will activate on the Sepolia network at epoch 56832, scheduled for 4:04:48 AM UTC on Feb. 28, 2023
• Stakers & node operators should read this post as well as the Withdrawals FAQ
• The Zhejiang testnet can be used to test Shapella functionality prior to the Sepolia upgrade

---

After months of testing and an ephemeral devnet launch, the Shanghai/Capella (a.k.a. Shapella) network upgrade is now scheduled for deployment on Sepolia.

This upgrade follows The Merge and enables validators to withdraw their stake from the Beacon Chain back to the execution layer. It also introduces new functionality to both the execution and consensus layer.

Upgrade Specification

The Shapella upgrade combines changes to the execution layer (Shanghai), consensus layer (Capella) and the Engine API.

Shanghai

Execution layer changes included in Shanghai are available here. For reference, they are:

Note that EIP-6049 is only a deprecation warning. Client teams expect SELFDESTRUCT semantics to change in future network upgrades, but the opcode’s behavior remains unchanged in Shanghai.

Additionally, the changes can now be viewed in the Ethereum Execution Layer Specification (EELS), which is a new Python reference implementation for the execution layer.

Capella

Changes to the consensus layer for the Capella upgrade are specified in the capella directory of the v1.3.0-rc.3 specifications. At a high level, the upgrade introduces:

• Full and partial withdrawals for validators
• BLSToExecutionChange messages, which allow validators using a BLS_WITHDRAWAL_PREFIX to update it to an ETH1_ADDRESS_WITHDRAWAL_PREFIX, a prerequisite for withdrawals
• Independent state and block historical accumulators, replacing the original singular historical roots

Stakers are encouraged to read the Withdrawal FAQ for more information on how they should prepare for Capella.

Client Releases

The following client releases support Shanghai & Capella on the Sepolia testnet. Note that these releases are only for Sepolia. A subsequent announcement will be made for the Goerli and mainnet releases.

When choosing which client to run, validators should be especially mindful of the risks of running a majority client on both the EL and CL. An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.

Consensus Layer Sepolia Releases

Execution Layer Sepolia Releases

Note: go-ethereum has put out a new recommended release, v1.11.2, for the upgrade. v1.11.1 is also compatible with the Shapella Sepolia upgrade.

FAQ

As an Ethereum user or Ether holder, is there anything I need to do?

In short, no.

If you use an exchange, digital wallet or hardware wallet, you do not need to do anything unless you are informed to take additional steps by your exchange or wallet provider.

If you run your own Ethereum node, see the “As a non-staking node operator, what do I need to do?” section below.

As a non-staking node operator, what do I need to do?

To be compatible with the Shapella upgrade on the Sepolia testnet, update your node to the version of your Ethereum client listed in the table above.

As a staker, what do I need to do?

To be compatible with the Shapella upgrade on the Sepolia testnet, update your node to the version of your Ethereum client listed in the table above.

We recommend reading the Withdrawal FAQ. Additionally, you can test things on the ephemeral Zhejiang testnet prior to the upgrade activating on Sepolia.

What happens if I am a staker or node operator and I do not participate in the upgrade?

If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the upgrade occurs.

You will be stuck on an incompatible chain following the old rules and will be unable to send Ether or operate on the post-Shapella Sepolia network.

As an application or tooling developer, what should I do?

Shapella does not introduce breaking changes for smart contracts. Application and tooling developers should review the upgrade changes to ensure any fixes are done, or to understand how to use newly introduced functionality.

Why “Shapella”?

Upgrades to the execution layer follow Devcon city names and those to the consensus layer follow star names. “Shapella” is the combination of Shanghai, the location of Devcon 2, and Capella, the brightest star in the northern constellation of Auriga.

---

Cover image by Yiran Ding

Important update: since the initial publication of this post, Lodestar has published a new release, v1.15.0, which Holesky users must upgrade to prior to Dencun’s activation on February 7th. Additionally, Prysm and Nimbus have both published highly recommended releases for Holesky. Prysm users are encouraged to use v4.2.1, and Nimbus users v24.2.0.

---

• Goerli blobs are here: Dencun went live on Goerli at 6:32 UTC on January 17, 2024. You can now use blobs there!
• Sepolia and Holesky will upgrade over the next two weeks. Dencun will activate on Sepolia at epoch 132608 (January 30th, 22:51 UTC), and on Holesky at epoch 29696 (February 7th, 11:35 UTC).
• Client releases in this announcement are suitable for both testnet upgrades.
• Assuming the Sepolia and Holesky upgrades go well, Dencun will be scheduled on the Ethereum mainnet next.
• To receive an email alert for network upgrade announcements, including the Dencun mainnet one, subscribe here.

---

The Dencun network upgrade has successfully activated on the Goerli testnet on January 17, 2024. It is now scheduled for the two remaining testnets, Sepolia and Holesky, at the following times:

The upgrade includes several changes, most notably the introduction of ephemeral data blobs with EIP-4844, also known as “protodanksharding”, which will help reduce L2 transaction fees.

Dencun follows last year’s Shapella upgrade. It will first be deployed to Ethereum testnets. Once these all are smoothly running the upgrade, Dencun will be scheduled for deployment on the Ethereum mainnet.

Upgrade Specification

The Dencun upgrade combines changes to both Ethereum’s consensus and execution layers. The full list of protocol changes can be found in EIP-7569. For reference, they are:

Deneb

Complete python specifications for changes affecting Ethereum’s consensus layer can be found in the deneb folder of the ethereum/consensus-specs repository.

Cancun

The EIPs linked above contain the full specifications for changes affecting Ethereum’s execution layer.

Additionally, a python specification for these is being implemented in the ethereum/execution-specs repository.

Lastly, Deneb requires changes to the Engine API, used for communication between the consensus and execution layer nodes. These are specified in the cancun.md file of the ethereum/execution-apis repository.

Client Releases

The following client releases support Dencun on both Sepolia and Holesky. Further versions will activate support on mainnet. Once these are released, another announcement will be made on this blog.

When choosing which client to run, validators should be especially mindful of the risks of running a majority client on either the execution layer (EL) or consensus layer (CL). An explainer of these risks and their consequences can be found here. An estimate of current EL and CL client distribution and guides for switching from one client to another can be found here.

Consensus Layer Sepolia & Holesky Releases

Notes:

• Holesky Lodestar v1.15.0-rc.0 users must upgrade to v1.15.0.
• Holesky Nimbus v24.1.2 users are highly encouraged to upgrade to v24.2.0.
• Holesky Prysm v4.2.1-rc.1 users are highly encouraged to upgrade to v4.2.1.
• When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.

Execution Layer Sepolia & Holesky Releases

Note: while Reth supports Dencun, the client is still pending a full audit and is not recommended for production use. See the Reth README for more context.

FAQ

As an Ethereum user or Ether holder, is there anything I need to do?

In short, no.

If you use an exchange, digital wallet or hardware wallet you do not need to do anything unless you are informed to take additional steps by your exchange or wallet provider.

If you run your own Ethereum node, see the next question.

As a non-staking Sepolia or Holesky node operator, what do I need to do?

To be compatible with the upgrade on either testnet, update your node’s execution and consensus layer clients to the versions listed in the table above.

As a Sepolia or Holesky staker, what do I need to do?

To be compatible with the upgrade on either testnet, update your node’s execution and consensus layer clients to the versions listed in the table above. Make sure both your beacon node and validator client are updated.

As a non-Sepolia or Holesky node operator or staker, what do I need to do?

Nothing for now. Further announcements will be made for Dencun’s activation on mainnet. You can sign up to receive an email alert for them here.

Stakers who want to run through the upgrade process more times before mainnet are encouraged to use ephemery.dev, which now supports Dencun.

What happens if I am a Sepolia or Holesky staker or node operator and I do not participate in the upgrade?

If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the upgrade occurs.

You will be stuck on an incompatible chain following the old rules and will be unable to send Ether or operate on the post-Dencun Ethereum network.

As an application or tooling developer, what should I do?

Review the EIPs included in Dencun to determine if and how they affect your project — there are many new exciting features being introduced across both the execution and consensus layers! The only EIPs with backwards compatibility implications are EIP-6780, EIP-7044 and EIP-7514.

Why “Dencun”?

Upgrades to the consensus layer use star names, and those to the execution layer follow Devcon city names. “Dencun” is the combination of Deneb, a first-magnitude star in the Cygnus constellation, and Cancun, the location for Devcon 3.

---

Original cover image by Darren Lawrence, with modifications by Tomo Saito.

At 7:29 UTC today, on epoch 222464, the Pectra network upgrade went live on the Sepolia testnet.

Unfortunately, an issue with Sepolia’s permissioned deposit contract prevented many execution layer clients from including transactions in blocks. The root cause was identified within minutes, and client teams immediately began working on a fix.

This issue is due to Sepolia’s configuration and could not occur on the Ethereum mainnet.

Around 14:00 UTC today, validators deployed a fix that restored the network to normal throughput.

All Sepolia node operators must now upgrade their execution layer clients to the versions listed below to maintain network compatibility.

---

Execution Layer Sepolia & Holesky Releases

---

This post will be updated with any further developments regarding the Sepolia Pectra deployment.

A postmortem will be available in the Pectra project management folder once the incident is resolved.

Ethereum’s long-awaited Pectra upgrade took a major step forward early Wednesday with its successful deployment on the Sepolia test network.

The biggest upgrade to Ethereum since 2024, Pectra consists of 11 major features, or “Ethereum improvement proposals” (EIPs), that will be shipped all at once. Together, the features aim to enhance staking, wallet functionality, and overall network efficiency.

Sepolia’s Pectra upgrade, which was completed at 07:29:36 UTC, followed a failed test on Ethereum’s Holesky testnet last week. A misconfiguration among validators resulted in a chain split, rendering Holesky temporarily unusable.

Testnets mimic a main blockchain and are used by developers to test code changes in a low-stakes environment. Holesky, which has a validator structure closer to Ethereum’s mainnet than Sepolia, was seen as a critical proving ground for Pectra. (Developers are still working to get Holesky back into operation and have set up an alternative developer network as a temporary testing ground for validators.)

Ethereum developers are set to meet on Mar. 6 to discuss Pectra’s mainnet release timeline. With only one fully successful test, developers may opt to delay the mainnet deployment to ensure stability.

One key Pectra proposal that will benefit Ethereum validators is EIP-7251, which increases the maximum amount of ETH one can stake from 32 to 2,048. The change is meant to address today’s clunky staking system, where validators who stake more than their 32 ETH must split their stake across multiple nodes.

Another highly-anticipated proposal, EIP-7702, would let crypto wallets temporarily function as smart contracts. The change moves Ethereum closer to account abstraction, enabling wallets to offer more user-friendly features. For example, users could pay transaction fees in stablecoins instead of ETH, set up automatic payments for subscriptions, or recover access to their wallets without relying on complex seed phrases.

Pectra’s rocky test cycle comes as Ethereum’s developers are under pressure to ship upgrades more quickly. Some Ethereum fans fear the network is losing its edge to newer chains like Solana, which has gained mindshare in recent months due to its popularity among meme coin users.

The price of ETH has also recently underperformed relative to other major coins, and the Ethereum Foundation—the non-profit steward of the network’s development—has been beset by leadership drama.

Read more: Ethereum’s Pectra Upgrade Goes Live on ‘Holesky’ Testnet, but Fails to Finalize