EIP-8134 Hard fork meta: BPO1 (Hardfork Meta - BPO1)
Final · Scaling & data · EIP status Final · created 2026-01-24
A meta EIP that officially records the activation time, blob target and maximum, and fee parameters of BPO1, Ethereum mainnet's first Blob-Parameter-Only (BPO) upgrade.
Why it is needed
Ethereum is expanding data availability by gradually increasing blobs, the space where rollups post data. Instead of a large network upgrade bundling many features at once, using a Blob-Parameter-Only (BPO) upgrade that changes only blob-related figures allows for safer, faster iteration. However, there was no official record documenting what changed, when, and to what value in each BPO upgrade. EIP-7892 defines the BPO mechanism itself but does not track the execution history of individual BPOs. In practice, BPO1's activation time and parameter values were scattered across client repositories, coordination notes, and operational records, making it hard for ecosystem participants to interpret consistently or look back on later. This EIP fills that gap by recording BPO1's official data in one place.
What changes
Today
- Blob parameter change history is scattered across client repositories and coordination documents
- EIP-7892 defines only the BPO mechanism and does not track the values of individual BPOs
- As of the Prague upgrade, the blob target is 6 and the maximum is 9
After EIP-8134
- BPO1's activation time and parameter values are recorded as a standard reference in this EIP
- After BPO1 is applied, the blob target becomes 10 and the maximum becomes 15
- An authoritative record is created that can be referenced before future decisions on blob expansion
Who is affected
- L2s and rollups: The blob target and maximum increase, enlarging the space available for posting data.
- Client teams: The bpo1 value in the genesis configuration can be checked against the standard record in this EIP.
- Validators / block proposers: They become the subject of collecting real-world performance data under the increased blob conditions, serving as the basis for slot stability evaluation.
- Researchers / ecosystem participants: They can analyze the history of blob parameter changes consistently, without relying on scattered sources.
In depth
BPO1 parameter values
BPO1's activation time is Unix timestamp 1765290071 seconds (UTC). The Blob Target is set to 10 and the Blob Max to 15. The Base Fee Update Fraction used for blob fee adjustment is 8,346,193. This upgrade changes only the blob-related parameters defined by EIP-7892 and does not affect other protocol behavior. The original text states that BPO1 is the first mainnet deployment of a Blob-Parameter-Only upgrade, and the first step of gradually expanding blob capacity after the Fusaka upgrade.
Comparison with previous upgrades
For reference, the original text also records the blob schedule prior to BPO. The Cancun upgrade had a blob target of 3, a maximum of 6, and a Base Fee Update Fraction of 3,338,477. The Prague upgrade raised these to a target of 6, a maximum of 9, and 5,007,716. BPO1 raises them one step further, to a target of 10, a maximum of 15, and 8,346,193.
Data source: client genesis configuration
The figures in this EIP are taken from the eth_client genesis configuration. The configuration includes a "bpo1Time": 1765290071 value and a blobSchedule entry, within which the target, max, and baseFeeUpdateFraction for cancun, prague, and bpo1 respectively are listed. Client implementations may expose this value in different formats, but this EIP records it based on mainnet's canonical configuration value.
Division of roles with EIP-7892
EIP-7892 defines the mechanism and constraints of BPO upgrades, that is, the method by which an upgrade that changes only blob parameters can be carried out. However, it does not track when and to what values individual BPOs were executed. Until now, BPO1's activation time and parameter values were scattered across client repositories, coordination notes, and operational records, making consistent interpretation and historical analysis difficult. This meta EIP serves as the official record that fills that gap.
Why record it as a standalone document
BPO1 formalizes the first blob parameter adjustment after Fusaka and makes it possible to evaluate blob capacity expansion under real mainnet conditions in a controlled way. Based on this, real-world performance data can be gathered across clients, validators, and block proposers, allowing slot stability and system behavior to be judged on solid grounds before making further expansion decisions. Recording BPO1 as a standalone parameter-change document creates an authoritative record of blob parameter changes, improving transparency and procedural clarity.
Security considerations and document status
BPO upgrades can affect network load characteristics. The original text states that careful monitoring, staged rollout, and ecosystem-wide coordination are needed to maintain stability. This EIP's status is Final, meaning its content is finalized.