Analyzing Ethereum's upcoming hard fork: the Pectra upgrade

2025.02.07

Analyzing Ethereum's upcoming hard fork: the Pectra upgrade

The Prague/Electra (Pectra) upgrade is scheduled for March 2025.

2025.02.07 - 02:38:20

以太坊

Navigating Web3 tides with focused insights

The Prague/Electra (Pectra) upgrade is scheduled for March 2025.

Authors: Sergey Boogerwooger, Dmitry Zakharov, MixBytes

Translated by: AI Translator, Luniverse Community

Introduction

In our previous articles, we reviewed the lifecycle of Ethereum validators in detail and discussed several aspects related to the upcoming Electra hard fork. Now, it's time to focus on the changes introduced by the upcoming Electra and Prague upgrades and explain them thoroughly.

The history of Ethereum 2.0’s “Proof-of-Stake” hard fork is complex. It began with adding a beacon layer alongside the existing execution layer, where Proof-of-Stake consensus was launched while the execution layer remained under Proof-of-Work (Phase0 and Altair hard forks). Then, during the Bellatrix hard fork, PoS was fully activated (though withdrawals were not yet enabled). The Capella hard fork later enabled withdrawals, completing the validator lifecycle. The most recent Deneb hard fork (part of the Dencun (Deneb/Cancun) upgrade) made minor adjustments to beacon chain parameters such as attestation time windows, processing voluntary exits, and validator churn limits. The main changes in Dencun occurred at the execution layer, introducing blob transactions, blob gas, KZG commitments for blobs, and deprecating the SELFDESTRUCT opcode.

Now, the Prague/Electra (i.e., Pectra) hard fork introduces significant upgrades to both the execution and consensus layers. As auditors of the Lido project, we primarily focus on consensus and staking-related changes in this hard fork. However, we cannot ignore the execution-layer changes in Prague, as they include important features affecting the Ethereum network and validators. Let’s dive into the details of these changes.

High-Level Overview of Pectra

Electra introduces numerous features to the beacon layer. Key updates include:

Allowing validator effective balances to vary between 32 and 2048 ETH (instead of a fixed 32 ETH).
Allowing validators to initiate exits via a secondary "withdrawal" credential (no longer requiring an active validator key).
Changing how the beacon layer processes Eth1 deposits (no longer parsing events from the deposit contract).
Adding a new generic framework for handling requests from regular Eth1 contracts on the beacon layer (similar to pre-Electra deposit management).

Meanwhile, Prague introduces the following changes to the execution layer:

A new precompiled contract supporting the BLS12-381 curve for zkSNARK proof verification (in addition to the popular BN254 curve).
A new system contract for storing and accessing up to 8192 historical block hashes (very useful for stateless clients).
Increasing calldata gas costs to reduce block size and encourage projects with calldata-heavy operations (like rollups) to migrate to blobs introduced in Dencun.
Supporting more blobs per Eth1 block and providing APIs to read these quantities.
Allowing EOAs (externally owned accounts) to have their own account code, greatly expanding what EOAs can do—such as executing multicalls or delegating execution to other addresses.

Let us now refer to the relevant Ethereum Improvement Proposals (EIPs) for further discussion:

EIP-7251: Increase MAX_EFFECTIVE_BALANCE
EIP-7002: Execution Layer Triggerable Exits
EIP-6110: On-Chain Validator Deposit Processing
EIP-7549: Move Committee Index Out of Attestation
EIP-7685: Generic Execution Layer Requests
EIP-2537: Precompiles for BLS12-381 Curve Operations
EIP-2935: Save Historical Block Hashes in State
EIP-7623: Increase Calldata Cost
EIP-7691: Increase Blob Throughput
EIP-7840: Add Blob Scheduling to EL Configuration
EIP-7702: Set EOA Account Code

Some of these EIPs mainly concern the consensus (beacon) layer, while others relate to the execution layer. Some span both layers, as certain operations (like deposits and withdrawals) require synchronized changes between consensus and execution layers. Due to this interdependence, separating Electra and Prague is impractical. We will therefore review each EIP in turn and specify which Ethereum components are affected.

EIP-7251: Increase MAX_EFFECTIVE_BALANCE

Reference: EIP-7251

