merge – Earlybirds Invest

https://earlybirdsinvest.com Latest Crypto News Fri, 04 Jul 2025 14:59:00 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.11 https://i0.wp.com/earlybirdsinvest.com/wp-content/uploads/2024/12/cropped-New-Project-2024-12-17T235703.455.png?fit=32%2C32&ssl=1 merge – Earlybirds Invest https://earlybirdsinvest.com 32 32 240146708 CZ to merge ‘Wall Street and blockchain’ alongside Goldman, DTCC, Citadel https://earlybirdsinvest.com/cz-to-merge-wall-street-and-blockchain-alongside-goldman-dtcc-citadel/ https://earlybirdsinvest.com/cz-to-merge-wall-street-and-blockchain-alongside-goldman-dtcc-citadel/#respond Fri, 04 Jul 2025 14:59:00 +0000 https://earlybirdsinvest.com/cz-to-merge-wall-street-and-blockchain-alongside-goldman-dtcc-citadel/

Former Binance CEO Changpeng (CZ) Zhao’s YZi Labs has invested in Digital Asset, the institutional blockchain platform Canton Network developer.

YZi Labs joins a $135 million Series E round that was first announced on June 24 and includes participation from finance incumbents like Goldman Sachs, Citadel Securities, DRW, and the Depository Trust & Clearing Corporation (DTCC).

YZi Labs is the new name for what was formerly Binance Labs. It has been restructured into a family office to manage the personal wealth and investments of CZ, and Binance co-founder, Yi He. CZ described the investment as “merging Wallet Street and blockchain.”

The capital infusion from the $10 billion asset manager aligns a major crypto-native fund with established Wall Street entities, all backing a specific technological approach to enterprise blockchain.

The funding is directed at expanding the Canton Network, a platform designed to facilitate the tokenization of real-world assets for regulated financial institutions. It aims to resolve the persistent challenge of enabling blockchain operations while adhering to the strict privacy and compliance mandates of mature markets.

The network functions as a public Layer 1 with configurable privacy, a structure intended to offer an alternative to transparent public ledgers and siloed, private blockchains.

Digital Asset’s platform has demonstrated substantial activity according to Yzi Labs, with reports of it supporting over $1.5 trillion in monthly tokenized U.S. Treasury repo volume. The network currently involves nearly 400 participants from both decentralized and traditional finance sectors.

By allowing institutions to set specific privacy controls, the Canton Network addresses the core conflict between the need for financial confidentiality and the interoperability benefits of a shared ledger. The growth in real-world asset tokenization has been substantial, with the sector benefiting from increased institutional interest in bringing assets like bonds and private credit on-chain.

Ella Zhang, Head of YZi Labs, commented on the firm’s involvement.

“Through this investment, YZi Labs is proud to support the mission of bringing tokenized real-world assets into the financial mainstream, and to contribute to the broader goal of advancing global institutional adoption,” Zhang stated.

Her comments position the investment as a move to foster the foundational infrastructure required for merging traditional financial assets with blockchain technology.

The collaboration was also commented on by Digital Asset’s leadership.

“This investment from YZi Labs reinforces the growing demand for blockchain infrastructure that meets the rigorous standards of global financial markets,” said Yuval Rooz, Co-Founder and CEO of Digital Asset.

Rooz added that YZi Labs’ background in Web3 infrastructure and scaling emerging technologies makes it a suitable partner as Canton expands its reach. The stated goal for the capital is to enhance the Canton Network’s infrastructure, streamline the onboarding of new institutions, and support the interoperability required to manage a higher volume of real-world assets.

Over the next 12 to 18 months, the company plans for additional live deployments from major financial institutions and expansion into new global markets.

]]> https://earlybirdsinvest.com/cz-to-merge-wall-street-and-blockchain-alongside-goldman-dtcc-citadel/feed/ 0

45739

Amphora: A Major Merge Milestone https://earlybirdsinvest.com/amphora-a-major-merge-milestone/ https://earlybirdsinvest.com/amphora-a-major-merge-milestone/#respond Sat, 07 Jun 2025 09:22:30 +0000 https://earlybirdsinvest.com/amphora-a-major-merge-milestone/

Earlier this year, the Rayonism hackathon kicked off to protoype the architecture for Ethereum’s transition to proof of stake. The transition, often refered to as The Merge, will keep the existing beacon chain (eth2) and execution layer (eth1) clients, and “merge” both chains by making the beacon chain drive the execution layer’s consensus. This approach is the most recent in a series of iterations to the Ethereum roadmap (more on that here).

While Rayonism proved that this was a sound architecture, there were still several things left to design, implement and test, including the actual proof of work (PoW) to proof of stake (PoS) transition. To do so, client teams met face to face last week (analogous to the Eth2 Interop from 2019) for a workshop named Amphora .

Here is an overview of the main things that were accomplished during the workshop, and the path from here to The Merge.

Amphora Milestones

The purpose of the event was to get the execution and consensus layer client teams to iron out outstanding issues in the specification and reach a set of development milestones. Each milestone got clients closer to a fully functioning merge devnet which transitioned from PoW to PoS. Representatives of Besu, Erigon, EthereumJS, Geth, Nethermind, Nimbus, Lighthouse, Lodestar, Quilt and Teku attended the workshop in person. The Prysm team, along with several members from the aforementioned teams, participated remotely.

The Amphora Milestones aimed to first get clients conforming with the spec, then gradually adding more complexity and finally growing the amount of other clients they could interoperate with.

