Pectra hard fork
Prague (execution) + Electra (consensus) · Mainnet 2025-05-07
Regular wallets (EOAs) can behave like smart accounts, and the staking limit a single validator can carry was raised from 32 ETH to 2048 ETH.
What changed
- Users
- A delegation feature (EIP-7702) was introduced that lets you keep using a regular wallet (EOA) address while having it behave like a smart account. Sending several transactions bundled together, having someone else pay the fee, or granting a specific app only limited permissions all became possible without changing your address. However, which code you delegate to determines the safety of the whole account, so it is safest to use only delegations that the wallet has vetted and provides. The L1 data cost that feeds into L2 fees also varies with supply and demand as blob space grows, so L2 users are affected indirectly.
- Wallet & app developers
- Wallets must audit and provide the code an EOA delegates to, and must not expose an interface that lets external apps request delegation signatures. Initialization front-running attacks and storage collisions must also be prevented on the wallet side. For contract developers, the assumption that tx.origin == msg.sender is true only in the top-level execution frame no longer holds. Reentrancy guards or sandwich defenses that rely on this check must be reviewed again. A precompile for BLS12-381 curve operations (EIP-2537) was also added.
- Validators
- The cap on the effective balance credited to a single validator was raised from 32 ETH to 2048 ETH (EIP-7251). The minimum of 32 ETH is unchanged. Large operators can consolidate thousands of validators into a few and reduce the number of beacon nodes and signing keys, solo stakers get a compounding effect as rewards accrue to the effective balance, and intermediate amounts such as 40 ETH can now be staked. The owner of the withdrawal address can request validator exits and partial withdrawals directly from the execution layer (EIP-7002), so there is a way to recover funds even after losing the signing key. Bandwidth demands may grow because there are more blobs.
- L2
- The number of blobs per block rose from a target of 3 and a maximum of 6 to a target of 6 and a maximum of 9 (EIP-7691). The data space available on L1 is now about double, which leaves room for the burden of data posting costs to shrink. Blob fees are set by supply and demand, so the actual cost depends on how much other rollups use.