Since the initial Phase0 hard fork preparing Ethereum for Proof-of-Stake until before Electra, the maximum effective balance for validators has been fixed at 32 ETH. Activating a validator required at least spec.min_activation_balance (32 ETH). After activation, validators started with this maximum effective balance but could reduce their effective balance down to spec.ejection_balance (16 ETH), at which point they would be ejected. This “minimum” logic remains unchanged in Electra, but now spec.max_effective_balance has increased to 2048 ETH. Therefore, validators can deposit anywhere between 32 and 2048 ETH to activate, and all such amounts will contribute to their effective balance. This shift marks a transition from “32ETH-staking” to true “staking” :)

This variable effective balance will now be used for:

Increasing the probability of becoming a block proposer, proportional to effective balance
Increasing the probability of joining the sync committee, proportional to effective balance
Serving as the basis for calculating relative slashing and inactivity penalties

The first two activities are the most rewarding for validators. Thus, after Electra, validators with larger stakes will participate in block proposing and sync committees more frequently, proportionally to their effective balance.

Another impact relates to slashing. All slashing penalties scale proportionally with a validator’s effective balance:

Both “immediate” and “delayed” slashing penalties are larger for validators with higher stakes.
“Delayed” penalties for validators co-signed with a slashed validator also increase, as the “slashed” portion of total stake becomes larger.
Validators who report a high-balance slashed validator receive a larger share of the slashed amount.

Electra also proposes changes to the slashing reward ratio, defining the fraction of a slashed validator’s balance that goes to the whistleblower.

Next comes the impact on inactivity. When an active validator (proposing or attesting) goes offline, inactivity scores accumulate, leading to periodic inactivity penalties. These penalties also scale proportionally with the validator’s effective balance.

Due to the increased effective balance, the validator “churn limit” has also changed. In pre-Electra Ethereum, validators typically had identical effective balances, and the churn limit was defined as “at most 1/65536 (spec.churn_limit_quotient) of the total stake can exit per epoch.” This created a “fixed” number of exiting validators with equal stakes. However, post-Electra, even a few “whale” validators exiting may represent a significant portion of the total stake.

Another consideration is rotating many validator keys on a single validator instance. Large validators are currently forced to run thousands of validator keys on one instance to accommodate large stakes, split into 32 ETH portions. With Electra, this behavior is no longer mandatory. Financially, this change has little impact, as rewards and probabilities scale linearly with stake. Thus, 100 validators each with 32 ETH are equivalent to one validator with 3200 ETH. Additionally, multiple active validator keys can share the same Eth1 withdrawal credential, allowing all rewards to be withdrawn to a single ETH address, avoiding gas costs associated with merging rewards. However, managing many keys incurs additional operational overhead.

The ability to aggregate validator balances introduces a new type of execution layer request. Previously, we had deposits and withdrawals. Now, there will be another type: consolidation requests. It merges two validators into one. The operation request includes the source validator’s public key and the target public key and will be processed similarly to deposits and withdrawals. Consolidations will also have pending queues and balance churn limits, just like deposits and withdrawals.

To summarize:

For small independent validators, Electra introduces the ability to automatically increase their effective balance (and rewards). Previously, any surplus beyond 32 ETH could only be withdrawn, but after Electra, this surplus will eventually contribute to their effective balance. However, effective balance can only increase in multiples of spec.effective_balance_increment (1 ETH), meaning increases occur only upon reaching the next “1 ETH threshold.”
For large independent validators, Electra offers significant operational simplification by allowing consolidation of multiple active validator keys into one. While not game-changing, running one 1x2048 stake is undoubtedly simpler than managing 64x32 stakes.
For liquid staking providers who collect small stakes from users and distribute them across validators, Electra adds more flexibility in stake allocation schemes but requires significant reengineering of accounting systems based on fixed 32 ETH effective balances.

Another important topic is validator historical data and profit estimation, especially relevant for new participants trying to assess risks and returns. Pre-Electra (as of writing), the 32 ETH cap (both minimum and maximum in practice) created uniformity in historical data. All validators had identical effective balances, rewards, individual slashing penalties, block proposal frequency, and other metrics. This uniformity allowed Ethereum to test its consensus mechanism without statistical outliers, gathering valuable network behavior data.