The first milestone, M1, only required clients to implement the merge specification. It was completed by most teams prior to the workshop even starting! To help clients validate their implementation, several – testing – suites were provided.

Then, milestones M2, M3 and M4 had client teams set up devnets with an increasing technical complexity and node diversity. M2 had execution layer (EL) and consensus layer (CL) teams pair one on one, and launch a post-merge devnet. This ensured that both layers could successfully communicate via the Engine API in a PoS context.

M3 is where the Amphora workshop moved a step beyond Rayonism: clients set up emphemeral devnets which ran through the PoW to PoS transition.

The transition is based on PoW difficulty: once a block’s difficulty equals or exceeds a specific value, called TERMINAL_TOTAL_DIFFICULTY, or TTD, it is considered the final PoW block. The execution layer then begins listening to the PoS consensus layer for new blocks. To ensure that each team’s implementation was robust, EL teams had to connect to two CL clients and vice-versa to pass M3.

M4 was the real target for the event: to get multiple EL & CL clients on a devnet which went through the entire PoW to PoS transition. In other words, while M3 was about one-to-one devnets, M4 was about many-to-many.

We achieved this for a subset of the teams before the end of the workshop, so we then went for our stretch goal: M5.

Lasting Artifacts

This milestone aimed to turn Amphora from a short-lived event to long(er)-lived infrastructure that the community could use. M5 required client teams to start a devnet that would not only run through the entire transition with all client combinations, but that would persist beyond the Amphora event.

On the last day of the workshop, minutes before the final dinner was served, M5 was hit: a network of 10,000 validators across 100 nodes and several client implementations launched under PoW, reached the TERMINAL_TOTAL_DIFFICULTY, transitioned to PoS, and successfully finalized the chain !

The M5 devnet successfully finalizes post-merge, minutes before the workshop’s closing dinner. Photo by Ben Edgington.

Beyond Amphora

Amphora’s success provides great momentum for The Merge. Client teams now have a clear list of tasks they need to work toward, and enough progress has been made to begin reaching out to a larger segment of the Ethereum community.

Yesterday, a more stable version of the M5 Amphora devnet, Pithos, was launched. Now that this network is live (explorer here), expect public calls exploring how developer tools and other core Ethereum infrastructure can best prepare for the PoW to PoS transition.

Client teams and researchers will keep iterating on The Merge specification to fix issues identified during Amphora and respond to feedback from the community. Within a few weeks the spec should be finalized and, soon after, a new stable testnet made available.

Thank you

The work accomplished during Amphora exceeded all of our expectations. For this, we want to thank the client teams and researchers, without whom, none of the specifications would have been written or implemented.

Additionaly, thanks to ConsenSys, Chainsafe and Ben Edgington for their excellent coverage of the workshop.

]]> https://earlybirdsinvest.com/amphora-a-major-merge-milestone/feed/ 0

40640

How The Merge Impacts Ethereum’s Application Layer https://earlybirdsinvest.com/how-the-merge-impacts-ethereums-application-layer/ https://earlybirdsinvest.com/how-the-merge-impacts-ethereums-application-layer/#respond Wed, 28 May 2025 17:26:57 +0000 https://earlybirdsinvest.com/how-the-merge-impacts-ethereums-application-layer/

Ethereum’s transition to proof of stake — The Merge — is near: devnets are being stood up, specifications are being finalized and community outreach has begun in earnest. The Merge is designed to have minimal impact on how Ethereum operates for end users, smart contracts and dapps. That said, there are some minor changes worth highlighting. Before we dive into them, here are a few links to provide context about the overall Merge architecture:

The rest of this post will assume the reader is familiar with the above. For those wanting to dig even deeper, the full specifications for The Merge are available here:

Block structure

After The Merge, proof of work blocks will no longer exist on the network. Instead, the former contents of proof of work blocks become a component of blocks created on the Beacon Chain. You can then think of the Beacon Chain as becoming the new proof of stake consensus layer of Ethereum, superseding the previous proof of work consensus layer. Beacon chain blocks will contain ExecutionPayloads, which are the post-merge equivalent of blocks on the current proof of work chain. The image below shows this relationship:

For end users and application developers, these ExecutionPayloads are where interactions with Ethereum happen. Transactions on this layer will still be processed by execution layer clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, due to the stability of the execution layer, The Merge introduces only minimal breaking changes.

Mining & Ommer Block Fields

Post-merge, several fields previously contained in proof of work block headers become unused as they are irrelevant to proof of stake. In order to minimize disruption to tooling and infrastructure, these fields are set to 0, or their data structure’s equivalent, rather than being entirely removed from the data structure. The full changes to block fields can be found in EIP-3675.

Field	Constant value	Comment
ommers	[]	RLP([]) = 0xc0
ommersHash	0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347	= Keccak256(RLP([]))
difficulty	0
nonce	0x0000000000000000

Because proof of stake does not naturally produce ommers (a.k.a. uncle blocks) like proof of work, the list of these in each block (ommers) will be empty, and the hash of this list (ommersHash) will become the RLP-encoded hash of an empty list. Similarly, because difficulty and nonce are features of proof of work, these will be set to 0, while respecting their byte-size values.

mixHash, another mining-related field, won’t be set to 0 but will instead contain the beacon chain’s RANDAO value. More on this below.

BLOCKHASH & DIFFICULTY opcodes changes

Post-merge, the BLOCKHASH opcode will still be available for use, but given that it will no longer be forged through the proof of work hashing process, the pseudorandomness provided by this opcode will be much weaker.

