Blob Budgeting After Pectra: Designing Rollups Around EIP-7691

A Practical Guide to Sizing, Scheduling, and Pricing Your Rollup's Data After Ethereum's Pectra Upgrade

So, after Ethereum rolled out its Pectra upgrade, they actually doubled the blob capacity! Plus, they've increased the floor costs for calldata. Pretty interesting stuff, right? We know this is a significant change in how we deal with data, but no worries! We're here to simplify everything for you. We're going to break down these new fee mechanics into simple budgeting rules, useful formulas, and checklists that your team can jump into right away. It’ll be super easy to get started!

Understanding Blob Capacity and Calldata Costs

Now that the upgrade’s here, it's super important to get a handle on how these changes will affect your rollup. Alright, here’s the scoop:

Blob Capacity: With this boost in capacity, you'll have way more room to stash your data in blobs. It's really a game changer when it comes to scaling up!
Calldata Floor Costs: So, with the updated minimum costs, it's super important to keep these in mind when you're figuring out your pricing strategy.

Key Budgeting Rules

As you dive into this new situation, here are a few budgeting tips to keep in mind:

1. Check Out Your Data Needs: First things first--take a moment to see just how much data your rollup is handling right now. This will give you a pretty good idea of how much extra capacity you might want to consider.

2. Keep an Eye on Rising Costs: Don’t forget to factor in those new calldata floor costs when you’re putting together your budget. It’s easy to overlook, but it can really affect your bottom line! So, what this really means is you'll need to rework those financial projections.

3. Revamp Your Pricing Strategy: Given the changes in costs, it might be a good idea to take a fresh look at your pricing. You’ll want to stay competitive, but also make sure you’re covering your costs.

Handy Formulas for Your Team

Check out these formulas that can help you figure out costs and capacity in a smart way:

So, to figure out the total cost, you just take the size of the blobs and multiply that by how many blobs you have. Then, you add the floor cost for calldata, which you also multiply by the number of transactions. Easy peasy!

To figure out how much capacity you’ll need, just add your current data size to the growth you expect.

Just plug in your numbers, and you'll see exactly what to expect!

Checklists for Implementation

To help keep things organized, here’s a handy checklist your team can use:

Take a look at how we’re using data right now and think about what we might need down the line.
Let's update the budget to account for the higher calldata costs we've been seeing.
Take a look at our pricing to ensure we're staying profitable. Let’s come up with some fresh ideas for using blobs more effectively! Keep an eye on the ongoing costs and tweak things as needed.

If you follow these steps, you'll be able to size, schedule, and price your rollup's data after the Pectra upgrade like a pro! Make sure to keep this guide close by so your team can stay focused and be ready to roll with any changes that come your way!

TL;DR for decision‑makers

So, on May 7, 2025, Ethereum officially launched its Pectra upgrade on the mainnet. It's pretty exciting stuff! With this upgrade, the blob target has now doubled to 6, and the maximum per block has increased to 9, all thanks to EIP-7691! These changes are really going to shake things up for Layer 2 data and should help keep prices steady for everyone who posts regularly. If you want to dive deeper into it, you can check it out here.

So, with the latest update, things have gotten pricier when it comes to calldata for those data-heavy posts, all thanks to EIP-7623. Honestly, switching back from blobs to calldata is just a clever strategy for those occasional spikes. We've laid out those thresholds for you right here. Hey! If you want to dive into the details, just click here. It’ll take you right to all the info you need!

What changed in Pectra (and why it matters to rollups)

EIP-7691 really ramped up Ethereum's blob throughput with a few important updates:

The number of target blobs per block shot up from 3 to 6! We've bumped up the max blobs per block from 6 to 9. Hey there! Just a quick update: the TARGET_BLOB_GAS_PER_BLOCK has been set at 786,432. Hey, just a heads up--the MAX_BLOB_GAS_PER_BLOCK has increased to 1,179,648! So, just a heads up: the new sensitivity for BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE is set at 5,007,716.

If you want to dive deeper into this, feel free to hop over to eips.ethereum.org for more info!

Two Operational Consequences for Rollups

