What Is Ethereum's Pectra Upgrade? A Guide Centered on EIP-7702 and Staking Changes

Overview of This Article

Pectra is a major Ethereum upgrade that went live on mainnet at epoch (a time-based unit on the chain) 364032, on May 7, 2025 at 10:05 UTC. The name combines Prague on the execution layer with Electra on the consensus layer, and it followed Dencun.ethereum.org

The headline change is EIP-7702, which lets a regular Ethereum account (an EOA, or Externally Owned Account) use smart-contract-like behavior. Wallets and apps can now more easily offer UX improvements such as batching multiple operations, sponsoring gas, and issuing sub-keys with limited permissions.EIP-7702

Staking also changed significantly. EIP-7251 raised the maximum effective balance of a single validator (the balance used in reward calculation) from 32 ETH to 2,048 ETH, making it possible to consolidate multiple 32 ETH validators and to let rewards compound within the same validator.EIP-7251

Pectra also touched data availability for L2s. Blobs (a dedicated, low-cost data area for posting L2 data), introduced in Dencun, were increased by Pectra’s EIP-7691 from a target of 3 and maximum of 6 to a target of 6 and maximum of 9.EIP-7691

At the same time, EIP-7623 raised the gas cost of transactions that use a lot of calldata (the input-data area attached to a transaction), further encouraging blob-based designs.EIP-7623

Overview and Timeline of the Pectra Upgrade

Goals and Approach

EIP-7600, the meta EIP for Pectra (the combined Prague/Electra upgrade), lists the EIPs included in this upgrade.EIP-7600

It contains 10 Core EIPs.ethereum-forks

The goals fall into four broad categories.

• Improving wallet UX
  • EIP-7702 lets an EOA use the code of a delegated contract.
  • It makes batching, gas sponsorship, permission-limited sub-keys, and recovery easier to handle as extensions of an existing account.
• Making staking operations more flexible
  • EIP-7251 raises the maximum effective balance of a single validator to 2,048 ETH, enabling validator consolidation.
  • EIP-7002 lets the withdrawal address for staked ETH directly trigger a validator’s exit or partial withdrawal.
  • EIP-6110 includes validator deposit data directly in execution blocks, removing the consensus layer’s need to pick it up indirectly through eth1data voting and speeding up how quickly deposits take effect.
• L2 data availability and block-size control
  • EIP-7691 increases the target and maximum number of blobs.
  • EIP-7623 raises the gas cost of transactions that use a lot of calldata, bounding maximum block size.
  • EIP-7840 has clients hold per-fork blob settings.
• Protocol efficiency and future-proofing
  • EIP-2537 adds precompiles (operations built into the client to reduce gas cost) for BLS12-381 curve operations.
  • EIP-2935 makes past block hashes available from a system contract.
  • EIP-7549 moves the committee index (the ID showing which validator committee a vote belongs to) out of the attestation (a validator’s vote), so votes from different committees can be aggregated together as long as the content matches.

Pectra advanced the L2 data-availability work that Dencun’s blobs began, while also touching wallets and staking. It is mainly a practical, foundation-level upgrade.

Timeline

Pectra was tested on Holešky, Sepolia, and Hoodi before activating on mainnet, following this schedule.EIP-7600

List of Target EIPs

Pectra includes the following 11 EIPs.EIP-7600 ethereum-forks

EIP-7600 also lists EIP-7642 (eth/69 – Drop pre-merge fields, which removes p2p fields such as total difficulty that stopped being used after the Merge) as a related EIP, under the Networking category.

Headliner Feature ① EIP-7702: EOAs Gain the Flexibility of a Smart Contract Wallet

The Problem: UX Constraints of EOAs

Most of the accounts Ethereum users interact with day to day are EOAs. An EOA is a simple account that signs and sends transactions with a private key. That simplicity is convenient, but by default an EOA does not have the flexible behavior of a smart contract wallet.

