Summary: A practical, decision‑maker’s guide to Etherscan’s View Blobs page and how proto‑danksharding, Pectra, and the coming PeerDAS era reshape Ethereum data strategy, costs, and observability for L2s and enterprise builders. We translate specs into checklists, formulas, and emerging best practices you can act on today.

txsBlobs and the Future of Ethereum Data

If your product depends on Ethereum data availability—whether you run an L2, submit batched proofs, or audit counterparties—blobs are no longer optional plumbing. They’re a first‑order cost center and a live operational signal. This post explains how to read Etherscan’s “View Blobs” page, how blob fees are really calculated, what changed after Pectra, and what PeerDAS and parameter‑only “BPO” forks mean for your 2026 roadmap. We include concrete examples and a checklist you can use with your team this week.

The 60‑second refresher: what a “blob” is (with exact numbers)

A blob is a ~128 KiB chunk of temporary data carried by a new Type‑3 transaction introduced in EIP‑4844 (proto‑danksharding). Each blob is 4,096 field elements × 32 bytes = 131,072 bytes. The transaction references blobs via versioned hashes; the version byte is 0x01 today. (eips.ethereum.org)
Blob storage lives on the consensus layer (beacon chain) and is pruned after 4,096 epochs—about 18 days. Permanence is via a KZG commitment that stays in canonical history. (eips.ethereum.org)
Blobs use a separate EIP‑1559‑style fee market (“blob gas”) with its own base fee and elasticity. Pre‑Pectra parameters targeted 3 blobs per block (max 6). (eips.ethereum.org)

Why it matters: blobs are priced far below calldata for DA‑heavy workloads, and they’re not readable by the EVM—exactly what rollups want for posting batches. (info.etherscan.com)

A guided tour of Etherscan’s “View Blobs” page

Open https://etherscan.io/txsBlobs and you’ll see a live stream of blob sidecars associated with mainnet transactions. Columns to know: (etherscan.io)

Blob Versioned Hash: The 32‑byte identifier of a blob’s commitment hash with version prefix. Use this to cross‑reference external archives or your own storage. (eips.ethereum.org)
Transaction Hash: The L1 Type‑3 transaction carrying one or more blobs.
Block and Timestamp: Where/when the blob was included on L1.
Blob Sender: Etherscan’s label for the submitter—often “Base: Batch Sender,” “Arbitrum Batch Poster,” “Blast: Batch Sender,” etc. This is invaluable for watching counterparties and competitors. (goto.etherscan.com)
Gas Price: The transaction’s gas price display; for blob economics, focus on the blob fee terms below rather than the legacy gas line alone. (etherscan.io)
Size: Always 128 KiB per blob on mainnet; senders pay the full blob even if under‑filled. (eips.ethereum.org)
Excess Blob Gas: A snapshot of the EIP‑1559 “excess” running counter used to compute the blob base fee. When this is high, the next blocks’ base fee per blob gas trends up; when low or negative drift, it trends down. (eips.ethereum.org)

Tip: Etherscan also surfaces blob counts per block on the Blocks page, and their info center links to the latest blob gas price from the same “View Blobs” page. (info.etherscan.com)

Fees: the exact formula you should budget against

Blob transactions pay two independent fees:

Calldata/EVM fee: computed as usual from gasUsed × effective gas price, but note the calldata repricing from EIP‑7623 (details below). (eips.ethereum.org)
Blob fee (burned, non‑refundable even if the tx reverts): blobGasUsed × baseFeePerBlobGas, capped by maxFeePerBlobGas. Each blob contributes GAS_PER_BLOB = 2^17 blob gas. (eips.ethereum.org)

In code‑like terms (from EIP‑4844):

blob_fee = get_total_blob_gas(tx) * get_base_fee_per_blob_gas(header)
get_total_blob_gas(tx) = GAS_PER_BLOB * number_of_blobs
GAS_PER_BLOB = 2**17

