EIP-8135 Hard fork meta: BPO2 (Hardfork Meta - BPO2)
Final · Scaling & data · EIP status Final · created 2026-01-24
A meta EIP recording the activation time and changed values of BPO2, Ethereum mainnet's second Blob-Parameter-Only (BPO) upgrade. The blob target per block increased from 10 to 14, and the maximum increased from 15 to 21.
Why it is needed
On Ethereum, L2s such as rollups post transaction data into a dedicated data space called blobs. The number of blobs allowed per block is being raised gradually within the range the network can handle, and an upgrade that changes only blob figures this way is called a BPO (Blob-Parameter-Only) upgrade. Rather than bundling major feature changes like a regular hard fork, a BPO changes just a few client configuration values, so a separate official record of which value was applied when is needed. This EIP carries forward the approach of EIP-8134, which recorded the first upgrade, BPO1, to record the activation time and parameters of the second upgrade, BPO2, as a standard document. This allows anyone to transparently track the history of blob capacity increases under the Surge roadmap.
What changes
Today
- Blob target of 10 per block, maximum of 15 (BPO1 baseline)
- Blob base fee update fraction 8,346,193
- BPO2's figures exist only in client genesis configuration files
After EIP-8135
- Blob target of 14 per block, maximum of 21
- Blob base fee update fraction 11,684,671
- The activation time and parameters are recorded in a standard EIP document
Who is affected
- L2/rollup teams: The blob capacity usable per block increases from a target of 10 to 14, and from a maximum of 15 to 21.
- Node operators and validators: The increase in blob throughput may affect network load characteristics, so the source text calls for close monitoring.
- Client teams: An official reference document is created for the mainnet standard values that go into the genesis configuration.
- Researcher: This provides grounds for observing blob processing and slot reliability data under higher blob load.
In depth
The Blob Parameter Only (BPO) upgrade framework
A BPO is a network upgrade that changes only blob-related parameters. Its operating mechanism is defined in EIP-7892, and this EIP records the values of BPO2, which was executed under that framework. The source text states that nothing other than the blob target, blob max, and base fee update fraction changes in protocol behavior. All activation times are expressed as Unix time in seconds, UTC. This document itself is not a proposal to change code but a Meta-type EIP that records the facts of an upgrade that has already occurred.
BPO2 parameters
BPO2 activated at Unix time 1767747671, which is January 7, 2026 UTC. The Blob Target per block is 14, the Blob Max is 21, and the Base Fee Update Fraction is 11,684,671. The source text defines BPO2 as the second incremental blob capacity increase following BPO1, continuing a phased expansion toward higher data availability limits.
The evolution of the blob schedule, from Cancun to BPO2
The source text tabulates the past blob schedule. Cancun had a target of 3, a max of 6, and an update fraction of 3,338,477. In Prague, these rose to a target of 6, a max of 9, and an update fraction of 5,007,716, and under BPO1 they became a target of 10, a max of 15, and an update fraction of 8,346,193. BPO2 builds directly on top of BPO1's parameter baseline, and compared to Cancun it means the blob target per block has grown from 3 to 14.
The source of the figures is the client genesis configuration
The figures in this EIP are taken from the genesis configuration of Ethereum clients. The configuration contains bpo2Time: 1767747671, and under the bpo2 entry of blobSchedule are target: 14, max: 21, and baseFeeUpdateFraction: 11684671. Different client implementations may expose these values in different formats, but this EIP states that it faithfully reflects the canonical configuration values of mainnet. In other words, the purpose of this section is to align the configuration actually applied on chain with the documented record.
The goal is observation, not demand
The source text's Rationale states clearly that BPO2 was not driven by proven demand. Observations following BPO1 showed signals that the network could tolerate higher blob limits, but there was not yet enough data across a wider range of operating conditions. So, as an extension of the same incremental expansion approach, the parameters were raised in order to gather further empirical data on blob processing, slot reliability, and overall network stability under higher blob load. At the same time, the position is to evaluate the system's limits in a controlled manner while retaining the ability to halt or adjust parameters based on observed results.
Security considerations and document status
The source text states that because BPO upgrades adjust blob throughput parameters, they may affect network load characteristics. It specifies that close monitoring, phased rollout, and ecosystem-wide coordination are needed to maintain stability. This EIP's status is Final. It is a finalized document recording an upgrade that has already been applied to mainnet, so its content will not change further.