Post-Electra, stake distribution will undergo major changes. Large validators will participate more frequently in block proposals and sync committees, face heavier penalties during slashing events, and exert greater influence on delayed slashing, activation queues, and exit queues. While this may pose challenges for data aggregation, Ethereum’s consensus ensures non-linear computations remain minimal. The only non-linear component uses sqrt(total_effective_balance) to calculate base rewards, which applies uniformly to all validators. This means validator rewards and penalties can still be estimated on a “per 1 ETH” basis (or more precisely, per spec.effective_balance_increment, which might change in the future).

For more details, see our earlier article on validator behavior.

EIP-7002: Execution Layer Triggerable Exits

Reference: EIP-7002

Each validator in Ethereum has two key pairs: an active key and a withdrawal key. The active public BLS key serves as the validator’s primary identity on the beacon chain. This key pair is used to sign blocks, attestations, slashings, sync committee aggregates, and (prior to this EIP) voluntary exits (to initiate consensus exit after a delay). The second key pair (“withdrawal credential”) can either be another BLS key pair or a standard Eth1 account (private key and address). Currently, withdrawals to an ETH address require a withdrawal message signed by the active BLS private key. This EIP changes that.

In practice, the owners of these two (active and withdrawal) key pairs can differ. The active key is responsible for validation duties—running servers, keeping them online, etc.—while the withdrawal credential is typically controlled by the staker who receives rewards and manages funds. Currently, only the staker controlling the withdrawal credential cannot initiate validator exit; they can only withdraw rewards. This allows the active key owner to effectively hold the validator’s balance “hostage.” Validators can “pre-sign” exit messages and hand them to stakers, but this workaround is far from ideal. Moreover, both withdrawals and exits currently require interaction with the beacon layer validator via specialized APIs.

The optimal solution is to allow stakers to perform both withdrawals and exits through standard smart contract calls. This involves standard Eth1 signature checks and greatly simplifies operations.

This EIP enables stakers to trigger withdrawals and exits by sending a standard transaction from their ETH address to a dedicated smart contract (similar to the existing deposit process using the “deposit” contract). The withdrawal (or exit when sufficient stake is removed) proceeds as follows:

The staker sends a withdrawal request (“in” request) to the system’s “withdrawal” contract.
The contract charges a specific fee (in ETH) to mitigate potential malicious attacks and, similar to EIP-1559, increases fees when the request queue is busy.
The contract stores the “in” withdrawal/exit request in its storage.
When a block is proposed to the beacon layer, the queued “in” withdrawal/exit requests are retrieved from storage.
The beacon layer processes the “in” requests, interacts with the active validator’s balance, schedules the validator exit, and forms an “out” withdrawal request.
The “out” withdrawal request is processed at the execution layer, and the staker receives their ETH.

While deposits are operations triggered in Eth1 blocks and then “moved” to the beacon layer via a “pending” deposit queue, withdrawals followed a different scheme—they were triggered on the beacon layer (via CLI) and then “moved” to Eth1 blocks. Now, both schemes will operate through the same generic framework (described below): creating requests at the Eth1 layer, processing “pending” deposit/withdrawal/consolidation queues, and handling them at the beacon layer. For “output” operations like withdrawals, output queues will also be processed, and results settled in Eth1 blocks.

With this EIP, stakers can use regular ETH transactions to withdraw and exit their validators without directly interacting with validator CLI or accessing validator infrastructure. This greatly simplifies staking operations, especially for large staking providers. Validator infrastructure can now be nearly fully isolated, requiring only maintenance of active validator keys, while all staking operations can be handled elsewhere. It eliminates the need for solo stakers to wait for active validator actions and significantly simplifies off-chain components of services like Lido’s Community Staking Module.

Thus, this EIP “completes” staking operations, fully migrating them to the Eth1 layer, significantly reducing infrastructure security risks, and enhancing decentralization for solo staking initiatives.

EIP-6110: On-Chain Validator Deposit Processing

Reference: EIP-6110

Currently, deposits are implemented via events in the system “deposit” contract (as detailed in prior articles). The contract accepts ETH and validator credentials, emits a “Deposit()” event, which is later parsed and converted into deposit requests on the beacon layer. This system has many drawbacks: it requires voting on eth1data at the beacon chain layer, causing significant delays. Additionally, the beacon layer must query the execution layer, adding further complexity. These issues are discussed in detail in the EIP. A simpler approach, avoiding many of these problems, is to directly include deposit requests at a designated location within Eth1 blocks. This mechanism resembles the withdrawal processing flow described in the previous EIP.

