EIP-7691 Cost Curves: Modeling Blob Fee Volatility for App Teams

Summary: EIP-7691 has increased Ethereum’s target blob capacity and made some tweaks to the fee update curve. This change impacts how blob base fees shift from one block to another. In this guide, we'll help decision-makers figure out how to model these fresh cost dynamics, evaluate various volatility scenarios, and bolster their posting strategies before fees spike.

Who should read this

Heads of product and engineering at L2s, rollup-based apps, and data-heavy protocols are diving into their L1 data availability budgets.
CTOs and CFOs are putting their heads together to analyze the total cost of ownership (TCO) between blob data availability, calldata, and other options out there.
Platform teams responsible for batchers, provers, or settlement pipelines are really feeling the pressure from the ups and downs in blob pricing.

1) What changed with EIP‑7691 (Pectra): parameters and their business impact

On May 7, 2025, Ethereum launched its Pectra upgrade on the mainnet, introducing EIP‑7691. This upgrade boosted blob throughput and made some tweaks to the way fees are structured in the blob market. Here’s the scoop: the target blobs per block jumped from 3 to 6, the max number of blobs per block went up from 6 to 9, and they also fine-tuned the blob base fee update fraction a bit. If you want to dive deeper into the details, check it out here.

EIP‑7691 is designed to throw a wrench into the equal up/down response you’d find in the EIP‑4844 curve:

Taking a look at the 3/6 configuration (before Pectra), it turns out that full blob sections are driving the blob base fee up by about 12.5% each block. On the flip side, empty sections are actually helping to lower it by around 11.1% per block.
Now, zoom ahead to the 6/9 setup with the fresh update fraction (after Pectra), and we see some interesting changes: full blobs are only pushing the fee up by about 8.2% per block, while empty blocks are reducing it by a cool 14.5% per block.
This shift really changes the game--it suggests that we’ll see faster price drops when demand falls below what we’re aiming for, and slower price increases when demand shoots up over our target. In other words, it’s helping to smooth out those crazy spikes and giving a little extra push to the dips. If you want to dive deeper into this, check it out here.

Why it matters:

When things start heating up, the “time to double” stretches out, but during those quieter times, the “time to halve” kicks in much faster.
You’ll want to adjust those budgets, alerts, and max_fee_per_blob_gas guardrails that were set for 3/6 as we move to 6/9. This way, you can avoid the risk of refusing to post or going over budget.

2) The blob fee engine you’re optimizing against

Blob pricing follows a market model similar to EIP-1559, but it's distinct from execution gas:

GAS_PER_BLOB is calculated as 2^17, which comes out to 131,072 blob‑gas for each blob.
To determine the base fee for blob gas, we use a "fake exponential" approach that includes the excess_blob_gas and an update fraction. Just a little note here: this fee will be burned.
The MIN_BASE_FEE_PER_BLOB_GAS is pegged at 1 wei. (eips.ethereum.org)

Pectra (thanks to EIP‑7691) is bringing in some new per-fork values for this function:

TARGET_BLOBS_PER_BLOCK: 6
MAX_BLOBS_PER_BLOCK: 9
BLOB_BASE_FEE_UPDATE_FRACTION (Prague): 5,007,716

So, these values are managed individually for each fork using something referred to as a “blobSchedule” (take a look at EIP‑7840). This setup makes it a breeze to update parameters for future forks without having to deal with any complex engine negotiations. If you're curious to dive deeper, you can check it out at (eips.ethereum.org).

What you’ll pay for a blob:

The cost per blob (ETH) is pretty much the base_fee_per_blob_gas multiplied by 131,072.
Blob transactions do come with the usual execution base and priority fees for that tiny execution wrapper, but keep in mind that the data payload is priced based on blob gas.

3) Cost curve intuition under 6/9: “how fast can this move?”

Understanding EIP‑7691's Tuned Curve

So, let’s break down what EIP‑7691’s tuned curve is all about:

When several empty blobs flow in, you can expect the blob base fee to drop by roughly 14.5% with each block (it's all about that geometric progression). If you're hoping for a 50% reduction, you'll need about 4 to 5 empty blocks to make that happen.
On the other hand, if we keep hitting a bunch of maxed blocks (you know, that’s 9 blobs), the blob base fee goes up by around 8.2% with each block. If you’re aiming for a 2× increase, get ready for about 9 full blocks to pass.

These rough estimates for "half-life" and "doubling-time" are super useful for tracking alerts and planning your budget. While the actual changes align with the exponential rule from EIP‑4844, the percentages we just covered come straight from the EIP‑7691 setup. You can check it out here: (eips.ethereum.org).

Key Implications:

Quick dips can erase earlier spikes in a flash, so it's best to steer clear of over-hedging when things are peaking.
Spikes generally take a little longer to build up. If your guardrails are set up correctly, your posting SLA should be able to manage short bursts without reaching those maximum limits.

4) Reserve price bounding: the next lever (EIP‑7918, “price floor” tied to L1 gas)

There's a new proposal floating around called EIP‑7918, and it's currently in its Last Call phase as I'm writing this. This proposal is all about setting a reserve price so that we don’t overlook the blob base fee when execution gas is taking the stage. It introduces a constant known as BLOB_BASE_COST, which is currently pegged at 2^13 in the EIP.

In simple terms, this means the price for each blob will be at least BLOB_BASE_COST multiplied by the base_fee_per_gas for every unit of execution gas -- all in blob-gas terminology. To break it down even further, the reserve blob base fee is set to be roughly 1/16 of the execution base fee. If you're curious for more details, check out the full scoop over at eips.ethereum.org.

What This Means for Your Models

When the execution base fee is sitting at 16 gwei, the reserve blob base fee per blob-gas is about 1 gwei. To break it down, a complete blob will cost you around 131,072 gwei (that’s about 0.000131072 ETH), and this doesn’t even include any tips.
This whole arrangement means that when the execution gas prices go up, it might take a little while for the fee drops to kick in. It’s all about keeping things steady while the system finds its balance. So, if there’s a sudden jump in the execution base fee, blob fees may take a few blocks to adjust, but don’t worry--they’ll even out nicely over time. If you want to dive deeper, check out the details here.

Note: There’s been a lot of discussion about what the exact BLOB_BASE_COST constant should be. Some folks are thinking it might be 2^14, but the current EIP states it as 2^13. Just a heads up to prepare for some calibration risks until the mainnet parameters are finalized. (notes.ethereum.org)

5) Real‑world volatility drivers you must price in

Non-L2 bursts can really pack a punch! Remember the whole "blobscription" trend that took off back in early April 2024? It skyrocketed the blob base fee from just 1 wei to around 650 gwei in a quick flash--about 10 minutes or so (that’s roughly 600 blocks, for those keeping track). Even with that crazy jump, blobs still ended up being cheaper than calldata, but man, that price gap definitely tightened. So, make sure your guardrails are ready to deal with those sudden spikes! (blocknative.com)
Post-Pectra Supply Hangover: Ever since 6/9 launched on May 7, 2025, the average number of blobs per block has regularly dipped below the new target. This has made blob fees seem almost “free” at times, which is causing costs to plummet until demand bounces back. But don't let this quiet phase trick you into ignoring the potential risks. (galaxy.com)

6) BPO forks and per‑fork blob schedules: why planning horizons change

Two new initiatives are trying to make blob capacity feel a bit more “governable” as time goes on:

EIP‑7840 (blobSchedule): This one’s focused on giving execution clients the ability to manage per-fork blob parameters, such as target, max, and baseFeeUpdateFraction. Thanks to this, Pectra can smoothly utilize 6/9 and a fresh update fraction in Prague/Electra without the hassle of complicated per-block messaging. If you want to dive deeper, you can check it out here.
EIP‑7892 (Blob Parameter Only Hardforks): This is all about those cool “blob-only” forks that just tweak the target, max, and updateFraction. It’s a clever strategy to help Ethereum scale DA more quickly while keeping coordination risks low. For app teams, this translates to a faster feedback loop--they can shift their parameters based on blob demand more easily, which means we should see adjustments happening more frequently and with less hassle. If you want to dive deeper, check it out here.

Translation for Budgets

When you're crafting your forecasts for the next 18-24 months, don’t only zero in on the typical organic demand changes. It’s crucial to think about how you can ramp up capacity and even tweak your responsiveness a bit. These adjustments can really help shift the equilibrium in your favor.

