EIP-7691 Ethereum, EIP-7691 Blob Throughput, and EIP-7691 Blob Throughput Increase Pectra

EIP-7691, activated in Ethereum’s Pectra hard fork on May 7, 2025, raises the network’s blob throughput from a 3/6 target/max to 6/9 and retunes blob fee dynamics to favor faster price declines when demand is below target. This post explains what actually changed, how much capacity you now have, how rollups and infra teams should adapt immediately, and what’s coming next with PeerDAS. (blog.ethereum.org)

TL;DR for decision-makers

Pectra doubled target blob capacity to 6 blobs per block (max 9), and adjusted the blob base fee curve so prices fall faster during lulls and rise more slowly in spikes, smoothing costs for L2s. (eips.ethereum.org)
In the first days after Pectra, blobs became “virtually free” again because demand sat well below the new 6‑blob target; validators, however, must retain more short‑lived data between prune windows. (galaxy.com)
EIP‑7623 (also in Pectra) raised calldata’s floor price to cap worst‑case block sizes, freeing p2p headroom for the blob increase. If you still fall back to calldata for DA, revisit that now. (eips.ethereum.org)
Next up: PeerDAS (EIP‑7594) will shift Ethereum to sampled data availability, enabling much larger blobspace without overburdening nodes—teams should start testing assumptions on devnets. (eips.ethereum.org)

What exactly EIP‑7691 changed

Target blobs per block: 3 → 6
Max blobs per block: 6 → 9
New blob gas parameters (consumed by clients post‑fork):
- TARGET_BLOB_GAS_PER_BLOCK = 786,432
- MAX_BLOB_GAS_PER_BLOCK = 1,179,648
- GAS_PER_BLOB = 2^17 = 131,072 blob‑gas
- BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5,007,716 (retuned update fraction) (eips.ethereum.org)

Why the curve feels different: pre‑Pectra (3/6), full blobs raised the blob base fee ~12.5% block‑over‑block and empty blobs cut it ~11.1%. Post‑Pectra (6/9) the new parameters intentionally skew responsiveness—full blobs increase ~8.2%, while empty sections decrease ~14.5%. Practically: prices decay faster in quiet periods and climb more slowly in peaks. (eips.ethereum.org)

Activation facts and context:

Pectra mainnet: epoch 364,032 on May 7, 2025, combining Prague (EL) and Electra (CL). (blog.ethereum.org)
The Pectra meta‑spec (EIP‑7600) lists EIP‑7691 alongside EIP‑7623, EIP‑7702, EIP‑7251, and others. (eips.ethereum.org)

How much “new” capacity you actually got

Blobs are 4096 field elements × 32 bytes = 131,072 bytes (≈128 KiB) each. With 12‑second slots (≈7,200 blocks/day), that yields:

At the new target (6 blobs/block): ≈6 × 128 KiB × 7,200 ≈ 5.3 GiB/day of DA throughput.
At the new max (9 blobs/block): ≈9 × 128 KiB × 7,200 ≈ 7.9 GiB/day worst‑case ceiling.
These are raw calculations using EIP‑4844’s blob size and Ethereum’s slot cadence. (eips.ethereum.org)

Weekly target capacity moves from ≈150k blobs/week (3 blobs/block) to ≈300k blobs/week (6 blobs/block), a helpful mental model when budgeting L2 batch throughput. Observed consumption since Pectra shows Base often buying roughly one‑third of capacity (≈50–60k blobs/week), with Taiko, World Chain, and Arbitrum collectively taking another significant slice. (coinlive.com)

Immediate market impact after Pectra

Demand: In the first five full post‑fork days, rollups purchased ~25.6k blobs/day vs. ~21.2k/day pre‑fork (+20.8%), yet still under the new 6‑blob target—hence “virtually free” blobs. (galaxy.com)
Cost and burn: With under‑target usage, blob base fees collapsed towards the minimum, reducing ETH burned from blob usage and improving rollup margins. Some L2 user‑facing fees did not drop proportionally (teams held pricing), improving net income. (galaxy.com)
Validator/CL storage between prunes: More blobs purchased per day means more data retained until the ~18‑day pruning window elapses; estimates pegged the peak retained set around ≈44.6 GB shortly after Pectra. (galaxy.com)

Why EIP‑7623 matters to your DA strategy

EIP‑7623 raised the calldata “floor” cost (to 10/40 gas per zero/non‑zero byte for DA‑heavy txs) to reduce the worst‑case EL payload size and its variance. The goal: reclaim bandwidth headroom so the network can afford higher blob throughput without harming propagation and reorg rates. In short, blobs got room to grow; calldata became less attractive for bulk DA. (eips.ethereum.org)