The base fee per blob gas updates via a “fake exponential” function using excess_blob_gas, similar to EIP‑1559 dynamics (± about 12.5% pressure vs. target utilization). This is why “Excess Blob Gas” on Etherscan is an actionable leading indicator. (eips.ethereum.org)

Practical budgeting example:

Assume baseFeePerBlobGas = 1 gwei and your batcher posts 4 blobs/slot.
Cost per blob ≈ 131,072 blob gas × 1 gwei = 131,072 gwei = 0.000131072 ETH.
Four blobs ≈ 0.000524288 ETH per post (excluding EVM gas). If you post every slot (~12s), that’s ~0.00394 ETH/minute at 1 gwei base fee. Use your actual observed base fee from Etherscan. (eips.ethereum.org)

Two non‑obvious gotchas for CFOs and SREs:

You pay for the entire 128 KiB per blob even if you use less; pack batches tightly. (blocknative.com)
Blob fee is burned regardless of execution success; avoid strategies that risk post‑inclusion failure. (eips.ethereum.org)

What changed in 2025: Pectra doubled blob capacity and nudged DA off calldata

Ethereum’s May 7, 2025 Pectra upgrade implemented EIP‑7691, raising the blob target/max from 3/6 to 6/9 per block. That expanded daily blob DA capacity from ~5.5 GB to ~8.15 GB and eased pricing pressure when demand spikes. For many L2s, posting costs fell and stayed near the new target for long stretches. (eips.ethereum.org)

In parallel, EIP‑7623 increased the floor cost of calldata for data‑heavy transactions, bounding worst‑case block size variance and pushing DA workloads to blobs. Treat calldata as a surge relief valve, not your default. If your pipeline still relies on calldata for DA, model the new floor price and confirm your wallets/estimators have been updated. (eips.ethereum.org)

Observed market impact (aggregated research snapshots):

Post‑Pectra, research desks reported lower rollup DA costs and under‑target blob utilization in many epochs—consistent with base fee remaining low. Node bandwidth/storage pressure rose as more blobs remained in the 18‑day retention window, which you should plan for when operating validators. (galaxy.com)

How to use Etherscan blobs data in day‑to‑day operations

Price watching and posting windows

Bookmark View Blobs and watch “Excess Blob Gas” drift across consecutive blocks. When it’s trending down or flat near target, consider advancing your posting window; when trending up, compress more aggressively to reduce blobs/slot. Automate this with your own monitors if you need sub‑minute responsiveness. (etherscan.io)

Counterparty observability

Filter rows by labeled “Blob Sender” names like “Base: Batch Sender” or “Blast: Batch Sender” to understand competitor cadence, blob packing efficiency, and posting windows. This is a fast way to validate market behavior without running full analytics. (goto.etherscan.com)

Forensics and audits

Copy the “Blob Versioned Hash” into your archive to fetch payloads you store off‑protocol. Even after ~18 days, the KZG commitment lets you verify a payload’s integrity against canonical history. Etherscan’s info center clarifies that blob data is pruned on‑chain but provable off‑chain. (info.etherscan.com)

API planning

Etherscan’s API v2 doesn’t yet expose a first‑class “blob list” endpoint, but you can stitch together block data, transaction type (0x03), and on‑page blob counts for simple dashboards. Also note Etherscan’s recommendation to migrate to API v2 (V1 disabled after May 31, 2025). (etherscan.io)

Practical examples (copy these into runbooks)

Spot a low‑fee window:
- What to watch: Excess Blob Gas flat or decreasing for ≥10 blocks, baseFeePerBlobGas near minimum.
- Action: Increase batch size up to your latency SLO, targeting 5–6 blobs/tx to minimize per‑tx overhead. Confirm fullness; you still pay for the whole 128 KiB. (blocknative.com)
When the blob market spikes:
- What to watch: Excess Blob Gas climbing quickly and your estimated base fee crossing your internal ceiling.
- Action: Switch to “tight packing” mode: more aggressive compression, fewer L2 blocks per blob. Consider temporary fallback to calldata only if your total cost model (with EIP‑7623 floor) beats blob fee—rare after Pectra, but model it explicitly. (eips.ethereum.org)
SLA for data retention:
- What to watch: Internal archive coverage vs. on‑chain pruning timeline (~18 days).
- Action: Store blobs you care about (e.g., regulatory or settlement recon) in an off‑protocol archive keyed by versioned hash. Integrity verification derives from the commitment in L1 history. (eips.ethereum.org)