For example, users may want to send an ERC-20 approve and a swap as separate transactions on a DEX, pay the gas equivalent in a different token, or delegate only certain actions to a sub-key with a daily limit.

But an EOA simply executes the transaction it signed as a single call; it has no mechanism for bundling multiple operations or attaching conditions to a transaction. A smart contract wallet can implement this kind of logic because the account itself is a contract, but an EOA structurally could not do so.

To make these use cases easier to handle while keeping the account as an EOA, EIP-7702 adds a mechanism that lets an EOA use the code of a delegated contract. The EOA keeps its existing private key and address, and borrows the delegated contract’s logic only at transaction execution time to behave like a smart contract wallet.EIP-7702

How It Works: Authorization Tuples and the Delegation Indicator

EIP-7702 adds a new transaction type, 0x04. This transaction is how an EOA approves using the code of a delegated contract.

This transaction contains data called an authorization_list, in the form [chain_id, address, nonce, y_parity, r, s], which indicates which delegated address to use.EIP-7702

Once this transaction is approved, the protocol writes 0xef0100 || address — a marker called the delegation indicator, pointing to the delegated contract — into the target EOA.

When that EOA becomes the target of CALL, DELEGATECALL, STATICCALL, or similar operations, clients read and execute the code at the address the delegation indicator points to.EIP-7702

Rather than moving the account itself to another contract, this lets the existing address use a specific contract, and setting the delegated address to 0x0000000000000000000000000000000000000000 removes the marker.EIP-7702

What Developers Should Watch For

After EIP-7702, applications can no longer classify account types by checking whether “an EOA has no code.”

Also watch the relationship between authorization-tuple processing and rollback. Under EIP-7702, a processed delegation indicator is not rolled back even if the transaction itself fails. Wallets and apps need UX that does not leave users confused about what they are signing, the nonce, the delegated address, and the state after a failure.EIP-7702

Headliner Feature ② EIP-7251 / EIP-7002: Major Changes to Staking

From a 32 ETH Cap to a 2,048 ETH Cap

Before Pectra, a single validator’s effective balance was capped at 32 ETH. Any balance above 32 ETH did not count toward block-proposal probability or reward calculation. As a result, running a large-scale stake required operating many separate 32 ETH validators.

EIP-7251 keeps the minimum staking balance at 32 ETH while raising MAX_EFFECTIVE_BALANCE to 2,048 ETH. The specification defines this as MAX_EFFECTIVE_BALANCE_ELECTRA = 2048 ETH.EIP-7251

This change makes it possible to consolidate multiple validators into a smaller number of validators with larger effective balances. As a result, the number of P2P messages, the number of BLS signatures aggregated per epoch, and the memory load on BeaconState are all expected to fall.EIP-7251

Consolidation is initiated by sending a transaction from the address recorded in the source validator’s withdrawal credentials to the consolidation request contract (0x0000BBdDc7CE488642fb579F8B00f3a590007251), with data that includes the pubkeys of the source and target validators.

As long as neither the source nor target validator is exiting or has already exited, the source validator’s exit begins, and after it exits, its balance is added to the target validator’s effective balance.

Each transaction can specify only one source-target pair, so consolidating several validators into the same target requires sending a separate transaction for each source validator.

Consolidation can also serve as a migration tool — for example, moving the balance of validators running on an old server or under a previous operator into a target validator already running on the new server or with the new operator.

However, the target validator must be an active validator with compounding withdrawal credentials — the withdrawal credential type introduced to support Pectra.EIP-7251

Reward calculation for ordinary validators also changes. Rewards above 32 ETH can now be reflected in the same validator’s effective balance, so they are no longer excluded from reward calculation the way they used to be while waiting for the next 32 ETH to accumulate and a new validator to be started.ethereum-pectra

Requesting Validator Exits and Partial Withdrawals from the Execution Layer

EIP-7002 adds a mechanism that lets the withdrawal address specified in an execution-layer 0x01 withdrawal credential request a validator’s exit or a partial withdrawal.

