This Meta EIP documents the activation details, parameter changes, and specification references for the first Blob-Parameter-Only (BPO) network upgrades, BPO1. It provides a canonical registry of blob targets, blob maximum limits, and associated configuration values to improve transparency, traceability, and ecosystem coordination for early-stage data availability scaling under Ethereum’s Surge roadmap.
Blob-Parameter-Only (BPO) upgrades enable Ethereum to scale data availability through incremental parameter adjustments rather than large multi-feature network upgrades. While this approach improves safety and iteration speed, there is currently no canonical reference documenting what changed in each BPO upgrade, when it was activated, and which parameter values were applied.
EIP-7892 specifies the mechanism and constraints for BPO upgrades but does not track individual BPO instances. In practice, activation timing and parameter values for BPO1 are distributed across client repositories, coordination notes, and operational artifacts, making consistent interpretation and historical analysis difficult for ecosystem participants.
This EIP addresses this gap by recording authoritative data for BPO1 in a canonical reference to improve transparency, traceability, and ecosystem coordination.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This section documents the Blob-Parameter-Only upgrade identified as BPO1.
The upgrade modifies blob-related protocol parameters as defined in EIP-7892. No other protocol behavior is affected. All timestamps are expressed as Unix epoch seconds (UTC).
| Field | Value |
|---|---|
| BPO Identifier | BPO1 |
| Activation Time (UTC) | 1765290071 |
| Blob Target | 10 |
| Blob Max | 15 |
| Base Fee Update Fraction | 8,346,193 |
BPO-1 represents the first mainnet deployment of a Blob-Parameter-Only upgrade and establishes the initial incremental increase in blob capacity following the Fusaka upgrade.
For reference, the blob schedule before BPO upgrades was established in earlier network upgrades:
| Upgrade | Blob Target | Blob Max | Base Fee Update Fraction |
|---|---|---|---|
| Cancun | 3 | 6 | 3,338,477 |
| Prague | 6 | 9 | 5,007,716 |
The parameter values and activation times in this EIP are derived from eth_client genesis configuration, including:
Client implementations may expose these values in different formats; this EIP reflects the canonical mainnet configuration values.
BPO-1 formalizes the first post-Fusaka adjustment to blob parameters, providing a controlled expansion of blob capacity to support empirical evaluation under mainnet conditions. This change enables the network to collect real-world performance data across clients, validators, and proposers, supporting evidence-based assessment of slot stability and system behavior before any further scaling decisions. Documenting BPO-1 as a standalone parameter update improves transparency and process clarity by establishing an authoritative record of blob parameter changes.
BPO upgrades may impact network load characteristics. Careful monitoring, staged rollout, and ecosystem coordination are required to ensure stability.
Copyright and related rights waived via CC0.