Relatedly, the DIFFICULTY opcode (0x44) will be updated and renamed to PREVRANDAO. Post-merge, it will return the output of the randomness beacon provided by the beacon chain. This opcode will thus be a stronger, albeit still biasable, source of randomness for application developers to use than BLOCKHASH.

The value exposed by PREVRANDAO will be stored in the ExecutionPayload where mixHash, a value associated with proof of work computation, was stored. The payload’s mixHash field will also be renamed prevRandao.

Here is an illustration of how the DIFFICULTY & PREVRANDAO opcodes work pre and post-merge:

Pre-merge, we see the 0x44 opcode returns the difficulty field in the block header. Post-merge, the opcode, renamed to PREVRANDAO, points to the header field which previously contained mixHash and now stores the prevRandao value from the beacon chain state.

This change, formalized in EIP-4399, also provides on-chain applications a way to assess whether The Merge has happened. From the EIP:

Additionally, changes proposed by this EIP allow for smart contracts to determine whether the upgrade to the PoS has already happened. This can be done by analyzing the return value of the DIFFICULTY opcode. A value greater than 2**64 indicates that the transaction is being executed in the PoS block.

Block time

The Merge will impact the average block time on Ethereum. Currently under proof of work, blocks come in on average every ~13 seconds with a fair amount of variance in actual block times. Under proof of stake, blocks come in exactly each 12 seconds except when a slot is missed either because a validator is offline or because they do not submit a block in time. In practice, this currently happens in <1% of slots.

This implies a ~1 second reduction of average block times on the network. Smart contracts which assume a particular average block time in their calculations will need to take this into account.

Finalized Blocks & Safe Head

Under proof of work there is always the potential for reorgs. Applications usually wait for several blocks to be mined on top of a new head before treating it as unlikely to be removed from the canonical chain, or “confirmed”. After The Merge, we instead have the concepts of finalized blocks and safe head exposed on the execution layer. These blocks can be used more reliably than the “confirmed” proof of work blocks but require a shift in understanding to use correctly.

A finalized block is one which has been accepted as canonical by >2/3 of validators. To create a conflicting block, an attacker would have to burn at least 1/3 of the total staked ether. While stake amounts may vary, such an attack is always expected to cost the attacker millions of ETH.

A safe head block is one which has been justified by the Beacon Chain, meaning that >2/3 of validators have attested to it. Under normal network conditions, we expect it to be included in the canonical chain and eventually finalized. For this block to not be part of the canonical chain, a majority of validators would need to be colluding to attack the network, or the network would have to be experiencing extreme levels of latency in block propagation. Post-merge, execution layer APIs (e.g. JSON RPC) will expose the safe head using a safe tag.

Finalized blocks will also be exposed via JSON RPC, via a new finalized flag. These can then serve as a stronger substitute for proof of work confirmations. The table below summarizes this:

Block Type	Consensus Mechanism	JSON RPC	Conditions for reorg
head	Proof of Work	latest	To be expected, must be used with care.
safe head	Proof of Stake	safe	Possible, requires either large network delay or attack on network.
confirmed	Proof of Work	N/A	Unlikely, requires a majority of hashrate to mine a competing chain of depth > # of confirmations.
finalized	Proof of Stake	finalized	Extremely unlikely, requires >2/3 of validators to finalize a competing chain, requiring at least 1/3 to be slashed.

Note: the JSON RPC specification is still under active development. Naming changes should still be expected.

Next Steps

We hope this post helps application developers prepare for the much-anticipated transition to proof of stake. In the next few weeks, a long-lived testnet will be made available for testing by the broader community. There is also an upcoming Merge community call for infrastructure, tooling and application developers to ask questions and hear the latest technical updates about The Merge. See you there

Thank you to Mikhail Kalinin, Danny Ryan & Matt Garnett for reviewing drafts of this post.

]]> https://earlybirdsinvest.com/how-the-merge-impacts-ethereums-application-layer/feed/ 0

38807

Announcing the Kintsugi Merge Testnet https://earlybirdsinvest.com/announcing-the-kintsugi-merge-testnet/ https://earlybirdsinvest.com/announcing-the-kintsugi-merge-testnet/#respond Sun, 25 May 2025 06:07:29 +0000 https://earlybirdsinvest.com/announcing-the-kintsugi-merge-testnet/

Since returning from the Amphora merge workshop, client teams have been hard at work implementing the latest versions of merge specifications and testing them on devnets.

After four ephemeral devnets, Kintsugi , a longer-lived public testnet, is now live!

Although client development and UX continue to be refined, we encourage the community to start using Kintsugi to familiarize themselves with Ethereum in a post-merge context. For application developers, as previously explained, not much will change. Tooling which only interacts with either the consensus or execution layer is also largely unaffected. Infrastructure which depends on both layers is most likely to need to adapt to support The Merge.

We recommend most projects begin testing and prototyping on Kintsugi to surface any potential issues soon. This way, changes can more easily be incorporated in future client and specification versions.

Using Kintsugi

Check out the Kintsugi landing page for information about interacting with the Kintsugi network. You’ll find network settings, a faucet, a block explorer and a JSON-RPC endpoint, along with documentation updated to reflect supported consensus <> execution layer client combinations.

As a reminder, post-merge, a full Ethereum client is comprised of both a Beacon / Consensus node and an Execution engine (handled by an existing “Eth1” client). Both layers maintain independent API endpoints and peer connections to handle their respective role. For a full overview of Ethereum’s post-merge architecture, see this post.

Support & Feedback