More Headroom: With the new setup, you've got the capacity to handle about 7 daily blobs now. Pretty cool, right? So, we're talking about 91 GiB here, which breaks down to 9 blobs, each one being 128 KiB, and then we’ve got around 7200 blocks getting handled each day. Wow, this is a great upgrade from the old 6-blob limit, which topped out around 5 blobs! 27 GiB. Alright, so here's the deal: we're aiming to nearly double our target-rate capacity. We're moving up from about 2. 64 GiB to 5. 27 GiB per day. If you want to dive deeper into the details, feel free to check it out here.
Varied Fee Sensitivity: With the new 2:3 target:max ratio in place, the blob base fee now reacts more quickly when usage drops below those target levels. This means it adjusts better to changes, making it a bit more flexible. So, based on the guidelines in EIP-7691, whenever there's a “full blob section,” you can expect the base fee to shoot up by roughly 8. 2% per block. On the other hand, if there's an empty section, it can drop the score by about 14 points. 5%. This method is specifically crafted to help us recover faster after those slow times. If you want to dive deeper into this, just click here for all the details!

Calldata has gone through some changes lately, all thanks to EIP‑7623. This new update establishes a baseline price for those data-heavy transactions. Pretty neat, right? Here’s the breakdown:.

Zero byte: You’ll need at least 10 gas per byte, which is the minimum.
Non-zero byte: It costs at least 40 gas per byte.

This little adjustment helps to lower the maximum possible size of execution payloads, which is great news. It also promotes using data availability (DA) through blobs, making things a bit smoother overall. Right now, it's a bit more challenging to keep calldata cheaper than blobs, unless blob prices take a big jump. If you want to dive deeper into the details, just head over to eips.ethereum.org. You’ll find everything you need there!

Finally, EIP-7840 has established a standard for clients to access blob parameters using what's known as the "blobSchedule." This really simplifies things for fee estimators and node setups when it comes to monitoring per-fork values, like Cancun and Prague. They can do it without having to mess around with those pesky quirks of the Engine API. If you want to dig deeper into the details, you can take a look here. Happy exploring!

Quick reference: the constants your team should use

Blob size: So, we’ve got a blob that’s 131,072 bytes, which is basically 128 KiB. That's the same as saying it’s made up of 4,096 chunks, each one being 32 bytes long. (eips.ethereum.org).
GAS_PER_BLOB: So, each blob will set you back 131,072 blob-gas. (eips.ethereum.org).
Blob Pruning: So, here's the deal with blob pruning: it usually happens after around 4,096 epochs, which takes about 18 days. That means it's smart to think ahead and make sure you have a plan for keeping that data off-chain. (eips.ethereum.org).
Post-Pectra “blobSchedule” (EL config): So, we’re looking at a target of 6, with a max of 9, and the base fee update fraction is set to 5,007,716. (eips.ethereum.org).

Example Client Config

Just a heads up, this is a template, so don’t forget to personalize it a bit to match your client’s style!

client:
  name: "Your Client's Name"
  version: "1.0"
  settings:
    timeout: 30
    retries: 5
    logging: 
      level: "debug"
      format: "json"
  endpoints:
    api: "https://api.yourclient.com/v1"
    docs: "https://docs.yourclient.com"

Key Points to Consider:

Client Name: Swap out "Your Client's Name" for the real name of your client.
Versioning: Just a quick reminder to double-check that you're using the correct version number every time! It’s super important to keep things straight.
Timeout and Retries: Feel free to tweak these settings to fit your client's needs. Some might need a bit more time before timing out or could benefit from extra retry attempts. Just keep their preferences in mind!
Logging Levels: Pick the logging level that works best for you. Using "debug" is awesome during development, but it might be a bit much when you're in a production environment.
Endpoints: Make sure to give all the API and documentation links a once-over to confirm they’re current.

If you have any questions about how to customize this, don’t hesitate to ask! I'm here to help!

"blobSchedule": {
  "cancun": { "target": 3, "max": 6, "baseFeeUpdateFraction": 3338477 },
  "prague": { "target": 6, "max": 9, "baseFeeUpdateFraction": 5007716 }
}

This is pretty important since fee estimators and analytics tools, like those ratio fields you see in fee history, depend on the max and target values for each fork. If you're interested in learning more about it, just hop over to this link: (eips.ethereum.org).

The blob fee market after Pectra: what we’ve observed