The changes proposed in this EIP are promising. eth1data processing can now be completely removed, eliminating the need for voting or long delays (currently around 12 hours) between events on the Eth1 side and deposit inclusion on the beacon layer. It also removes the logic for deposit contract snapshots. This EIP simplifies deposit processing and aligns it with the withdrawal processing scheme described above.

For stakers and validators, these changes significantly reduce the delay between deposit and validator activation. When validators are slashed, necessary replenishments will also be faster.

There isn’t much more to say about this EIP except that it removes outdated logic, simplifies the process, and creates better outcomes for all stakeholders.

EIP-7685: Generic Execution Layer Requests

Reference: EIP-7685

This EIP should have preceded the previous three EIPs related to deposits/withdrawals/consolidations, as it lays the foundation for them. However, it is presented here to emphasize the growing need for consistent movement of specialized data between Eth1 (execution) and beacon (consensus) chain blocks (layers). This EIP affects both layers, making request processing triggered by regular ETH transactions more efficient. Currently, we observe:

Deposit events in Eth1 blocks are “moved” to beacon blocks for processing.
Withdrawal requests in beacon blocks (using CLI) are “moved” to Eth1 blocks for processing.
Validator consolidations need to be processed, which is also an Eth1→beacon request.

These three operations highlight the need for consistent handling of various request types when transitioning between execution and beacon layers. Moreover, we need the ability to trigger these operations solely via the Eth1 layer, as this would allow isolation of validator infrastructure from staking management infrastructure, improving security. Therefore, a generic solution for managing such requests is both practical and necessary.