What this means for you:

If your batcher still flips to calldata in spikes, revisit those thresholds—post‑Pectra, that fallback is costlier and also undermines network‑level goals.
P2P health improves when DA moves to blobs; it’s part of the reason core devs were comfortable green‑lighting 6/9. (blog.ethereum.org)

Practical examples for planning and budgeting

Right‑sizing batches

Suppose your rollup emits ≈2 MiB/min of compressed DA. Each blob ≈128 KiB → ≈16 blobs/min. Ethereum produces 5 blocks/min → ≈3.2 blobs/block demand. That sits below the 6‑blob target, meaning you should expect minimal fees most of the time and low price variance.
If demand spikes to ≈8 blobs/block for your chain’s cohort, expect slower upward fee drift than pre‑Pectra: +8.2%/full block vs. +12.5% previously. Budget for time‑to‑double that’s longer in spikes, and time‑to‑halve that’s shorter in lulls. (eips.ethereum.org)

Per‑blob fee math you can implement today

Cost per blob = GAS_PER_BLOB × blob_gas_price. With GAS_PER_BLOB = 131,072 blob‑gas, at a 1 wei/blob‑gas floor, a blob costs 131,072 wei—effectively negligible. Use the header’s excess_blob_gas with the “fake exponential” function from EIP‑4844 to estimate blob_gas_price locally. Update your constants to the Pectra values. (eips.ethereum.org)

Daily capacity assurance

With ≈5.3 GiB/day at target, a single app needing ≈0.3 GiB/day uses ~5.6% of the target budget on average. As long as aggregate demand across L2s stays under target, your posted batches should clear at near‑floor prices. Track aggregate utilization on public dashboards and Etherscan’s blob views. (info.etherscan.com)

Operational playbook: best emerging practices

For rollup platform teams (batchers/provers/settlement):

Re‑tune blob gas guardrails
- Recalibrate max_fee_per_blob_gas ceilings and backoff multipliers for the new 6/9 parameters so you don’t unnecessarily drop batches during momentary spikes. The post‑Pectra curve decays faster; take advantage of “wait a slot” strategies before switching mediums or paying above target. (eips.ethereum.org)
Prefer blobs over calldata more aggressively
- Update fallback logic thresholds given EIP‑7623. Only drop to calldata for metadata/exception paths. This keeps your costs down and protects network propagation. (eips.ethereum.org)
Implement robust blob retrieval and verification
- Consume blobs directly from a local beacon node via the Beacon API GET /eth/v1/beacon/blob_sidecars/{block_id}?indices=…; verify against versioned hashes (BLOBHASH) and KZG commitments. Maintain multi‑provider failover (Alchemy/QuickNode/Blockdaemon) for redundancy. (alchemy.com)
Align with OP Stack/Nitro/zk stacks’ latest derivation guidance
- OP Stack specifies retrieval via blob_sidecars and verification against versioned hashes—ensure your derivation pipeline treats blob batches and calldata metadata consistently to preserve ordering. (specs.optimism.io)
Budget for retained blob data in your CL nodes
- Nodes must keep blobs for ~4,096 epochs (~18 days). Tune prune margins and ensure you have headroom for surges (e.g., Lighthouse exposes blob_prune_margin_epochs). Multi‑region caching of recent blobs tightens RTOs during reorgs. (eips.ethereum.org)

For validator operators and node infra:

Monitor propagation and reorgs during high‑DA windows
- Pectra’s combo (7691 + 7623) aimed at keeping worst‑case blocks tractable; still, watch block_prop tails and peer health during bursts. Use client dashboards and research threads tracking post‑fork propagation and reorgs. (ethresear.ch)
Keep an eye on bandwidth ceilings
- Blobs must be gossiped; while 7623 tightened calldata extremes, more blob data flowing increases consensus‑layer bandwidth. Audit your peering, I/O, and CPU profiles, especially if you’re consolidating validators under EIP‑7251. (blog.ethereum.org)
Validate your CL/EL versions against Pectra meta (EIP‑7600)
- Make sure node stacks align with the included EIPs and engine API updates in the Prague/Electra specs. (eips.ethereum.org)

For product and finance leaders:

Expect lower, less volatile DA costs while utilization < target
- Price smoothing from the new update fraction reduces tail risk; if you provisioned large buffers pre‑Pectra, consider freeing working capital or redeploying it to user incentives. (eips.ethereum.org)
Validate user‑visible fee policies
- Some L2s held retail fees steady despite lower DA costs to improve margins; decide whether your strategy is margin capture, growth, or both. Track blob burn and margins via research dashboards. (galaxy.com)