The EthStaker community is available to provide Kintsugi support. If you have questions, encounter errors or need clarifications, they are happy to provide assistance in the #testingthemerge channel of their Discord server.

With the launch of Kintsugi, we hope the community gets involved #TestingTheMerge. Check ou this list of test scenarios for ideas on how to bring your testing to the next level.

If you identify bugs or issues with the specification, the best place to raise these is in the #merge-general channel of the Ethereum R&D Discord server. If you’d rather not use Discord, other venues to raise such issues are the specification repositories (consensus, execution, APIs), and Ethereum Magicians .

Next Steps

The Kintsugi testnet provides the community an opportunity to experiment with post-merge Ethereum and begin to identify any issues. Once feedback has been incorporated into the client sofware and the specifications, a final series of testnets will be launched. In parallel, testing efforts will continue ramping up.

After this, existing long-lived testnets will run through The Merge. Once these have upgraded and are stable, next up is Ethereum mainnet’s transition to proof of stake .

For those eager to follow the progress at a more granular level, a mainnet readiness checklist is publicly available and regularly updated.

See you on Kintsugi !

]]> https://earlybirdsinvest.com/announcing-the-kintsugi-merge-testnet/feed/ 0

38179

Merge Pals Game Guide: Play, Earn, and Merge Your Way to Web3 Rewards https://earlybirdsinvest.com/merge-pals-game-guide-play-earn-and-merge-your-way-to-web3-rewards/ https://earlybirdsinvest.com/merge-pals-game-guide-play-earn-and-merge-your-way-to-web3-rewards/#respond Mon, 19 May 2025 18:26:30 +0000 https://earlybirdsinvest.com/merge-pals-game-guide-play-earn-and-merge-your-way-to-web3-rewards/

Merge Pals is a fast-growing Web3 game that combines the addictive satisfaction of merging mechanics with strategic play and blockchain incentives. Available as a Telegram Mini App and on LINE, this title has attracted over 3 million players by introducing familiar gameplay elements within an accessible Web3 environment.

Recently, Merge Pals announced its integration with the Ronin blockchain, signalling a major step in expanding its ecosystem and leveraging Ronin’s gaming-focused infrastructure. The LINE version of the game is built on the Kaia blockchain, bringing Web3 capabilities like token rewards and digital ownership to a mobile-native audience.

This article explores Merge Pals’ gameplay, NFT integration and whitelist events.

Key Takeaways

Merge Pals is a Web3 game merging pet collection, strategic gameplay, and blockchain-based assets.
Players collect and merge “Pals” to level up, earn rewards, and progress through missions and idle systems.
The game uses the $MERGE token for in-game transactions, with NFT Genesis Pals offering unique strategic enhancements and earning options.
Now part of the Ronin ecosystem, Merge Pals benefits from Ronin’s scalability and low-fee structure, which is ideal for blockchain gaming.
It’s accessible to both crypto-savvy players and traditional gamers via Telegram and LINE, operating across both Ronin and KaiaChain blockchains.

What Is Merge Pals?

Merge Pals is a Web3-powered game that runs as a Telegram Mini App and on LINE. With a growing user base that now exceeds 3 million, the game combines casual mechanics like collecting and upgrading virtual pets with blockchain features such as token-based rewards and NFTs.

By joining the Ronin Network, Merge Pals aligns itself with other leading blockchain games, aiming to deliver smooth user experiences and reliable asset ownership in a low-gas environment.

Players collect creatures called “Pals” through a gacha system. These Pals come in five rarities—Common, Rare, Epic, Legendary, and Mythic. The merging mechanic lets users combine two identical Pals to create a stronger version, encouraging long-term strategic planning.

Merge 1.png

How Merge Pals Works: Mechanics and Strategy

Merge Pals combines simple mechanics with deeper layers of strategy. Here’s how the core systems work:

Gacha System: Players acquire Pals using Gacha Tickets or Coins. A built-in “pity” mechanic guarantees higher rarity Pals after a specific number of pulls.
Merging Mechanic: Two identical Pals of the same rarity and level can be merged to create a stronger version, encouraging smart progression planning.
Mission Assignments: Levelled-up Pals are assigned to timed missions that return rewards like Coins, Fame, and more Gacha Tickets. Success rates depend on rarity and level.
Idle Gameplay with the House System: Pals not currently in use can be placed in the House to passively generate experience and resources over time.
Fast Quest and Fast Claim Features: These tools allow players to streamline daily tasks and reward collection, which is ideal for those who prefer quick, low-maintenance play sessions.

Merge Pals NFT Integration

Genesis Pals are the centrepiece of Merge Pals’ NFT system. These 5,000 unique NFTs, hosted on the Ronin blockchain, offer enhanced mission success rates, faster task completion, and better earning potential.

Each Genesis Pal can be upgraded to level 70 and awakened using a resource called Awakening Dust, unlocking improved performance and special visual effects.

Unlike even the highest rarity Mythic Pals, Genesis Pals provide blockchain-enabled ownership and income potential. They can also be rented out to other players or traded on NFT marketplaces, making them valuable digital assets with utility both in and beyond the game.

The Play to Whitelist Event

The Play to Whitelist event is one of Merge Pals’ signature community competitions, running from May 13, 2025, to May 22, 2025. This limited-time event may be part of a recurring series designed to boost engagement and NFT accessibility.

To participate, players must connect a Ronin or MetaMask wallet. The Ronin Wallet is recommended not only for a smoother experience but also because it aligns with the game’s new ecosystem.