7) Scenario modeling: cost curves you can run today

Here are some useful modeling patterns that your finance or platform teams might find helpful.

7.1 Block‑by‑block simulator (spreadsheet or Python)

Inputs:

A bunch of blobs for each block (they can be between 0 and 9 after Pectra).
Fork parameters: target=6, max=9, baseFeeUpdateFraction=5,007,716; GAS_PER_BLOB=131,072; min_blob_base=1 wei. (eips.ethereum.org)

State per block:

excess_blob_gas_t can be calculated as follows: max(0, excess_blob_gas_{t-1} + blobs_used_t × 131,072 − target × 131,072).
For base_fee_per_blob_gas_t, use this formula: fake_exponential(1, excess_blob_gas_t, baseFeeUpdateFraction).
If you're looking to simulate a future “reserve price” setup, just make sure that base_fee_per_blob_gas_t is at least (BLOB_BASE_COST × base_fee_per_gas_t) / GAS_PER_BLOB. You can find more details at (eips.ethereum.org).

To calculate the cost for each blob in a block, you simply take the base_fee_per_blob_gas_t, multiply it by 131,072 (in ETH), and then multiply that by how many blobs your batcher is posting.

It seems like you forgot to add any pseudocode in your message. If you could share the pseudocode you'd like me to work on, I'd be more than glad to assist!

GAS_PER_BLOB = 2**17
TARGET = 6
UPDATE_FRACTION = 5_007_716
MIN_BLOB_BASE = 1  # wei

def fake_exponential(factor, numerator, denominator):
    i = 1
    output = 0
    numerator_accum = factor * denominator
    while numerator_accum > 0:
        output += numerator_accum
        numerator_accum = (numerator_accum * numerator) // (denominator * i)
        i += 1
    return output // denominator

def step(parent_excess, parent_basefee_blob_gas, blobs_used, basefee_exec_gas=None, reserve_cost=None):
    parent_excess = max(0, parent_excess + blobs_used*GAS_PER_BLOB - TARGET*GAS_PER_BLOB)
    bf_blob = fake_exponential(MIN_BLOB_BASE, parent_excess, UPDATE_FRACTION)
    # Optional: reserve price (EIP-7918)
    if reserve_cost:
        bf_blob = max(bf_blob, (reserve_cost * basefee_exec_gas) // GAS_PER_BLOB)
    cost_per_blob = bf_blob * GAS_PER_BLOB
    return parent_excess, bf_blob, cost_per_blob

Where reserve_cost is set to BLOB_BASE_COST (for example, 2**13), and basefee_exec_gas represents the EIP‑1559 base fee for execution gas. For more details, feel free to check out eips.ethereum.org.

7.2 Volatility envelopes for guardrails

Up-swing envelope: Imagine we have 9 blobs spread across N consecutive blocks. By applying roughly +8.2% compounding, we can calculate how many blocks we need to go through before we hit a spending cap or service level agreement (SLA).
Down-swing envelope: If we kick things off with 0 blobs, we can use about -14.5% compounding to get a sense of how long it’ll take us to recover from a spike.

These can be super handy for setting up alerts. For example, you might say, “If a 9-blob streak sticks around for over 9 blocks, think about doubling the max_fee_per_blob_gas or try switching to staggered posting.” Check it out here: (eips.ethereum.org)

7.3 Blob vs calldata “flippening” threshold

Calldata prices are currently sitting pretty between 4 to 16 gas per byte. This depends on whether the byte is a zero or a non-zero value, and it's all tied to the execution base fee. On the flip side, if we're talking about blob data, it’s around 1 blob-gas per byte as per the blob base fee. During the busy times in April 2024, blob gas was still more affordable than calldata, even with the blob base fee being roughly 13.3 times higher than the execution base fee. However, the gap narrowed down to about 19% for some blobs. So, it might be wise to have a backup plan in place to switch small batches to calldata if you think your Service Level Agreement (SLA) could be at risk. (blocknative.com)

8) Practice‑proven tactics to tame cost and variance