Emerging best practices we’re seeing work

Blob‑first posting policy with calldata as a pressure valve
- Codify a policy: “Post to blobs unless expected blob fee > X for Y consecutive slots.” Re‑evaluate X as capacity rises under new parameters. (eips.ethereum.org)
Tight packing to 128 KiB boundaries
- Structure batchers to fill blobs—don’t ship 80–90 KiB blobs when you can combine them. You pay the same. (blocknative.com)
Use EIP‑7623‑aware estimators and wallets
- Ensure gas estimation accounts for the calldata floor or transactions may underprice and fail. This hit several teams immediately after activation. (eips.ethereum.org)
Monitor blob supply signals, not just price
- Build a simple time series of excess_blob_gas and blobs_per_block. Price is a lagging signal; supply pressure shows up first in utilization and excess counters. Etherscan’s Blocks page is a quick human check. (info.etherscan.com)
Archive and attest
- Because blobs are pruned on‑chain, keep your own archive or rely on a third‑party service. Verification remains trust‑minimized via KZG. (info.etherscan.com)

What’s next: PeerDAS, BPO forks, and faster capacity increases

PeerDAS (EIP‑7594) landed in the 2025 “Fusaka” upgrade (mainnet activation scheduled for December 3, 2025). It introduces data availability sampling so nodes verify only portions of blob data, enabling higher blob throughput without centralizing hardware. Expect lower bandwidth pressure per node at higher blob counts than today. (eips.ethereum.org)
Blob Parameter Only hard forks (EIP‑7892) formalize “BPO” bumps—lean forks that change only blob target/max and update fraction—so Ethereum can scale blob capacity more frequently and safely as PeerDAS matures. Plan for more frequent capacity changes than the 2024‑2025 cadence. (eips.ethereum.org)
Post‑Pectra capacity: The community already doubled target/max to 6/9 via EIP‑7691; several proposals explore further increases in 2026 once PeerDAS data is stable. Watch for incremental bumps rather than giant leaps. (eips.ethereum.org)
Fee market tweaks: Proposals like EIP‑7762 (raise MIN_BASE_FEE_PER_BLOB_GAS) exist to improve price discovery; track them if your margins are tight. (eips.ethereum.org)

Bottom line: the medium‑term roadmap favors more blob supply, smoother price discovery, and a faster path to “dial up capacity” changes—good for L2 economics and end‑user fees. (eips.ethereum.org)

Deep‑dive: exact limits and retention (pin these for onboarding)

Size per blob: 128 KiB; structure is 4,096 × 32‑byte field elements over the BLS12‑381 scalar field. (eips.ethereum.org)
GAS_PER_BLOB: 2^17 blob gas. (eips.ethereum.org)
Retention: 4,096 epochs ≈ 18 days on consensus‑layer clients; pruned afterwards. KZG commitments remain in history forever. (eips.ethereum.org)
Pre‑Pectra capacity: target 3 / max 6 blobs per block; post‑Pectra: target 6 / max 9. (eips.ethereum.org)
Calldata repricing: EIP‑7623 increases the floor for data‑heavy tx to reduce worst‑case block size; rerun cost models if you still use calldata for DA. (eips.ethereum.org)

For decision‑makers: a quick ROI framework

Quantify DA demand

Measure your average compressed batch size per L2 block and how many L2 blocks you post per L1 slot. Translate that to blobs/slot with a 10–15% headroom buffer for spikes.

Model at two price points

Use a conservative blob base fee (e.g., 3–5 gwei) and a stress price (e.g., 10–20 gwei) to get a cost band. The formula is deterministic; pull actual base fees from Etherscan’s page when operating. (etherscan.io)