Once everything was activated, the price of "blob objects" on the consensus layer really took a hit. So, Galaxy Research noted that right after Pectra rolled out, the average cost for a blob object shot down to almost nothing. Just a quick note, though: this doesn’t factor in the transaction fees for EL type-3 stuff. This definitely showed that there was plenty of extra capacity available, and honestly, the auction was flowing pretty smoothly at the higher target. (galaxy.com).
Just a heads up, don’t settle in too comfortably--things can still get a bit wild! In 2024, during the whole “blobscription” craze, the blob base fee per gas really exploded, jumping from just 1 wei to around 650 gwei per blob gas. It’s interesting to note that blobs were typically more affordable than calldata for the most part! Pectra has set a higher target, and with EIP-7623 raising the calldata floor, there's now a larger buffer before calldata really starts to come into play. (blocknative.com).

Implication: Make sure to plan your budget for regular blob usage - don’t just hang back and wait for those price drops. At the same time, it’s smart to put some boundaries in place for those surprise short spikes that can catch you off guard.

Budgeting blobs: concrete formulas and break‑even thresholds

Use These Three Rules to Choose Between Blobs and Calldata:

1. Size Matters: When you're dealing with big chunks of data, blobs are usually the way to go. They can easily manage larger sizes, which makes them a great fit for more demanding tasks.

2. Access Speed: If you're looking to grab data quickly and often, definitely choose calldata. It's your best bet for speed! It's set up for fast access, which is a total game-changer for apps that really need to perform well.

3. Cost Considerations: Don’t forget to watch those costs! Storing blobs can sometimes get pricey, depending on the situation. If you’re trying to save some cash, definitely think things through before you take the plunge.

Before you start making your blobs, take a moment to decide how big you want your batch to be. Alright, to figure out how many blobs you need, just use this formula: B = ceil(bytes / 131,072). It’s pretty straightforward! Hey, just a quick reminder that you’ll be footing the bill for the padding, so be sure to fill those blobs up nicely! Check it out here: eips.ethereum.org.
The price you pay for a blob per byte matches the base_fee_per_blob_gas. So, here's the deal: each blob-gas is linked to just one byte. That means when you have GAS_PER_BLOB set to 131,072, you're essentially dealing with 131,072 bytes. Pretty straightforward, right? Alright, here’s how to figure out the total blob fee in wei. It’s pretty simple! Just use this formula: Total blob fee (in wei) = B × 131,072 × base_fee_per_blob_gas. So, just plug in your numbers and you’ll have it in no time! (eips.ethereum.org).

3) Calldata Cost Per Byte Under EIP-7623 (When the Floor Binds)

Alright, let’s take a look at this:

If you're dealing with zero bytes, the cost comes to 10 times the base fee per gas.

If there are any non-zero bytes, it ramps up to 40 times the base fee per gas.

Alright, so let's say we use f to stand for the fraction of non-zero bytes in your compressed batch. We can figure out the effective calldata cost per byte like this:

So, here’s the deal: C_calldata is roughly equal to the base_fee_per_gas multiplied by this formula: 10 times (1 minus f) plus 40 times f. ** (eips.ethereum.org).

Break-even: Call Data Selection Criteria

You should only use calldata if this condition is met:

So, when you're looking at base_fee_per_blob_gas, it’s actually calculated using this formula: you take base_fee_per_gas and multiply it by this whole expression: [10 × (1 − f) + 40 × f]. It sounds a bit complex, but you’re essentially adjusting your gas fee based on that factor, f!

Examples: So, if your function f is hovering around 1 (which means it’s mostly not zero), you can basically set your threshold to about 40 times the base fee per gas.

So, if f is close to zero... So, try to set a target around 25 times the base fee per gas. If f is pretty close to zero (like, mostly just zeros), then go ahead and set the threshold to about 10 times the base_fee_per_gas.

When the blobscriptions really took off, the blob base fee shot up to around 13. So, even though the execution base fee is three times higher, blobs frequently ended up being more cost-effective than calldata. With EIP-7623 introducing that new floor, your threshold is typically at least 10 times higher, and sometimes you might even see it around 40 times! So, when you're thinking about switching from blob to calldata, it’s super important to be a bit picky and deliberate about it. (blocknative.com).

A simple “BlobBudgeter” that your sequencer team can implement

Inputs: Alright, so we've got a few things to keep an eye on here:

First up is backlog_bytes, which refers to the amount of data that's still waiting to be posted.
Then there's max_delay_slots, which is related to our service level objectives (SLO).
And last but not least, we have f, which represents that non-zero ratio we see after compressing the data.