Batch shaping with fill efficiency targets:
- Aim for that sweet spot of a blob fill between 97-99% (which means keeping waste to a minimum--around 1-3%). Keep in mind, you're shelling out money for blobs, not bytes!
- Consider a “fill-or-wait” approach where you set a max wait time (maybe 20-40 seconds) to make sure everything runs smoothly for users and reduces waste. (eips.ethereum.org)
Time-shifting posts:
- If you can be a bit flexible with your posting times, consider hitting those cooler spots. When you’re below the target, there’s roughly a 14.5% decay per block, so holding off for 4-5 blocks that aren’t maxed out can really cut your costs down by half, and you'll still meet your settlement SLAs. (eips.ethereum.org)
Quantile-based fee caps:
- Start by determining the p95/p99 values for the base_fee_per_blob_gas based on your simulations under expected conditions. After that, tweak your max_fee_per_blob_gas to help avoid those pesky posting failures.
Market-aware reserve modeling:
- If EIP-7918 rolls out, make sure to link your minimum expected blob base fee to the execution base fee. You can think of your reserve like this: ( \text{(BLOB_BASE_COST/GAS_PER_BLOB)} \times \text{base_fee_per_gas} \approx \text{base_fee}/16 ) using the current EIP constant. This approach helps you steer clear of those wild underbids when gas prices shoot up. (eips.ethereum.org)
Multi-track fallback:
- Have a strategy lined up for those unexpected traffic spikes. Consider switching to smaller, more frequent blobs, and if possible, crank up the compression. And if things get really tight, don’t hesitate to let those small deltas slip into calldata when the price gap gets narrow. Just remember, the April 2024 scenario is your ultimate trial run. (blocknative.com)
What you should already be keeping an eye on:
- Monitor base_fee_per_blob_gas and excess_blob_gas for every block.
- Pay attention to blobGasUsedRatio (you can find this through eth_feeHistory). It's important for clients to know the max per fork, which is now all set in blobSchedule (thanks to EIP-7840). Check it out here: (eips.ethereum.org).

9) Post‑Pectra reality check: what the market did

After May 7, 2025, daily blob purchases by rollups saw a nice bump of about 20.8% compared to the previous 60-day average. They jumped from roughly 21,200 to around 25,600 a day. But here's the catch: the average blobs per block still didn't quite reach that new target of 6 blobs. Because of this, blob prices stayed pretty close to the floor again, thanks to the “smoothing” effect of 6/9, which helped keep those peaks in check. Just so you know, it's probably a good idea not to get too comfy with today’s low prices; this whole situation is really about capacity and responsiveness, so it doesn’t mean costs won’t pop up later on. (galaxy.com)

10) Worked examples for decision‑makers

Example A: posting at a 16 gwei execution base fee with a reserve price (in the future EIP‑7918 world)
- The reserve blob base fee per blob-gas works out to about 16 gwei / 16 = 1 gwei, which comes to roughly ~0.000131072 ETH for each full blob.
- If you’re looking to post 5 blobs in each block over 100 blocks, your reserve-only burn will total around 5 × 0.000131072 × 100 = 0.065536 ETH (and keep in mind, this doesn't include the execution wrapper and tips). So, think of this amount as your “backup plan” for when gas prices start climbing. (eips.ethereum.org)
Example B: surge tolerance during a 9-blob streak
- So, here’s the deal: if you kick things off with a blob base fee of 1 gwei, after pumping through 9 full blocks, the fee is going to climb to around 1×(1.082)^9 ≈ ~1.99 gwei. That means your ETH burn per blob is practically going to double in about 2 minutes. It's a good idea to get your batchers ready--either have them stagger their posts over time or keep a little headroom for that quantile. (eips.ethereum.org)
Example C: decay after a lull
- If you're looking to drop fees from 2 gwei down to about 1 gwei, expect it to take around 5 mostly empty blocks. Each block will chip away at the fee by roughly -14.5%. So, if your service level agreement (SLA) can tolerate a delay of about 1 to 1.5 minutes, you could seriously slash those costs! (eips.ethereum.org)

11) Implementation checklist (what to ask your team for)