Decide your survivable latency

Lower fees usually mean larger batches and slightly higher latency to finality; set product SLOs first, then find the knee of the curve.

Architect for parameter changes

Treat blob capacity as dynamic. After PeerDAS and with BPO forks, expect more frequent target/max increases without sweeping changes elsewhere. Build levers in your batcher for the day the network moves from, say, 6/9 to a higher target. (eips.ethereum.org)

Implementation checklist (steal this)

Posting pipeline
- Defaults to blobs; packs to 128 KiB; retries respect baseFeePerBlobGas ceilings.
- Calldata fallback behind a circuit‑breaker that considers EIP‑7623 economics. (eips.ethereum.org)
Monitoring
- Alerts on excess_blob_gas and blobs_per_block trends, not just spot prices.
- Etherscan View Blobs bookmarked on NOC dashboards; labels tracked for counterparties. (etherscan.io)
Data retention
- Maintain an off‑protocol blob archive keyed by versioned hash with KZG verification on restore.
- Document the ~18‑day on‑chain retention SLA for compliance teams. (eips.ethereum.org)
Client/wallet updates
- Estimators/wallets tested against EIP‑7623’s calldata floor rules to avoid underpricing. (eips.ethereum.org)
Capacity planning
- Rehearse “parameter bump day” runbooks (e.g., target/max increases) to adjust batcher, analytics, and alerts within an hour of activation. (eips.ethereum.org)

Frequently asked operator questions

Can the EVM read blobs?
- No. Blobs are not accessible to EVM at execution; they’re verified via commitments and proofs. If your app needs on‑chain readable data, use calldata or storage. (info.etherscan.com)
How many blobs should I pack per transaction?
- Up to 6 pre‑Pectra and typically up to 9 post‑Pectra depending on your client/tooling; most batchers target 5–6 for efficiency. Always validate against current network parameters. (eips.ethereum.org)
Where do I see the “real” blob price?
- Etherscan’s “View Blobs” page shows current inclusions, including Excess Blob Gas and effective fees; for programmatic work, read block headers’ blob fields and compute the base fee per EIP‑4844. (etherscan.io)
What happens after 18 days?
- Consensus clients prune blob payloads; you (or a third party) should retain data if you need it. Integrity stays provable via the commitment stored on L1. (eips.ethereum.org)

The strategic takeaway

Post‑Pectra, blob capacity doubled (target 6, max 9), calldata got pricier for DA, and fee pressure eased. In December 2025, PeerDAS begins a shift to sampling that unlocks further capacity increases via smaller, focused BPO forks. Translate that into your own playbook: blob‑first, tightly packed batches, automated monitoring of excess_blob_gas, and an archive strategy keyed by versioned hash. If you treat Etherscan’s blobs pages as a real‑time DA market console—and design for parameters that can change more often—you’ll turn Ethereum’s evolving data layer into a predictable cost line instead of a rolling surprise. (eips.ethereum.org)

References and further reading

EIP‑4844 (proto‑danksharding) specification: transaction type, blob structure, gas math, and pruning parameters. (eips.ethereum.org)
Etherscan Information Center: “Blobs on Ethereum” overview; links to View Blobs and blob gas tracker. (info.etherscan.com)
Etherscan View Blobs (live mainnet page). (etherscan.io)
Pectra’s EIP‑7691 (blob throughput increase) and post‑upgrade analysis on capacity and costs. (eips.ethereum.org)
EIP‑7623 (calldata floor pricing) and migration notes for estimators/wallets. (eips.ethereum.org)
EIP‑7594 (PeerDAS) and Fusaka activation timeline. (eips.ethereum.org)
EIP‑7892 (Blob Parameter Only hard forks). (eips.ethereum.org)
Blocknative blob primer (packing matters; you pay for full blob). (blocknative.com)

If you want a worksheet to plug in your own batch sizes, cadence, and fee ceilings, reply and we’ll share our 7Block Labs blob pricing calculator template.