That’s a quick rundown!

base_fee_per_blob_gas_now, base_fee_per_gas_now Hey there! Just a heads up, we've got some fresh info on blobGasUsedRatio[] and baseFeePerBlobGas[] that you can check out through eth_feeHistory. Happy exploring!

Heuristics Based on EIP‑7691 Dynamics

So, if the last N slots didn't quite hit the target--like when the average blobGasUsedRatio dips below 0-- If you're looking at prices under 6/9, you might notice they drop a bit faster--about 14 units or so. When a slot is empty, it’s 5% per slot. On the other hand, if it's over the target and at full capacity, you can expect price increases to slow down a bit, maybe around 8%. 2% per slot. For more info, take a look at the details over at eips.ethereum.org.

Pseudocode is basically just a way to lay out algorithms in a format that's easy for people to read and understand. It simplifies the process so you can focus on the logic without getting bogged down in the nitty-gritty of coding syntax. It helps you sort out your program logic without getting stuck in the nitty-gritty details of programming languages. Here's a simple guide to kick off your pseudocode writing journey!

Key Concepts of Pseudocode

1. Prioritize Clarity: It's much more important to make your ideas easy to understand than to get every single programming rule right.

2. Keep It Real: Just say things in simple, everyday language, whether it's English or whatever language you prefer. This really helps anyone looking at your pseudocode get a clear picture of what's going on.

3. Indentation for Structure: Just like in real coding, don’t forget to use indentation to show the different levels of logic. This helps with loops and conditional statements!

Basic Structure

Alright, let’s dive into some of the basic concepts you’ll encounter when you're writing pseudocode.

Variables: Just keep it straightforward when you're declaring them.
```
SET counter TO 0
```
Input/Output: Make sure to let everyone know when you're asking for input or when you're showing the output.
```
DISPLAY "Enter your name:"
INPUT userName
```

Conditions:

IF counter < 10 THEN
    DISPLAY "Counter is less than 10."
ELSE
    DISPLAY "Counter is 10 or more."
END IF

Loops: Just let me know how many times you want to repeat something, and we’ll keep it going!
```
WHILE counter < 10 DO
    counter = counter + 1
END WHILE
```

Example Pseudocode

Alright, let’s check out a quick example where we add up all the numbers from 1 to 10.

SET total TO 0
FOR number FROM 1 TO 10 DO
    total = total + number
END FOR
DISPLAY total

Tips for Writing Good Pseudocode

Stay Consistent: Make sure you stick to the same terms and format in your pseudocode. It really helps keep things clear!
Brush Up and Check It Out: Once you've jotted down your pseudocode, take a moment to read it over. Make sure it all clicks and makes sense. Sure! Here’s a more relaxed version of your message while still keeping the same info:

Just a heads-up: I've got all my training based on data up to October 2023.

Feel Free to Add Comments: If there's anything that seems a bit unclear, don't hesitate to jot down your thoughts or notes to clarify how you're thinking about it.

Writing pseudocode can actually be a pretty enjoyable and efficient way to get your ideas down on paper. Whether you're gearing up for a coding project or trying to wrap your head around an algorithm, it's definitely a useful tool to have in your toolbox!

def plan_blob_posts(backlog_bytes, max_delay_slots, f, 
                    base_fee_per_blob_gas, base_fee_per_gas,
                    blobGasUsedRatio, slots_ahead=6):
    bytes_per_blob = 131072
    need_blobs = math.ceil(backlog_bytes / bytes_per_blob)

    # Compute calldata break-even blob gas price
    calldata_per_byte = base_fee_per_gas * (10*(1-f) + 40*f)  # gas per byte
    blob_break_even = calldata_per_byte  # wei per blob-gas

    # Predict blob fee drift using last few slots: crude envelope
    recent = sum(blobGasUsedRatio[-3:])/3 if len(blobGasUsedRatio)>=3 else 0.66
    def next_fee_estimate(fee, used_ratio):
        # Approximations from EIP-7691 rationale
        if used_ratio >= 1.0:   # full blob section
            return fee * 1.082
        if used_ratio <= 0.0:   # empty
            return fee * 0.855
        # linearize between 0 and 1 for a quick proxy
        return fee * (0.855 + 0.227*used_ratio)

    fee_path = [base_fee_per_blob_gas]
    for i in range(slots_ahead):
        fee_path.append(next_fee_estimate(fee_path[-1], recent))

    # Target a smoothed cost: spread posts across S slots, capped by SLO
    S = min(slots_ahead, max_delay_slots, max(1, math.ceil(need_blobs/3)))
    blobs_per_slot = math.ceil(need_blobs / S)

    # Price cap per slot: below both break-even & predicted path
    cap_per_blob_gas = min(blob_break_even * 0.9, min(fee_path))  # 10% safety

    return {
        "slots": S,
        "blobs_per_slot": blobs_per_slot,
        "max_fee_per_blob_gas": int(cap_per_blob_gas),
        "switch_to_calldata_if_blob_gas_over": int(blob_break_even)
    }

