{"id":"EIP-4844","name":"Shard Blob Transactions","status":"Final","chain":"ethereum","category":{"id":"infrastructure","name":"Infrastructure","description":"Foundational patterns enabling other standards"},"journeyStages":[{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"}],"uxImpact":"EIP-4844 introduced Type 3 blob transactions so rollups can post data using a separate blob-fee market. This can lower data costs, but the end-user fee depends on the rollup, execution costs, demand and its pricing policy. Show a current network-specific estimate rather than a fixed dollar price or savings guarantee.","officialUrl":"https://eips.ethereum.org/EIPS/eip-4844","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-4844","summary":"EIP-4844 introduced Type 3 blob transactions so rollups can post data using a separate blob-fee market. This can lower data costs, but the end-user fee depends on the rollup, execution costs, demand and its pricing policy. Show a current network-specific estimate rather than a fixed dollar price or savings guarantee.","applicability":{"whenToUse":["A supported rollup uses blob data and exposes a current total fee estimate.","Users benefit from understanding data-cost changes or temporary data availability."],"whenToAvoid":["You need a guaranteed price or fixed percentage saving.","The application relies on blobs as permanent archival storage."]},"designerTakeaways":["Show current total fee estimates for the selected rollup.","Explain that blob data and execution fees have different components.","Offer small transactions only when the current fee makes them practical."],"problemsSolved":[{"problem":"Rollup data competed entirely for calldata gas","oldWay":"Publish all batch data through ordinary calldata pricing","newWay":"Supporting rollups can use the separate demand-sensitive blob fee market","impact":"high"},{"problem":"Users cannot judge the cost of a small action","oldWay":"Promise a fixed sub-penny fee based on protocol support","newWay":"Show the current total fee and whether it is reasonable relative to the amount","impact":"high"}],"uxPatterns":[{"name":"Current L2 fee estimate","description":"Quote the selected network and actual transaction.","userFlow":["User initiates an action on a supported rollup","Fetch the current total fee estimate and any available component breakdown","Label the network, estimate time and possible changes","User reviews the cost and confirms","Show the actual fee after execution"]},{"name":"Network Comparison","description":"Help users choose network based on cost","userFlow":["User wants to mint/trade/interact","App shows available networks","Clear fee comparison displayed","Recommendation based on cost vs security tradeoffs","User selects cheapest suitable option"]},{"name":"Blob Fee Tracker","description":"Show current blob fee market status","userFlow":["User views fee dashboard","Sees L1 gas and blob gas separately","Understands blob utilization affects L2 costs","Use current total rollup estimates when choosing when to transact; a lower blob price alone does not guarantee a lower user fee."]},{"name":"Micro-Transaction UI","description":"Design for viable small transactions","userFlow":["User chooses a small payment","Estimate its current total cost on the selected network","Explain when the fee is large relative to the payment","Let the user revise the amount, wait or cancel","Show the actual outcome and fee"]}],"uiComponents":[{"name":"L2FeeDisplay","description":"Show L2 transaction fee with L1 comparison","states":["loading","cheap","moderate","expensive"],"props":["fee","feeUsd","l1Comparison","savings"]},{"name":"NetworkSelector","description":"Choose network with fee comparison","states":["loading","ready","selected"],"props":["networks[]","fees[]","recommended","onSelect"]},{"name":"BlobStatusIndicator","description":"Show blob space utilization","states":["low","moderate","high","full"],"props":["utilization","blobGas","trend"]},{"name":"MicroTxAmount","description":"Amount selector for small transactions","states":["selecting","selected","custom"],"props":["presets[]","minViable","fee","onSelect"]},{"name":"SavingsBadge","description":"Highlight fee savings vs L1","states":["minimal","good","great","amazing"],"props":["percentSaved","amountSaved","comparison"]}],"antiPatterns":[{"pattern":"Promising a fixed dollar fee or percentage saving","why":"Blob demand, execution costs and rollup policies vary","instead":"Use a current network-specific estimate and label comparisons with their time and assumptions","severity":"high"},{"pattern":"Hiding the selected network","why":"Fee and settlement expectations depend on the network","instead":"Keep the network visible through review and confirmation","severity":"high"},{"pattern":"Treating blobs as permanent storage","why":"Protocol data availability is time-limited","instead":"Use an archival strategy when the product needs long-term retrieval","severity":"high"}],"keyTakeaways":["Blob data uses a separate, demand-sensitive fee market.","Rollup user fees include more than the blob-data charge.","Use current estimates; historical savings are not a promise.","Blob data availability is temporary, so plan archival separately."],"technicalNotes":"EIP-4844 introduces Type 3 blob transactions with 128 KiB blobs and a separate self-adjusting blob base fee. End-user rollup charges also depend on execution, settlement, compression, network demand and rollup policy. Original target and maximum blob counts were changed by later upgrades; use the active network parameters. The protocol provides temporary blob-data availability, roughly 18 days under the original retention window, not permanent storage.","lastUpdated":"2026-09-18","lastReviewed":"2026-09-18","specConstraints":[{"id":"blob-api-not-permanent","constraint":"Blob data is not accessible from the web3 API in the same way as execution-payload data.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"### Blob non-accessibility\n\nThis EIP introduces a transaction type that has a distinct mempool version and execution-payload version,\nwith only one-way convertibility between the two. The blobs are in the network representation and not in the consensus representation;\ninstead, they are coupled with the beacon block. This means that there is now a part of a transaction that will not be accessible from the web3 API.","specSection":"Backwards Compatibility — Blob non-accessibility","specUrl":"https://eips.ethereum.org/EIPS/eip-4844#blob-non-accessibility","designImplication":"Do not use the blob transaction as the only long-term source for user-visible records. Provide an archival or retrieval path when the product needs durable data."},{"id":"blob-mempool-throttle","constraint":"Nodes announce blob transactions without automatically broadcasting the full transactions, allowing receiving nodes to throttle intake.","appliesTo":"infrastructure","normativity":"backwards-compatibility","specQuote":"### Mempool issues\n\nBlob transactions have a large data size at the mempool layer, which poses a mempool DoS risk,\nthough not an unprecedented one as this also applies to transactions with large amounts of calldata.\n\nBy only broadcasting announcements for blob transactions, receiving nodes will have control over which and how many transactions to receive,\nallowing them to throttle throughput to an acceptable level.\n[EIP-5793](./eip-5793.md) will give further fine-grained control to nodes by extending the `NewPooledTransactionHashes` announcement messages to include the transaction type and size.\n\nIn addition, we recommend including a 1.1x base fee per blob gas bump requirement to the mempool transaction replacement rules.","specSection":"Backwards Compatibility — Mempool issues","specUrl":"https://eips.ethereum.org/EIPS/eip-4844#mempool-issues","designImplication":"Model blob submission as a pending or unavailable propagation state when the node has not received full blob data. Do not promise a universal pending feed."},{"id":"blob-data-retention","constraint":"Blob sidecars are kept for a bounded period, around 18 days under the specified retention parameter, rather than as permanent execution history.","appliesTo":"application","normativity":"security-considerations","specQuote":"there is no expectation that the blobs need to be stored for as long as an execution payload.","specSection":"Security Considerations","specUrl":"https://eips.ethereum.org/EIPS/eip-4844#security-considerations","designImplication":"Label blob availability as temporary and plan separate archival storage for any data users must retrieve later."}],"sources":[{"label":"EIP-4844 official specification","url":"https://eips.ethereum.org/EIPS/eip-4844","type":"official-spec"}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-4844","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-4844","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-4844","markdown":"https://www.eipsfordesigners.com/standards/EIP-4844/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-4844/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-4844","official":"https://eips.ethereum.org/EIPS/eip-4844","discussion":"https://ethereum-magicians.org/search?q=EIP-4844"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}