Previously, exits had to be triggered with the validator’s signing key, so the owner of the funds — the holder of the withdrawal credentials — could not start an exit on their own.EIP-7002

The validator’s signing key is used solely for validator signing duties, while the withdrawal credentials are treated as the address that ultimately receives and owns the funds.

Faster Deposit Processing

EIP-6110 places validator deposit processing directly into the block structure, making it easier for the consensus layer to ingest the data and removing the need for the eth1data voting the consensus layer previously required.EIP-6110

This change is said to shorten the time from sending the deposit transaction to processing on the consensus layer from roughly 12 hours under the existing mechanism to about 13 minutes with in-protocol processing.EIP-6110

Changes to L2s and Data Availability: More Blobs and a Calldata Cost Change

Blobs Increase to a Target of 6 and Maximum of 9

Blobs, introduced in Dencun, are a low-cost data area L2s use to post data to Ethereum L1. Pectra’s EIP-7691 raised the blob target from 3 to 6 and the maximum from 6 to 9.

EIP-7691 assumes the rollup-centric roadmap, under which L2s scale by relying on L1’s data capacity. Pectra raised blob throughput as a short-term increase to bridge the gap until future data-availability expansions such as PeerDAS arrive.EIP-7691

Raising the Cost of Calldata to Favor Blobs

calldata load reduction and repricing were also addressed: EIP-7623 is the EIP that sets a floor cost for transactions that use a lot of calldata, bounding maximum block size and its variance.EIP-7623

Transactions that do not use calldata as their main data-availability route — ordinary ETH transfers, token transfers, NFTs, DeFi, social apps, restaking, and bridging — are designed to be less affected.

Transactions that use calldata as a data store will see higher fees, making the “use blobs wherever possible” design direction even clearer.

Clients Now Hold the Blob Growth Schedule

EIP-7840 adds blobSchedule to the execution client’s configuration file.

For example, cancun has a target of 3, a max of 6, and a baseFeeUpdateFraction of 3,338,477, while prague has a target of 6, a max of 9, and a baseFeeUpdateFraction of 5,007,716 — each network phase carries its own target blob count, maximum blob count, and fee-update figure.EIP-7840

This change smooths communication between clients: it makes per-fork blob parameters explicit and avoids the need for complex per-block exchanges over the Engine API.EIP-7840

Other Notable EIPs

EIP-7685: A Channel from the Execution Layer to the Consensus Layer

Pectra’s staking-related EIPs pass withdrawal, deposit, and consolidation requests from the execution layer to the consensus layer. EIP-7685 is the shared foundation for doing that. It adds requests_hash to the block header, carrying a hash of the requests added during block processing.EIP-7685

EIP-7685 itself does not define the individual request types; each request’s own EIP specifies its request type, data format, and other specifics.

Sharing this foundation means new request types added to the execution layer in the future can reuse the same framework.EIP-7685

EIP-2537: BLS12-381 Precompiles

EIP-2537 adds precompiles that let the EVM use BLS12-381 curve operations efficiently.

BLS signature verification and similar operations can now be called through precompiled logic built into the client, instead of through Solidity implementations or custom contracts.EIP-2537

Because Ethereum’s consensus layer uses BLS signatures, this reduces the implementation and gas cost for applications — staking pools, restaking, bridges, and applications that use zero-knowledge proofs — that handle validator data or BLS signatures.ethereum-pectra

EIP-2935: Past Block Hashes Become Queryable from Chain State

EIP-2935 stores the block hashes of the latest 8,191 blocks in a system contract, making them queryable from the EVM. The existing BLOCKHASH opcode can only reach the latest 256 blocks (about 51 minutes).

EIP-2935 does not change the opcode itself; by storing hashes in a separate contract, it extends the queryable range to about 27 hours.EIP-2935

This also matters for future support of stateless clients (clients that do not hold state themselves, and instead receive the data they need as a proof called a witness and verify it). If block hashes are stored in a contract as part of state, that value can also be included and proven in a witness — so this change is partly groundwork for the future.EIP-2935