Notes:

If you want to find out about baseFeePerBlobGas and blobGasUsedRatio, just check them out with eth_feeHistory. It's pretty straightforward! After the 4844 update rolled out, a bunch of clients and providers got access to these two fields. If you're looking for more info, you can find all the details here. Give it a click!

Hey there! Just a little reminder to keep an eye on those type-3 mempool replacement rules. If you're looking to give your blob fees a boost, bumping them up by about 1 should do the trick! It's like what EIP-1559 recommends -- just a simple 1× for replacements. If you’re looking for more details, check out the EIP-4844 documentation here. It's got all the info you need!

How many blobs should you buy per batch?

Let's take a moment to chat about SLOs, which basically refer to the maximum latency we can handle from L2 to L1. It's crucial to keep that in mind. And then there's the concept of the “cost slope.” It’s all about balancing performance with expenses, right? Understanding these two factors together really helps us make smarter decisions down the line.

So, if you're going for that 6-blob target, it's pretty fascinating how even a couple of empty slots can seriously bump up the fees--like around a 14% hit, give or take. 5%/slot when they're empty). If you can hold off on filling 1 or 2 slots for a bit, it could really help save some money.

On the other hand, when the sections fill up, the base fee doesn’t spike as fast--it's only about a +8 increase. 2%/slot). So, what this really means is that regularly posting close to the target is way more cost-effective than waiting until your backlog hits the max of 9 and then trying to fill a bunch of slots all at once. It's all about keeping things steady rather than cramming it in at the last minute! If you want to dive deeper, just click here: (eips.ethereum.org). Enjoy exploring!

Here's a helpful tip for you: aim to stick to what we call "near target" consumption. It's a good guideline to follow! So, when you're dealing with a steady load, aim for around 4-6 blobs per slot instead of trying to push for those bigger bursts of 8-9. It's all about keeping it manageable!

Worked examples you can plug into your budget

So, let me break down the costs for you if you want to post about 1 MiB (that’s 1,048,576 bytes) of compressed data.

You'll need a total of 8 blobs. So, if you take 8 and multiply it by 131,072, you get a total of 1,048,576 blob-gas. Pretty cool, right? So, if we're looking at 1 wei for each blob-gas, that adds up to a whopping 1,048,576 wei. If we do the math, that’s roughly 0. 000001048576 ETH. So, if you're talking about 1 gwei per blob-gas, then you're checking out a total of 0. 001048576 ETH. So, at 100 gwei for each blob-gas, that'd come out to 0. 1048576 ETH.

Just a quick reminder: there’s a bit of extra overhead from the execution layer (you know, those type-3 transactions), but honestly, it’s usually not a huge deal compared to those higher blob prices. For more info, feel free to check it out at eips.ethereum.org.

2) When Should a Rollup Temporarily Fall Back to Calldata?

Alright, so imagine we're starting with a base fee of 3 gwei. So, here's the scoop on how the break-even points play out with different values of f:.

So, if f is around 1 (which basically means we’re looking at non-zero heavy), the break-even point comes out to be roughly 40 times 3. That gives us around 120 gwei per blob-gas.

If f is close to zero. So, if we look at 5, the break-even point actually falls to around 25 times 3. That brings us to about 75 gwei for each blob-gas. So, when f is pretty much hovering around 0, which means we’re seeing mostly zeros, we can expect the break-even point to land around 10 times 3. That brings us to about 30 gwei per blob-gas.

In the past, we've seen gas fees shoot up to around 650 gwei per blob-gas, but honestly, that usually only happens during some pretty crazy events. In the big picture, calldata is still more of an exception, especially with the EIP-7623 floor coming into play. If you want to dive deeper into this topic, head over to Blocknative and check it out!