After registration, players earn points through daily check-ins, completing quests and missions, gacha pulls, referring friends, and spending $MERGE tokens in-game.

The top 500 players on the leaderboard will receive guaranteed whitelist access. Other rewards include Awakening Dust, Gacha Tickets, and Fame. Even players outside the top 500 can collect valuable items by participating.

Keep in mind: the wallet used during registration will be permanently linked to the event. Accounts cannot be changed once entered, so choosing the right wallet is important.

Frequently Asked Questions (FAQ)

How do I start playing Merge Pals?

Search for Merge Pals on Telegram or LINE and start collecting Pals through the in-game gacha system.

What is the $MERGE token used for?

$MERGE is the in-game utility token used for progression, transactions, and accessing premium features.

What benefits do Genesis Pals provide?

Genesis Pals improve mission performance and rewards, can be awakened, and offer rental income opportunities.

Do I need a wallet to play?

No, but a wallet is needed for blockchain features like NFTs and whitelist events. Ronin Wallet is recommended.

Is Merge Pals suitable for non-crypto gamers?

Yes. The game introduces Web3 concepts through familiar mechanics and a user-friendly interface.

Summary

Merge Pals shows that Web3 games don’t have to be overwhelming or inaccessible. With easy entry via Telegram and LINE, engaging mechanics, and seamless NFT integration, it stands out in the blockchain gaming space.

Its cross-chain approach—using both Ronin and KaiaChain—offers better scalability, lower transaction costs, and access to distinct user bases across mobile and crypto-native audiences.

Events like Play to Whitelist keep the community involved and offer meaningful rewards for participation. Whether you’re a casual player or a blockchain enthusiast, Merge Pals provides an engaging entry point into the world of Web3 gaming.

]]> https://earlybirdsinvest.com/merge-pals-game-guide-play-earn-and-merge-your-way-to-web3-rewards/feed/ 0

37143

Announcing the Kiln Merge Testnet https://earlybirdsinvest.com/announcing-the-kiln-merge-testnet/ https://earlybirdsinvest.com/announcing-the-kiln-merge-testnet/#respond Sat, 17 May 2025 01:22:40 +0000 https://earlybirdsinvest.com/announcing-the-kiln-merge-testnet/

The Kintsugi merge testnet, launched late December, has been a valuable testing ground for The Merge. Through various test suites, multi-client devnets, shadow forks of Goerli, application deployments, and the community’s help #TestingTheMerge, we’ve arrived at a set of stable and robust protocol specifications. Now that clients have implemented these latest specs, a successor to Kintsugi, Kiln , is being launched!

Like the Ethereum mainnet, Kiln’s execution layer was launched under proof-of-work in parallel to a Beacon Chain running proof-of-stake. The Merge happened on Kiln on March 15, 2022. The network is now running entirely under proof-of-stake!

Kiln is expected to be the last merge testnet created before existing public testnets are upgraded. Application & tooling developers, node operators, infrastructure providers and stakers are strongly encouraged to test on Kiln to ensure a smooth transition on existing public testnets.

Kintsugi, the previous merge testnet, will be deprecated in the coming weeks.

Using Kiln

Getting Started

The easiest way to get started using Kiln is to visit the network’s landing page. There, you can add the network to your browser wallet, view block explorers, request funds from the faucet, and connect to a JSON RPC endpoint. If you’d like to be a validator on Kiln, the staking launchpad also supports the network.

Application & Tooling Developers

With Kiln going live, 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 impacts on a subset contracts deployed on Ethereum, none of which should be breaking. Additionally, the lion’s share of user API endpoints remain stable (that is, unless you are using PoW specific methods such as eth_getWork).

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

Node Operators

Post-merge, an Ethereum full node will be the combination of a consensus layer client, which runs proof-of-stake on the 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.

Node operators will thus need to run both a consensus and execution layer client in tandem. In other words, if you were already running a node on the Beacon Chain, you now need to also 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.

You can find the latest Kiln-supported release of clients here.

It is worth emphasizing that each layer will maintain an independent set of peers and expose its own APIs. The Beacon and JSON RPC APIs will thus both continue working as expected.

Stakers

As explained above, validators on the Beacon Chain will need to run an execution layer client after The Merge. Pre-merge, this was strongly recommended, but it was possible for validators to outsource 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 they create and attest to are valid. To do so, an execution layer client is required. 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 upgrade to be withdrawn, transaction fees will continue to be paid, burned, and distributed on the execution layer. Validators can thus specify any Ethereum address as a receipient for transaction fees.

Kiln is the perfect environment for existing stakers to familiarise themselves with the post-merge Ethereum context. We recommend trying to mirror your production setup on the network and ensuring that you work through any issues now.

Again, the staking launchpad provides a simple interface to get started. Note that as part of the renaming away from “eth2.0”, the ethereum/eth2.0-deposit-cli repository will soon be renamed to ethereum/staking-deposit-cli.

FAQ

wen merge?

A date for the Ethereum mainnet proof-of-stake transition has not been set as of the publication of this post. 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 Kiln, once clients have finalized the details of their implementations, the existing Ethereum testnets (Goerli, Ropsten, etc.) will run through The Merge. Once these have successfully transitioned and stabilized, again, assuming no issues are found, a difficulty value will be set for the mainnet transition. Only then will it be possible to estimate the exact date for The Merge.

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

No. If you want to try out Kiln, please do. We hope many community members will join us in #TestingTheMerge on Kiln.

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

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

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

As a validator, can I withdraw my stake?