This EIP establishes a framework for at least three main cases: deposits, withdrawals, and consolidations. That’s why earlier EIPs introduced fields like WITHDRAWAL_REQUEST_TYPE and DEPOSIT_REQUEST_TYPE—now consolidation will add another field, CONSOLIDATION_REQUEST_TYPE. Additionally, this EIP may include a generic mechanism for rate-limiting such requests (referencing constants: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

While detailed implementation specifics of this framework are not yet available, it will certainly include key request types, integrity mechanisms (e.g., hashing and Merkleizing requests), and pending queue handling with rate limiting.

This EIP has architectural significance, enabling Eth1 to trigger critical operations in the beacon layer through a unified framework. For end users and projects, this means all requests triggered at the Eth1 layer will be passed and processed on the beacon layer more efficiently.

EIP-2537: Precompiles for BLS12-381 Curve Operations

Reference: EIP-2537

If you don’t want to go deep, think of BLS12-381 precompiles as complex cryptographic “hash” operations now usable in smart contracts. For those interested, let’s dive deeper.

Mathematical operations on elliptic curves like BLS12-381 (and its counterpart BN-254) are currently used mainly for two purposes:

BLS signatures, where a special operation called “pairing” is used to verify these signatures. BLS signatures are widely used by validators because they allow aggregation of multiple signatures into one. Validators rely on BLS signatures based on the BLS12-381 curve (although they can also be implemented using any pairing-friendly curve like BN254).
zkSNARK proof verification, where pairing is used to verify proofs. Additionally, KZG commitments for large blobs introduced in the Dencun hard fork also use pairing to verify blob commitments.

If you want to verify BLS signatures or zkSNARK proofs in a smart contract, you must compute these “pairings,” which is computationally very expensive. Ethereum already has a precompiled contract for BN254 curve operations (EIP-196 and EIP-197). However, the BLS12-381 curve (now considered more secure and more widely used today) has not yet been implemented as a precompile. Without such a precompile, implementing pairing and other curve operations in a smart contract requires massive computation—as shown here—and consumes enormous gas (~10^5 to 10^6 gas).

This EIP opens doors for many potential applications, particularly cheap BLS signature verification based on the BLS12-381 curve. This makes it possible to implement threshold schemes for various purposes. As noted, Ethereum validators already use BLS12-381-based signatures. With this EIP, standard smart contracts can now efficiently verify aggregated validator signatures. This can simplify consensus proofs and cross-network asset bridging, since BLS signatures are widely used in blockchains. Threshold BLS signatures themselves enable building many efficient threshold schemes for voting, decentralized random number generation, multisig, etc.

Cheaper zkSNARK proof verification will in turn unlock numerous applications. Many zkSNARK-based solutions are currently hindered by high proof verification costs, making certain projects nearly impractical. This EIP has the potential to change that.

EIP-2935: Save Historical Block Hashes in State

Reference: EIP-2935

This EIP proposes storing 8192 (approximately 27.3 hours) of historical block hashes in the blockchain state, providing extended history for stateless clients (like rollups) and smart contracts. It suggests preserving the current behavior of the BLOCKHASH opcode, maintaining the 256-block limit, while introducing a new system contract specifically designed to store and retrieve historical hashes. This contract performs set() operations when processing blocks at the execution layer. Its get() method is accessible to anyone, retrieving the desired block hash from a circular buffer.

Currently, referencing historical block hashes in the EVM is possible but limited to the most recent 256 blocks (about 50 minutes). However, accessing older block data is crucial in some cases, especially for cross-chain applications (which need to prove data from prior blocks) and stateless clients, which regularly need access to earlier block hashes.

This EIP extends the time window available to rollups and cross-chain applications, allowing them direct access to historical data within the EVM without external collection. Thus, these solutions become more robust and sustainable.

EIP-7623: Increase Calldata Cost

Reference: EIP-7623

Calldata cost regulates the available size of transaction payloads, which can be large in some cases (e.g., when passing large arrays or binary buffers as parameters). Significant calldata usage is primarily attributed to rollups, which send payloads via calldata containing the current rollup state.

Introducing large, provable binary data onto the blockchain is crucial for rollups. The Dencun (Deneb-Cancun) upgrade introduced a major innovation for such use cases—blob transactions (EIP-4844). Blob transactions have their own dedicated “blob” gas fee; although their body is temporarily stored, their cryptographic proof (KZG commitment) along with its hash is integrated into the consensus layer. Therefore, blobs provide a better solution for rollups compared to storing data in calldata.

Encouraging rollups to move their data to blobs can be achieved via a “carrot and stick” approach. Reduced blob gas fees serve as the “carrot,” while this EIP acts as the “stick” by increasing calldata costs, thereby discouraging excessive data storage in transactions. This EIP complements the next EIP-7691 (Blob Throughput Increase), which raises the maximum number of blobs allowed per block.

EIP-7691: Blob Throughput Increase

Reference: EIP-7691

Blobs were introduced in the previous Dencun hard fork, and the initial values for maximum and target “per-block” blob counts were conservative estimates. This was due to the complexity of predicting how the p2p network would handle large binary objects propagating among validator nodes. Previous configurations have proven effective, making this a suitable time to test new values. Previously, the target/maximum blob count per block was set at 3/6. These limits are now increased to 6/9 respectively.

Combined with the previous EIP-7623 (increased calldata cost), this adjustment further incentivizes rollups to move their data from calldata to blobs. Work on finding optimal blob parameters continues.

EIP-7840: Add Blob Scheduling to EL Configuration

Reference: EIP-7840

This EIP proposes adding the target and maximum “per-block” blob counts (discussed above) and the baseFeeUpdateFraction value to the Ethereum Execution Layer (EL) configuration. It also enables clients to retrieve these values via node APIs. This feature is particularly useful for tasks like estimating blob gas fees.

EIP-7702: Set EOA Account Code

Reference: EIP-7702

This is a very important EIP that will bring significant changes to Ethereum users. As we know, EOAs (externally owned accounts) cannot have any code but can provide transaction signatures (tx.origin). In contrast, smart contracts have bytecode but cannot actively produce a direct signature “from them.” Any user interaction requiring additional, automatic, and verifiable logic can currently only be executed by calling an external contract to perform the desired operation. However, in this case, the external contract becomes the msg.sender for subsequent contracts, resulting in calls “from contract, not user.”

This EIP introduces a new SET_CODE_TX_TYPE=0x04 transaction type (we previously had old type 0x1 transactions, new 0x02 transactions from Berlin and EIP-1559 upgrades, and 0x03 blob transactions introduced in Dencun). This new transaction type allows setting code for an EOA account. Effectively, it allows an EOA to “execute external code within the context of its own EOA account.” From an external perspective, during a transaction, the EOA appears to “borrow” code from an external contract and execute it. Technically, this is achieved by adding a special authorization data tuple to the “code” storage of the EOA address (this “code” storage was always empty for EOAs before this EIP).

Currently, this EIP proposes that the new 0x04 transaction type contains an array:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Each element allows the account to use code from the specified address (from the last valid authorization item). When processing such a transaction, the given EOA’s code is set to a special value 0xef0100 || address (23 bytes), where address points to the contract with the desired code, || denotes concatenation, and 0xef0100 is a special magic value that regular smart contracts cannot contain (according to EIP-3541). This magic value ensures the EOA cannot be treated as a regular contract nor called like one.

When this EOA initiates a transaction, the specified address will be used to invoke the corresponding code within the EOA’s context. While full implementation details of this EIP are not yet clear, it is certain to bring significant changes.

A major impact is the ability to perform multicalls directly from an EOA. Multicalls are an ongoing trend in DeFi, and many protocols offer this as a powerful tool (e.g., Uniswap V4, Balancer V3, or Euler V2). With this EIP, multicalls can now be initiated directly from an EOA.

For example, this new feature solves a common inefficiency in DeFi: approve() + anything() requiring two separate transactions. This EIP enables general “pre-authorization” logic, allowing operations like approve(X) + deposit(X) to be completed in a single transaction.

Another advantage is the concept of sponsorship—delegating transaction execution “on behalf of” an EOA. Sponsorship is frequently discussed and highly desired to help new users enter Ethereum.

Programmable logic associated with an EOA unlocks many possibilities, such as implementing security restrictions, setting spending caps, enforcing KYC requirements, etc.

Of course, this shift raises many design questions. One issue is the use of chain_id, determining whether a signature is valid across multiple networks depending on whether it is included in the signature. Another complex issue is choosing between using the target code’s address versus embedding actual bytecode. Each method has unique characteristics and limitations. Additionally, nonce usage plays a key role in defining whether permissions are “multi-use” or “single-use.” These elements affect functionality and security, including batch invalidation of signatures and usability. Vitalik raised these issues in a discussion (here), worth exploring further.

Notably, this change impacts a security mechanism in Ethereum: tx.origin. More details on the implementation of this EIP are needed, but it appears the behavior of require(tx.origin == msg.sender) will change. This check has been the most reliable way to ensure msg.sender is an EOA, not a contract. Other methods, such as checking EXTCODESIZE (to verify if it’s a contract), often fail and can be circumvented (e.g., by calling constructors or deploying code at predefined addresses post-transaction). These checks are used to prevent reentrancy and flash loan attacks but are far from ideal, as they also hinder integration with external protocols. After this EIP, even the reliable require(tx.origin == msg.sender) check seems outdated. Protocols must adapt by removing these checks, as the distinction between “EOA” and “contract” will no longer apply—now every address may have associated code.

The traditional separation between EOAs and smart contracts continues to blur. This EIP brings Ethereum closer to designs like TON, where every account is essentially executable code. As interactions with protocols grow more complex, using programmable logic to improve end-user experience is a natural evolution.

Conclusion

The Prague/Electra (Pectra) upgrade is scheduled for March 2025. Its most notable planned changes include:

Variable validator effective stakes up to 2048 ETH, which will significantly alter stake distribution, validator scheduling, and simplify management for large staking providers by consolidating smaller stakes
Improved interaction between execution and consensus layers, simplifying data exchange between Eth1 execution blocks and beacon chain blocks. This will greatly streamline deposits, activations, withdrawals, and exits, speeding up these processes and laying the groundwork for further interactions between consensus and execution layers
Support in smart contracts for cheaper direct BLS signature and zkSNARK verification via a new “pairing-friendly” BLS12-381 precompile
Encouraging Rollups to adopt blob transactions by increasing blob transaction thresholds and raising calldata costs
Enabling EOAs to act as programmable accounts, granting them multicall, sponsorship, and other advanced capabilities

As you can see, Pectra will significantly impact staking and the consensus layer, as well as the end-user experience on the execution layer. While we cannot analyze all these changes in code detail at this stage due to ongoing development, we will cover these updates in future articles.

Join TechFlow official community to stay tuned

Telegram:https://t.me/TechFlowDaily

X (Twitter):https://x.com/TechFlowPost

X (Twitter) EN:https://x.com/BlockFlow_News

Source

Add to Favorites

Share to Social Media

Author

MixBytes

@MixBytes

Analyzing Ethereum's upcoming hard fork: the Pectra upgrade

TechFlow Selected TechFlow Selected