Operational checklist (post‑Pectra)

Node/client readiness Hey there! Just a quick reminder to check that your EL/CL clients are all set up with the Pectra-ready releases. Remember, the mainnet went live on May 7, 2025, during epoch 364,032. Make sure you're good to go! Check it out here. Hey, just a quick reminder to double-check your EL chain config! Make sure you've got the “blobSchedule” parameters all set. You’ll need to have your target at 6, max at 9, and baseFeeUpdateFraction at 5,007,716. It’s easy to overlook, so better safe than sorry! If you want to dive deeper into this topic, you can check out more details here.
Estimating and Keeping an Eye on Fees. To get started, you can use eth_feeHistory along with baseFeePerBlobGas and blobGasUsedRatio from the last 20 to 100 blocks. This will help you come up with some smart, percentile-based caps. Check it out here.
Go ahead and set up alerts for when: So, if you look at base_fee_per_blob_gas, it's gonna be about 25 to 40 times higher than base_fee_per_gas, depending on the factor you pick. Looks like your backlog_bytes has gone over the limit you set.
And you’ll notice that when those spikes happen, the reorg rate tends to go up.
Mempool and How Replacement Works. To make sure everything runs smoothly, we’re kicking off a 1. Just a quick reminder to bump up those blob-fee replacements! This should definitely help avoid any issues with posts getting stuck. Take a look at this: (eips.ethereum.org). You might find it pretty interesting!
Storing and accessing data. So, blobs are typically pruned about 18 days after they're added. Because of that, it's a smart move to hang onto some extra off-chain storage and make sure to index everything using the commitment or versioned hash. Hey, just a quick reminder to regularly test your recovery process! It’s super important to keep things running smoothly. You can check out more details here: eips.ethereum.org.

Packaging data efficiently for 128 KiB blobs

Fill every blob: Just a heads up, you want to make sure you’re utilizing the full 128 KiB you’re paying for, even if it doesn’t seem completely packed. Try to group your stuff together so that your blobs come out to about 100-127 KiB once you compress them.
Compression: Try using speedy, frame-friendly codecs like zstd at low to mid settings. Also, consider using binary encodings that keep non-zero density low. This is especially important to keep in mind if you think you might need to rely on calldata down the road. The smaller your non-zero fraction (f), the simpler it is to reach that break-even point for your calldata.
Homogeneous batches: When you mix really sparse and dense parts, it can really mess things up. To keep your cost model steady, it’s a good idea to break things down a bit. That way, you’ll get more reliable results.

How Pectra changes your sequencing strategy

Whenever things are running smoothly, aim to drop around 4 to 6 blobs per slot. It really helps keep the flow going! This keeps you close to the auction's "sweet spot" and helps manage long-term fluctuations, all thanks to the way the asymmetric update fraction operates. (eips.ethereum.org). Instead of cramming all your posts into those last few minutes of an epoch, try to space them out more evenly throughout the slots. It’ll help you maintain a steady flow and keep things interesting! With the new higher target, even a few quieter time slots can really work wonders in bringing that base fee down--like, we’re talking about getting it down to around 14. You'll get 5% for every empty slot.

Go ahead and set up an automated “calldata breaker,” but don’t forget to keep it in check with that formula I mentioned earlier. In real-life situations, it’s pretty unlikely that most teams will reach those 25-40× benchmarks after the Pectra and EIP-7623 updates. (eips.ethereum.org).

Tooling tips (engineering teams)

Don't forget to display these signals on your Grafana dashboards! So, the base_fee_per_blob_gas is taken from the next slot in the fee history, and it also shows the percentage change over the last 8 to 16 slots. So, take a look at the blobGasUsedRatio from the last 64 slots. You’ll want to compare that to the target ratio, which is 6 out of 9, or roughly 0.66. 666….
Make sure to check out the backlog bytes. This will help you get a sense of how many “blobs required” you need based on the current compression ratio.
Show the break-even points for calldata when f takes on a value of {0. 25, 0. 5, 0. 75, 1. 0}. Hey, just a quick reminder to grab both the EL tx and CL blob object receipts! When you're diving into those anomalies, it's really helpful to see how the EL inclusion lines up with the CL gossip timings. Trust me, it makes a difference! Why not give your replacement logic a little workout? Try tossing in some type-3 transactions that intentionally underbid or overbid. It'll be a good test! Make sure your 1. So, that’s when the 1× bump logic really starts to come into play! For more info, just click here. You’ll find all the details you need!