No. The Merge is the most complicated upgrade to Ethereum to date. In order 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 available as of the first upgrade after The Merge. Specifications for both the consensus and execution layers are in progress.

Why Kiln?

The previous merge testnet, Kintsugi, was named after the Japanese art of breaking pottery and fixing it using gold, making it both stronger and more beautiful.

In a similar vein, a Kiln is a high-temperature oven used to turn clay into hardened objects, such as pottery or bricks .

]]> https://earlybirdsinvest.com/announcing-the-kiln-merge-testnet/feed/ 0

36654

Ropsten Merge Announcement https://earlybirdsinvest.com/ropsten-merge-announcement/ https://earlybirdsinvest.com/ropsten-merge-announcement/#respond Tue, 13 May 2025 05:34:49 +0000 https://earlybirdsinvest.com/ropsten-merge-announcement/

Ropsten will be the first longstanding testnet to run through The Merge
A new Ropsten Beacon Chain was launched on May 30, 2022 to provide consensus to the network
The Ropsten Beacon Chain will upgrade to merge-compatible protocol rules (Bellatrix) at slot 24000, expected on June 2, 2022
After this, a Terminal Total Difficulty (TTD) will be chosen to activate The Merge on the proof-of-work chain. Node Operators will need to manually set this value on their clients.
June 3 update: the exact Terminal Total Difficulty for the Ropsten Merge is 50000000000000000. A subsequent announcement explains how node operators and stakers can ensure their clients are ready for the upgrade. Please update your client’s TTD before June 7, 2022.

Background

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

Having tested client implementations on Kintsugi , Kiln and many shadow forks, client teams are now ready to run Ropsten — the oldest proof-of-work testnet — through The Merge. In preparation, a Ropsten Beacon Chain has been launched to provide consensus to the network.

After the Ropsten transition, two more testnets (Goerli and Sepolia) will be transitioned to proof-of-stake before focus shifts to mainnet. Other testnets, such as Rinkeby and Kovan, may be maintained and upgraded separately by the community but will no longer be monitored by client developers.

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

Given these circumstances, the Ropsten network, which is intended to be deprecated after The Merge, will run through the upgrade earlier in the development process than previous network upgrades. This will give the community more time to become familiar with the upgrade process.

Note: Client releases listed below will not be suitable for the Ethereum mainnet’s transition to proof-of-stake.

Upgrade Information

Timing

The Merge is a two-step process. It starts with a network upgrade on the consensus layer, triggered by a slot 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 2, 2022, at slot 24000, the Bellatrix upgrade will prepare the Ropsten Beacon Chain for The Merge. At that point, CL clients will begin 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 will first be set to an exceedingly high value, 100000000000000000000000. At Ropsten’s current hash rate, it would take ~250 years to reach it.

Once the Bellatrix upgrade has happened on the Beacon Chain, a new TTD value, which is expected to be reached a few days later, will be chosen and announced. Users will then need to configure their node with this new value. Instructions for doing so with each client are available here.

When this new TTD is hit or exceeded on Ropsten, the execution layer part of the transition, codenamed Paris, will start. Again, note that hash rate on Ropsten 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 Ropsten testnet. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

As mentioned above, the following releases have a hardcoded Terminal Total Difficulty value of 100000000000000000000000 which will need to be manually updated after the Bellatrix upgrade has been activated on the Beacon Chain.

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.

Note: if you had previously downloaded a client release with a Ropsten TTD of 43531756765713534, you must either update your release or manually override the TTD to 100000000000000000000000 as specified here.

Consensus Layer

Name	Version	Link
Lighthouse	Baby Wizard (2.3.0)	Download
Lodestar	See “Lodestar Note” below	See “Lodestar Note” below
Prysm	v2.1.3-rc.2	Download
Nimbus	v22.5.2	Download
Teku	v22.5.2	Download

Lodestar Note: the latest Lodestar release, v0.37.0, has an outdated Ropsten TTD value of 43531756765713534. To be compatible with the Ropsten Merge, which now uses a TTD of 100000000000000000000000, Lodestar users will need to manually override this value. Instructions about doing so can be found on the team’s release announcement post.

Execution Layer

Name	Version	Link
Besu	v22.4.2	Download
Erigon	v2022.06.01-alpha	Download
go-ethereum (geth)	See “Geth Note” below	See “Geth Note” below
Nethermind	v1.13.1	Download

Geth Note: the latest go-ethereum (geth) release, Sharblu (v1.10.18), has an outdated Ropsten TTD value of 43531756765713534. To be compatible with the Ropsten Merge, which now uses a TTD of 100000000000000000000000, geth users must either:

Build from source on the latest master branch
Use the latest Docker image
Manually override the TTD, by running the following command when starting the client: –override.terminaltotaldifficulty 100000000000000000000000.

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.

Finally, remember to check back on June 3rd for an announcement on this blog of the final Ropsten TTD value.

As a staker, what do I need to do?

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.

Testnet upgrades are the last chance for validators to ensure their setups work as expected and resolve issues. Information about running a validator on the Ropsten Beacon Chain in preparation for The Merge can be found on the Ropsten staking launchpad.

We strongly recommend that mainnet validators run through The Merge on Ropsten and other testnets before the Ethereum mainnet transitions to proof-of-stake.

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

With The Merge going live on Ropsten, 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.

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 Ropsten, 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 around June 8, 2022 on Ropsten 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 June 3, 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 Ropsten, once client testing is complete, Ethereum’s other testnets, will run through The Merge. Once Goerli and Sepolia have successfully transitioned and stabilized, a slot height will be chosen for the Bellatrix upgrade on the 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, .

]]> https://earlybirdsinvest.com/ropsten-merge-announcement/feed/ 0

