The second Blob Parameters Only (BPO) fork happened today. BPO #2 was the next scheduled step in the Fusaka upgrade cycle to scale Ethereum’s data capacity. Here’s what you need to know about BPO #2, and why these parameter adjustments matter.

0/ What is a BPO fork? "Blob Parameter Only" forks are a new mechanism introduced in the latest Fusaka upgrade. Instead of waiting for a major annual upgrade to adjust network capacity, BPO forks allow Ethereum to tune specific parameters (like blob targets) independently and efficiently.

1/ What changed with the BPO fork? BPO #2 adjusted the blob limits to support more data throughput: ↗ Target blobs: increased to 14 (from 10) ↗ Max blobs: increased to 21 (from 15) This gradual ramp-up allows the network to safely test increased load step-by-step. BPO #2 is the last of the BPO forks that were planned as part of Ethereum’s Fusaka upgrade. With a goal to continue increasing the network's capacity, BPO forks will continue to be used as a tool for ongoing, data-driven scaling.

2/ Why the BPO fork matters More blobs = more data availability for Layer 2 networks. By incrementally raising the per-block blob limits, Ethereum reduces data costs for rollups. This helps keep transaction fees on L2s low even as activity grows, ensuring the network scales sustainably with demand.

3/ For node operators Fusaka-ready clients should have these BPO schedules baked in. It’s always good practice to double-check your release notes.