How to see the changes live

Etherscan:
- Real‑time blob submissions: etherscan.io/txsBlobs
- Per‑block blob counts: etherscan.io/blocks (shows new 6 target / 9 max) (info.etherscan.com)
EF blog posts:
- Pectra mainnet announcement and rationale for blob scaling. (blog.ethereum.org)
EIP pages (primary specs):
- EIP‑7691 (blob throughput), EIP‑7623 (calldata floor), EIP‑4844 (blob mechanics). (eips.ethereum.org)

Deep technical details teams often miss

Blob sizing and KZG specifics
- Each blob is 4096 field elements in BLS12‑381 Fr, 32 bytes each, encoded as a degree‑4095 polynomial; commitment and per‑point proofs are 48 bytes. This keeps verification cheap and forward‑compatible with DAS. (eips.ethereum.org)
On‑chain visibility and BLOBHASH
- EVM contracts cannot read blob contents, only their versioned hashes via the BLOBHASH opcode (0x49). Applications should persist minimal metadata on L1 and rely on off‑chain availability paired with KZG proofs. (eips.ethereum.org)
Fee computation under Pectra
- The fake exponential function uses excess_blob_gas and the updated fraction to derive blob_gas_price. With the 6/9 target/max, your base fee decays faster when under target, so “post when cheap” strategies get more effective. (eips.ethereum.org)

What’s next: PeerDAS and a bigger blob future

PeerDAS (EIP‑7594, in Last Call as of late 2025) introduces peer‑to‑peer data availability sampling so nodes only download a fraction of blob data while still verifying availability. This is the path to scaling blobspace further without pushing every node’s bandwidth linearly. Expect client and API shifts (e.g., cell proofs, custody groups), and test your pipelines on PeerDAS devnets. (eips.ethereum.org)

Ethereum.org’s roadmap and EF posts foreshadow “Fusaka” with PeerDAS, with community chatter about targets like 48/72 blobs when DAS lands. Treat these numbers as exploratory; plan capacity scenarios rather than hard commitments. (info.etherscan.com)

Implementation checklist (7Block Labs’ quick start)

Update constants and fee estimators to Pectra values; unit‑test blob fee backoff/rate‑limit logic against the 8.2%/14.5% dynamics. (eips.ethereum.org)
Harden blob fetch/verify: integrate Beacon API blob_sidecars with redundancy and strict KZG verification; pin recent blobs in cache regions you operate in. (alchemy.com)
Remove DA bulk fallbacks to calldata except for metadata; re‑profile costs under EIP‑7623. (eips.ethereum.org)
Monitor: blob utilization vs. target, blob base fee, per‑L2 share, and retained CL blob storage between prunes; set alerts when utilization >80% of target for several consecutive epochs. (galaxy.com)
Start PeerDAS readiness: test cell proof flows, custody metrics, and builder interfaces on the latest devnets. (notes.ethereum.org)

FAQ

Is blob capacity “double” or “+50%”?
- Target doubled (3 → 6), max increased by 50% (6 → 9). Both statements appear depending on whether someone references target or max; the EF blog emphasizes the effective doubling of usable target throughput. (blog.ethereum.org)
How long are blobs stored?
- About 4,096 epochs (~18 days). After that they can be pruned by nodes, which is why your off‑chain data pipelines and proofs matter. (eips.ethereum.org)
Where can I watch blob usage per block?
- Etherscan exposes both live blob submissions and per‑block counts; Dune dashboards (e.g., hildobby) track weekly consumption by L2. (info.etherscan.com)

Conclusion

For startups and enterprises building on Ethereum, Pectra’s EIP‑7691 is a concrete, here‑and‑now scaling win: more headroom, cheaper and smoother DA pricing, and a cleaner runway to PeerDAS. The short‑term move is to retune batchers and fee guards, fully embrace blobs over calldata, and harden blob retrieval. The medium‑term move is to prepare for sampled DA, where your infra will validate availability without downloading every byte—and your product plans should assume significantly higher blob ceilings. (eips.ethereum.org)

Sources and primary specs

EIP‑7691: Blob throughput increase; EF Pectra announcements; Pectra meta EIP‑7600. (eips.ethereum.org)
EIP‑7623: Increase calldata cost; research notes on worst‑case block sizes/propagation. (eips.ethereum.org)
EIP‑4844: Blob structure, size, pricing; BLOBHASH opcode. (eips.ethereum.org)
Post‑Pectra market data and operational notes (Galaxy Research; Etherscan). (galaxy.com)
PeerDAS: EIP‑7594 and devnet specs. (eips.ethereum.org)