35929

Sepolia Merge Announcement https://earlybirdsinvest.com/sepolia-merge-announcement/ https://earlybirdsinvest.com/sepolia-merge-announcement/#respond Mon, 05 May 2025 00:38:00 +0000 https://earlybirdsinvest.com/sepolia-merge-announcement/

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.

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.

Consensus Layer

Execution Layer

Name	Version	Link
Besu	See “Besu Note” below	See “Besu Note” below
Erigon	v2022.07.01	Download
go-ethereum (geth)	~~v1.10.20~~ master	See “Geth Note” below
Nethermind	1.13.4	Download

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?

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

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?

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.

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.

]]> https://earlybirdsinvest.com/sepolia-merge-announcement/feed/ 0

34437

Goerli/Prater Merge Announcement https://earlybirdsinvest.com/goerli-prater-merge-announcement/ https://earlybirdsinvest.com/goerli-prater-merge-announcement/#respond Fri, 02 May 2025 20:21:58 +0000 https://earlybirdsinvest.com/goerli-prater-merge-announcement/

For the last testnet proof-of-stake transition, Goerli will merge with Prater. The combined Goerli/Prater network will retain the Goerli name post-merge.
Bellatrix, the Prater upgrade readying it for The Merge will happen at epoch 112260, expected at 12:24PM UTC on August 4, 2022.
After Bellatrix is activated, the Goerli/Prater merge will happen when Goerli hits a total difficulty of 10790000, expected between August 6-12, 2022.
Post-merge, Goerli’s validator set will remain open for individual stakers to run testnets validators. Stakers who wish to start a Goerli/Prater validator can do so at the Prater Launchpad.

Background

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

After several devnets, shadow forks and merges on deprecated testnets, Sepolia was recently transitioned to proof-of-stake. Now, only one more testnet remains: Goerli, and its associated Beacon Chain, Prater.

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, named Bellatrix, at an epoch height on the Beacon Chain and the second, named Paris, upon hitting a Total Difficulty value on the execution layer.

Upgrade Information

Timing

The Merge is a two-step process. It starts with a network upgrade, Bellatrix, 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, Paris, triggered by a specific Total Difficulty threshold, called the Terminal Total Difficulty (TTD).

The Bellatrix upgrade is scheduled for epoch 112260 on the Prater Beacon Chain, expected at 12:24PM UTC on August 4, 2022. Paris, the execution layer’s portion of the transition, will trigerred by reaching a Terminal Total Difficulty (TTD) of 10790000 on Goerli, expected between August 6-12, 2022.

Client Releases

The following client releases support The Merge across the Goerli & Prater testnets. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

Consensus Layer

Execution Layer

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 (CL) client, which runs the proof-of-stake Beacon Chain, and an execution layer (EL) 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.

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?

The Goerli/Prater Merge is your last opportunity to ensure that your validators are correctly configured before the mainnet transition. Running through the transition now is strongly recommended to avoid any unexpected issues on mainnet.

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.

The Prater Staking Launchpad has a Merge Readiness Checklist that stakers can use to ensure they have gone through each step of the process. The EthStaker team is also hosting a Merge Validator Preparation Workshop on July 29.

Why is the estimate for the Terminal Total Difficulty date so broad?

The volatility in incremental difficulty per block makes estimating a window for the TTD harder than with a block or epoch height, hence the wider expected range. Users should note that this will also be the case for mainnet’s transition due to changes in proof-of-work hash rate.

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

With The Merge going live on Goerli, now is your last chance 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 Sepolia, 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.

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, you should be aware that the network will operate entirely under proof-of-stake after The Merge. At that point, mining will no longer be possible on the network.

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?

The EthStaker community has set up a discord channel to answer staker and node operator questions. You can join their discord here and then use the #goerli-prater channel for assistance. As mentioned above, EthStaker will also host a Merge Validator Preparation Workshop on July 29.

Additionally, a Merge Community Call is scheduled for August 12, 14:00 UTC. Client developers and researchers will be available to answer questions from node operators, stakers, infrastructure & tooling providers and community members. Note that this community call is expected to happen after the Goerli/Prater merge.

wen merge?

As of the publication of this post, the time 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 during the Goerli/Prater merge, once clients have feature-complete releases, a slot height will be chosen for the Bellatrix upgrade on the mainnet Beacon Chain and a total 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.

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

]]> https://earlybirdsinvest.com/goerli-prater-merge-announcement/feed/ 0

34048

Mainnet Merge Announcement https://earlybirdsinvest.com/mainnet-merge-announcement/ https://earlybirdsinvest.com/mainnet-merge-announcement/#respond Fri, 25 Apr 2025 21:22:48 +0000 https://earlybirdsinvest.com/mainnet-merge-announcement/

Ethereum is moving to proof-of-stake! The transition, known as The Merge, must first be activated on the Beacon Chain with the Bellatrix upgrade. After this, the proof-of-work chain will migrate to proof-of-stake upon hitting a specific Total Difficulty value.
The Bellatrix upgrade is scheduled for epoch 144896 on the Beacon Chain — 11:34:47am UTC on Sept 6, 2022.
The Terminal Total Difficulty value triggering The Merge is 58750000000000000000000, expected between Sept 10-20, 2022.
Note: as announced earlier, the Kiln testnet is being sunset. Operators will shut down on September 6, 2022.

Background