What’s next to watch (so your budget model stays current)

EIP‑7918 (Last Call): So, this proposal is all about tying the reserve price for blobs to the execution gas costs. The idea here is to keep the blob market above a specific portion of what it costs to run stuff on the execution layer. It's a pretty neat way to make sure everything stays balanced! It's a smart idea to address those underpricing issues and adjust your break-even calculations a bit. Just remember to keep your estimators modular--it's really going to help in the long run! You can check out more about it here: eips.ethereum.org.
EIP‑7762 (Review): So, in this update, we’re thinking about raising the MIN_BASE_FEE_PER_BLOB_GAS. The idea is to make things a bit snappier when it comes to figuring out prices. It also gives you the option to reset excess_blob_gas at fork points, which should help raise the minimum blob price. (eips.ethereum.org).
PeerDAS: This might just be the answer to boosting data availability a whole lot without needing to crank up the bandwidth in a straight line. Over time, it's really going to change how we think about our abilities and the risks we take. The Ethereum Foundation has highlighted this path as the way to scale beyond Pectra. (blog.ethereum.org).

Executive takeaways

When you’re putting together your budgets for blobs, it’s a good idea to think of them as your default choice for data analytics.
With Pectra's 6/9 and the calldata floor from EIP‑7623, blobs are definitely the way to roll when things are steady. Absolutely! There might be a few ups and downs here and there, but with those uneven updates and a higher target in place, you’ll see prices usually drop pretty fast as soon as demand slows down. It’s interesting how that works! (eips.ethereum.org).

Hey, have you thought about setting up this super useful automated tool called the "BlobBudgeter"? This handy little assistant can help balance your purchases and even set limits on your bids using feeHistory. Plus, it only switches to calldata when the numbers really add up.

Just a heads up: make sure your node setups and fee estimators are designed to be aware of different forks. It's pretty important! Be sure to take full advantage of EIP‑7840’s blobSchedule, and don’t forget to keep an eye on the blobGasUsedRatio. Staying in sync with the protocol is key! (eips.ethereum.org).

How 7Block Labs can help

We develop and oversee blob-aware sequencers and fee engines that are tailored just for production rollups. If you’re looking for:.

We've got a solid BlobBudgeter that comes with percentiles for caps and smart smoothing that takes SLAs into account.
We've got dashboards and alerts set up that track the baseFeePerBlobGas and the blobGasUsedRatio.
Here are some benchmarks for your compression pipeline, including those non-zero ratios (f), or.
We’ve got a solid plan for retaining and recovering data. Blobs will be cleaned up after 18 days, keeping everything tidy and efficient!

We can team up to get your stuff shipped in just a few weeks instead of stretching it out for months. It's all about making things quicker and easier for you!

Sources and further reading

EIP‑7691: This proposal is really about cranking up blob throughput. It zeroes in on some key parameters and how fees react to changes. Check it out here.
Pectra Mainnet Activation: Hey, don’t forget to save the date! May 7, 2025, is when the Pectra mainnet officially kicks off at epoch 364,032. It’s going to be an exciting milestone, so make sure you’re ready for it! Get the details here.
EIP-7623: So, this proposal is all about increasing the calldata cost, setting a minimum of 10/40 for transactions that are packed with a ton of data. It's an interesting move to consider, especially for those more data-heavy transactions. If you want to dive deeper into this topic, you can check out more details here.
EIP‑4844: Let's take a closer look at Proto‑Danksharding. We’ll talk about blob sizes, GAS_PER_BLOB, how pruning windows work, and break down the fee formulas. Get the scoop here.
EIP-7840: This one is all about establishing the blob schedule in the execution layer configs. It takes into account the target, maximum, and update fractions for each fork. Check it out here.
Blocknative: They’re diving into blobscriptions and tackling those annoying price spikes, helping to shed some light on the recent ups and downs we’ve been seeing. Read more here.
Galaxy: So, they've been diving into the costs of blob objects after the whole Pectra thing, and they've come up with some initial thoughts.
Hey, take a look at their insights right here. You might find it super interesting!
Execution API: Curious about the feeHistory fields for blobs? Well, you've got some key details to check out, like the baseFeePerBlobGas and the blobGasUsedRatio. Find out more here.