This Meta EIP documents a subsequent adjustment to Ethereum’s blob parameters using the Blob-Parameter-Only (BPO) update mechanism. The proposal specifies updated target and maximum blob limits to be applied without a full network upgrade, enabling continued evaluation of blob processing behavior under revised operational conditions. The change is intended to support ongoing measurement of network performance, reliability, and capacity characteristics, and to inform future data-availability scaling decisions based on observed mainnet behavior. The BPO3 specification provides a canonical reference of blob target, blob maximum limits, and associated configuration values, enabling transparent tracking of incremental data availability scaling following BPO2.
Following the publication of Meta EIPs documenting BPO1 and BPO2, this EIP extends the reference approach to BPO3, preserving continuity and enabling longitudinal comparison of blob capacity increases.
This EIP records authoritative data for BPO3, including activation parameters and the deterministic derivation rule used for blob scaling, to improve traceability, ecosystem coordination, and historical accuracy. For BPO3, the Blob Target is set to the previous upgrade’s Blob Maximum, and the Blob Maximum is calculated as 1.5× the Blob Target, rounded up, resulting in a Blob Target and a Blob Maximum. Documenting both the resulting parameter values and the derivation rule improves predictability for client implementations, tooling, capacity planning, and longitudinal analysis of blob scaling behavior across successive BPO upgrades.
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 BPO3.
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 | BPO3 |
| Activation Time (UTC) | |
| Blob Target | |
| Blob Max | |
| Base Fee Update Fraction |
BPO3 represents the third incremental blob capacity adjustment following BPO2 and continues staged scaling toward higher data availability limits.
For reference, prior blob schedules were established in earlier network upgrades and BPO upgrades:
| Upgrade | Blob Target | Blob Max | Base Fee Update Fraction |
|---|---|---|---|
| BPO2 | 14 | 21 | 11,684,671 |
| BPO1 | 10 | 15 | 8,346,193 |
| Prague | 6 | 9 | 5,007,716 |
| Cancun | 3 | 6 | 3,338,477 |
BPO3 builds directly on the BPO2 parameter baseline.
The parameter values and activation time for BPO3 will be derived from Ethereum client configuration once finalized.
Example (placeholder only):
Client implementations may expose these values in different formats; this EIP will reflect the canonical mainnet configuration once confirmed.
BPO3 adjusts blob throughput by increasing/decreasing the Blob Target and the Blob Maximum, continuing the staged scaling model established by prior BPO upgrades. Capturing these values in a dedicated Meta EIP provides a stable reference for implementers, tooling developers, researchers, and infrastructure operators who depend on accurate parameter baselines. Documenting this information reduces ambiguity across client implementations, supports consistent monitoring and benchmarking, and enables longitudinal analysis of data availability growth as Ethereum progresses through its scaling roadmap.
BPO upgrades adjust blob throughput parameters and may impact network load characteristics. Careful monitoring, staged rollout, and ecosystem coordination are required to ensure stability.
Copyright and related rights waived via CC0.