EIP-7549: Lighter BLS Signature Aggregation

EIP-7549 removes the committee index (the index identifying which committee — a group of validators — cast a given vote) from the attestation (a validator’s vote), taking it out of the signed data.

One epoch consists of 32 slots (SLOTS_PER_EPOCH), and voting within each slot is split across up to 64 committees (MAX_COMMITTEES_PER_SLOT).

Because the committee index used to be signed along with the vote, votes with identical content still produced separate signatures whenever the committee differed. In the worst case, that means verifying an aggregate signature for every one of the 32 × 64 = 2,048 (slot, committee) combinations in a single epoch.EIP-7549

Taking the committee index out of the signed data means votes with the same content within a slot can be combined into a single aggregate signature even if they come from different committees. Because the unit of verification shifts from (slot, committee) combinations to slots, the number of aggregate signatures needed falls to roughly one-64th (the committee count) of what it was before.

EIP-7549 explains that on a beacon chain network with at least 262,144 active indices, the number of aggregate signatures that must be verified to reach the two-thirds threshold falls from ceil(32*64*2/3) = 1366 to ceil(32*2/3) = 22.EIP-7549

This not only improves consensus-client processing and verification efficiency, it also makes Ethereum’s ZK proof generation more efficient.EIP-7549

Impact on Validator/Node Operators, L2s, and App Developers, and Summary

Impact on Validator and Node Operators

For staking operations after Pectra, responding to EIP-7251 comes first.

Operators can keep running existing 32 ETH validators as-is, but if they use validator consolidation or compounding withdrawal credentials, the unit of key management, monitoring, reward calculation, and accounting changes.EIP-7251

Consolidation can also be used as a migration path, moving balances from an old operator or server setup toward a new target validator.

Mixing up the source or target pubkey, the withdrawal address, or the target’s compounding credentials would change who controls the funds and the operation, so this needs a documented procedure and upfront verification.EIP-7251 Electra consensus spec

EIP-7002 now lets the holder of the withdrawal credentials request an exit or partial withdrawal. In split setups where the operator holds the active key and the fund owner holds the withdrawal credentials, both parties should be aware that exit authority and fund control now work differently.EIP-7002

Impact on L2 and Rollup Developers

For L2s, Pectra is a combination of increased blob capacity and a calldata repricing. EIP-7691 raised the blob target and maximum, while EIP-7623 is expected to raise costs for transactions that put large amounts of data into calldata.EIP-7691 EIP-7623

Rollups therefore need to revisit how much transaction data they put into calldata, their blob fallback strategy, and their fee-estimation logic, all against the post-Pectra blob limits and calldata floor cost.

Impact on Wallet and dApp Developers

EIP-7702 is a change that directly improves UX for wallets. Bundling approve and swap into one action, sponsoring gas, and issuing session keys with limited permissions, along with recovery designs — capabilities that had leaned toward smart contract wallets — become easier to deliver to existing EOA users as well.EIP-7702

But security responsibility also grows. Signing screens must let users understand which address is delegating to which code. Applications need to revisit the assumption that an EOA has no code, assumptions around tx.origin, and access control that depends on account type.EIP-7702

Summary

EIP-7702 makes an EOA usable like AA (Account Abstraction); EIP-7251 and EIP-7002 changed the unit of validator balances and exit authority; EIP-7691 raised blobs to a target of 6 and maximum of 9; and EIP-7623 raised the cost of transactions that carry large amounts of calldata.

Pectra is an upgrade with wide-reaching effects on the existing workflows of users, operators, and developers. Wallets need to rethink how they present authorization for actions. Staking operators will need to confirm their consolidation procedures and where exit authority sits, while L2 teams will need to confirm their assumptions about blob and calldata costs.

Omakase, as an SSP (Staking Service Provider) for Ethereum staking, continues to track validator consolidation, withdrawal credentials, and client operational requirements after Pectra.