Following years of hard work, Ethereum’s proof-of-stake upgrade is finally here! The successful upgrade of all public testnets is now complete, and The Merge has been scheduled for the Ethereum mainnet.

The Merge is different from previous network 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, named Bellatrix, at an epoch height on the Beacon Chain, and the second, named Paris, upon hitting a Total Difficulty value on the execution layer.

Upgrade Information

Timing

The Merge is a two-step process. The first step is a network upgrade, Bellatrix, 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, Paris, triggered by a specific Total Difficulty threshold called the Terminal Total Difficulty (TTD).

The Bellatrix upgrade is scheduled for epoch 144896 on the Beacon Chain — 11:34:47am UTC on Sept 6, 2022.

Paris, the execution layer’s portion of the transition, will be triggered by the Terminal Total Difficulty (TTD) of 58750000000000000000000, expected between Sept 10-20, 2022. The exact date at which TTD is reached depends proof-of-work hash rate. Estimates for the transition can be found at bordel.wtf and 797.io/themerge.

Once the execution layer reaches or exceeds the TTD, the subsequent block will be produced by a Beacon Chain validator. The Merge transition is considered complete once the Beacon Chain finalizes this block. Under normal network conditions, this will happen 2 epochs (or ~13 minutes) after the first post-TTD block is produced!

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 by 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 Ethereum mainnet. Node operators must run both an execution and consensus layer client to remain on the network during and after The Merge.

Consensus Layer

Warning: Nimbus version v22.9.0 is a high-urgency upgrade that fixes a critical pre-TTD block production issue affecting users that restarted their node after Bellatrix. It also improves compatibility with Besu, Prysm and slow block builders and provides a speed boost in block processing important for those running on Raspberry Pi and similar hardware.

Warning: Lighthouse version v3.1.0 is a high-priority release contains an important fix to ensure that Lighthouse does not attempt to produce invalid blocks. The –strict-fee-recipient flag for the Lighthouse Validator Client has also been found to prevent block proposals in the period between the Bellatrix upgrade (Sept 6th) and the TTD date (estimated Sept 15th). We are presently inside that period of time and therefore all stakers using that flag are affected. We advise that anyone using the –strict-fee-recipient flag should remove it and restart the Validator Client as soon as possible. This does not affect the –suggested-fee-recipient flag.

Warning: Prysm v3.1.1 is a highly recommended update as it contains several important fixes and features for the merge.

Warning: Teku version 22.9.0 is a required update.

Execution Layer

Warning: Besu 22.7.2 is a recommended release for the Merge and Mainnet users. 22.7.1 remains Merge-ready. This release provides additional robustness before the Merge with some fixes and improvements in sync, peering, and logging.

Warning: Erigon version v2022.09.01-alpha fixes invalid block production due to insufficient verification of digital signature components, block snapshot production that sometimes occurs during POS reverse header download and a lot of smaller bugs and safety issues. All Erigon users are recommended to upgrade to this or a later version prior to the Merge.

Warning: geth version v1.10.22 contains a critical database issue, do not use this version, and if you have already upgraded, please upgrade to v1.10.23 as soon as possible.

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

Merge Bug Bounty Bonus

All Merge-related bounties for vulnerabilities have received a 4x multiplier between now and the 8th of September. Critical bugs are now worth up to $1 million USD.

See the bug bounty program for more details.

FAQ

As a node operator, what should I do?

Post-merge, an Ethereum full node is the combination of a consensus layer (CL) client which runs the proof-of-stake Beacon Chain and an execution layer (EL) client which manages the user-state and runs the computations associated with transactions. The EL and CL client 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 this value.

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?

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 some validators 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 must ensure that user transactions and state transitions 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. This expands validators’ responsibilities but also gives a validator who proposes a block the right to its associated transaction priority fees (which currently go to miners).

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

The Staking Launchpad has a Merge Readiness Checklist that stakers can use to ensure they have gone through each step of the process. EthStaker have also hosted Validator Prep Workshops, with more being planned.

Stakers who wish to run a validator on a testnet in preparation for the mainnet proof-of-stake transition can do so on Goerli (now merged with Prater), which also has a Staking Launchpad instance.

Why is the estimated date for the Terminal Total Difficulty so broad?

The incremental difficulty added per block is dependent on the network hash rate which is volatile. If more hash rate joins the network, TTD will be reached sooner. Similarly, if hash rate leaves the network, TTD will be reached later. In the event of a significant drop in hash rate levels, a TTD Override could be coordinated as was done on Ropsten.

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

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 Sepolia or Goerli 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, please 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?

Whether you are using Ethereum applications on-chain, holding Ether on an exchange or in a self-custodied wallet, you do not have to do anything. If an application, exchange or wallet you use offers additonal instructions or recommendations, you should verify these are actually coming from them. Be on the lookout for scams!

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

What happens if I am a miner 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-merge Ethereum network.

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?

Join client team developers, members of ETHStaker, researchers, and more on the next Merge Community Call on Friday, Sept 9 at 14:00 UTC!

Thank You

Ethereum’s transition to proof-of-stake has been a loooong time coming. Thank you to everyone who contributed to researching, specifying, developing, analyzing, testing, breaking, fixing, or explaining everything that got us to The Merge.

There have been far too many contributors over the years to list here, but you know who you are. Without all of you in the bazaar, we wouldn’t have built this cathedral.

wen merge? Very .

Thank you to Joseph Schweitzer and Tomo Saito for the cover image for this post!

]]> https://earlybirdsinvest.com/mainnet-merge-announcement/feed/ 0

32820