Instrumentation
- Monitor data on a per-block basis, including blobs_used, base_fee_per_blob_gas, excess_blob_gas, execution base fee, and blobGasUsedRatio.
- Create alerts to notify you when a rolling window of 9 blobs hits or exceeds N blocks (like N=6 for instance) or if the base_fee_per_blob_gas surpasses your 95th percentile threshold.
Simulation & Budgeting
- Start by running a rolling 30/90-day Monte Carlo simulation based on the demand patterns you've noticed, plus some worst-case spikes (just remember to calibrate it to the 2024 blobscription event). You can dive into the details here.
- Create p50, p95, and p99 burn forecasts for both 6 and 9; don't forget to update these whenever the fork parameters change (you can find all that info in blobSchedule). For more specifics, check out this link.
Policy
- Put together a volatility playbook that clearly outlines the thresholds for splitting batches, adjusting timing, or activating calldata fallback. Additionally, establish upper limits for max_fee_per_blob_gas during "peak" and "extreme" situations.
Getting Ready for Parameter-Only Forks
- Stay updated on EIP-7892 so your operations plan is all set for those little, frequent blob parameter tweaks. These changes can seriously impact the balance or responsiveness without throwing the protocol out of whack. Check out more details here.

12) FAQ for CFOs and program managers

Are blobs “permanently cheap” after Pectra?
Not exactly. While Pectra has increased capacity (aiming for 6, with a max of 9), it has definitely helped reduce some of the scarcity problems and smoothed out those wild price swings. However, there's still a bit of volatility to keep an eye on; the price curve tends to drop faster when there’s less usage, but it rises more slowly when things get a bit tight. (eips.ethereum.org)
Will the protocol keep blob prices linked to execution gas?
Possibly! EIP‑7918 is in its Last Call phase and aims to set a reserve price that’s roughly 1/16 of the execution base fee, built on the current constants. This could really help in stabilizing the markets when execution costs are the main worry. Just a heads up, though: those constants might shift before it officially rolls out. (eips.ethereum.org)
So, did Pectra actually launch, and when did that happen?
Yup, it launched! The big day was May 7, 2025 (epoch 364032). If your models are using "go-live" data, be sure to tie them to that date. Check it out here: (blog.ethereum.org)

13) Bottom line

EIP‑7691 isn’t just about creating more space; it’s also about tweaking incentives to help prices drop faster during the slow times and rise more steadily when things get busy.
You can use the 6/9 curve math to set your alerts and hedge your bets: expect around −14.5% per block when prices are falling, and about +8.2% per block when they’re climbing back up.
Get ready for reserve‑price coupling with execution gas (EIP‑7918), and keep your eyes peeled for more frequent, lighter blob parameter forks (EIP‑7892) that could shake things up a bit.

If you want to turn this into a solid production-ready simulator and batching policy, 7Block Labs is here to help. They'll create a model, set up dashboards, and give you all the implementation tips you need in under two weeks.

References and further reading

EIP‑7691: We're aiming to ramp up blob throughput to 6, with a possible max of 9. Plus, there's an update on how we handle asymmetry in up/down movements. You can find the details here: (eips.ethereum.org)
EIP‑4844: This one takes a closer look at how we calculate blob fees, focusing on GAS_PER_BLOB, fake_exponential, and some header fields. Definitely worth a read! (eips.ethereum.org)
EIP‑7840: In this proposal, we set the blobSchedule parameters for each fork, including target, max, and baseFeeUpdateFraction. Check it out! (eips.ethereum.org)
EIP‑7892: This one introduces Blob Parameter Only hardforks, which should help us scale blob capacity in a more predictable and precise way. Dive in for more info! (eips.ethereum.org)
EIP‑7918: Here, we’re linking the reserve price to execution gas, plus we’ve got some interesting insights on delayed responses and empirical analysis. Don't miss it! (eips.ethereum.org)
Pectra Mainnet Activation: Be sure to check out the details on the exact date and time for this, along with the latest client releases. You won’t want to miss it! (blog.ethereum.org)
Volatility Case Study: Here’s a fascinating look at the first EIP‑4844 congestion event, where we noticed a significant spike in “blobscription.” Check it out! (blocknative.com)
Post‑Pectra Market: Blob purchases have surged by about 20.8%, but average usage is still lagging behind targets, leading to some near-floor prices. Get the full picture here: (galaxy.com)