The Clock Starts the Moment Your Rollup Posts a Blob
You submit a transaction on a Layer 2. Somewhere upstream, a sequencer bundles it with a few thousand others, compresses the batch, and posts it to Ethereum as a blob. The data is live. Nodes can see it, fraud provers can read it, anyone with a client can reconstruct the rollup state from it.
For now.
Approximately 18 days later, every full node on Ethereum is expected to delete it.
That single design decision, introduced with EIP-4844 and its blob-carrying transaction type, is one of the most consequential and least-discussed architectural choices in the current rollup ecosystem. It cuts fees dramatically. It also encodes a set of assumptions about timing, liveness, and who actually holds the data afterward that rollup designers, bridge operators, and users are all implicitly betting on, and most of them couldn't tell you the terms of the bet.
What Blobs Are and Why They Disappear
Before EIP-4844, rollups posted transaction data as Ethereum calldata. Permanent, expensive, stored on every full node forever. Blob data works differently.
A blob is a large chunk of raw bytes, up to 128 KB per blob with a cap of six blobs per block at launch, that travels alongside a transaction but sits outside the EVM's execution environment. Contracts can't read blob contents directly; they can only verify a cryptographic commitment to the blob. Think of it like a shipping manifest that proves a container exists without requiring every port inspector to carry the container home. The actual bytes are gossipped across the consensus layer's peer-to-peer network, made available to anyone who wants them during the retention window, and then pruned.
The target retention period is 4,096 epochs, roughly 18.2 days at Ethereum's 12-second slot time. This is not a hard protocol rule enforced by slashing. It is a social and client-level agreement. Nodes that keep blobs longer aren't punished. Nodes that delete them on schedule aren't rewarded. The policy is a default, not a constraint, and that distinction matters more than most commentary acknowledges.
The rationale is honest. Storing every blob forever would balloon node storage requirements by hundreds of gigabytes per year at scale, killing the accessible-node count and quietly centralizing validation. The tradeoff is intentional.
The 18-Day Window Is a Security Parameter, Not Just a Storage Detail
Different rollup designs interact with blob pruning in very different ways, and the differences map directly onto security models.
Optimistic rollups like Optimism and Arbitrum rely on fraud proofs. If a sequencer posts a fraudulent state root, a watcher must reconstruct the underlying transaction data, identify the bad state transition, and submit a fraud proof on-chain within the challenge window. Challenge windows on major optimistic rollups currently sit at seven days. Seven days fits inside the 18-day blob retention window. A fraud prover who comes online at any point during the challenge period can still fetch the relevant blob data from the consensus layer network.
Now consider what happens if challenge windows were ever extended past 18 days. Or consider the less obvious scenario: a blob is posted on day one, a fraud prover is offline or censored for 19 days, and by the time they attempt to reconstruct the disputed state, the blob is gone from the canonical peer-to-peer layer. The fraud proof cannot be built from Ethereum's own infrastructure. The prover must find the data somewhere else.
That somewhere else is the crux of the matter.
ZK rollups like zkSync Era and Starknet have different exposure. They don't need fraud proofs; validity proofs are verified on-chain at posting time. But users and bridges still need to reconstruct historical state for exits, forced transactions, and data audits. If that reconstruction depends on blob data that no longer exists on Ethereum's peer-to-peer layer, it depends entirely on whoever archived it.
Who Actually Keeps the Data
Call them Priya and Marcus. Both ran Ethereum full nodes when EIP-4844 went live. Priya configured her node with the default settings, which prune blobs after the retention window. Marcus, running infrastructure for a rollup bridge operator, patched his client to retain blobs indefinitely and fed them into a separate archival database.
Three months after a particular rollup batch was posted, a user tries to construct a Merkle proof of their old balance for a bridge exit. Priya's node cannot help. The blob is gone. Marcus's node serves the data. So can any other archival service that kept it: Etherscan's blob explorer, EigenDA, Celestia, blobscan.io, or the rollup's own data availability layer.
The point is not that the data disappears in practice. Multiple parties have strong incentives to archive blobs: block explorers, rollup teams, data availability committees, third-party services. The point is that Ethereum's base layer is no longer the authoritative source after 18 days. The security guarantee shifts from "anyone running a standard Ethereum node can verify this" to "anyone who trusts at least one of these archival parties can verify this."
For most users in most situations, that is a perfectly acceptable shift. For a bridge holding nine figures in locked assets, the precise identity and trust model of those archival parties deserves serious scrutiny.
The Deeper Assumption About Liveness
Optimistic rollup security has always depended on at least one honest watcher being online and willing to submit fraud proofs. Blob pruning adds a second liveness assumption layered on top of the first: at least one honest party must have retained the blob data long enough for any fraud proof to be constructable.
These two assumptions compound. It is not enough that a fraud prover is online. They need the data too. If the rollup's own data availability committee, typically a small set of countersigning entities, goes offline or is compromised simultaneously with a fraudulent sequencer, and the blob retention window has already closed, the fraud proof window may close without anyone being able to prove fraud.
Genuinely unlikely. It requires coordinated failure across multiple parties within a specific timeframe. But "unlikely" and "impossible" are different things in security design, and the honest answer is that EIP-4844 moved Ethereum rollups from a stronger data availability guarantee (permanent calldata) to a weaker one (temporary blob availability plus archival trust) in exchange for dramatically lower costs.
The Ethereum research community knows this. Proposals like full Danksharding and PBS-adjacent data availability sampling aim to make blob data verifiably available to a much larger set of light clients during the retention window, hardening the liveness assumption without requiring permanent storage. Those are future mechanisms. Current blob transactions rely on the simpler model.
What Rollup Designers Are Actually Betting On
When a rollup team chooses blob transactions over calldata, they are making a set of implicit bets.
First, that their challenge window, for optimistic systems, fits inside the retention window with enough margin that liveness failures don't compound with data unavailability. Second, that at least one trustworthy archival source will maintain blob data indefinitely, and that their bridge and exit mechanisms have a credible path to that source. Third, that the social and economic incentives around blob archival stay strong enough that the data doesn't effectively vanish in any realistic adversarial scenario.
Those are probably good bets. The ecosystem around blob archival is maturing. But the rollup projects I find most credible are the ones that document their archival strategy explicitly, name the parties holding the data, and specify what happens to exit proofs after the retention window closes. The ones that say nothing about it are not necessarily reckless. They are just asking you to trust a pipe they haven't shown you.
The honest framing is that blob transactions represent a deliberate trade: Ethereum stops guaranteeing data availability after 18 days in exchange for making the system cheap enough that rollups can actually post data at scale. The rollup ecosystem then builds its own archival and availability infrastructure on top. That infrastructure is real, and it works.
It's just not Ethereum.
If your rollup's data availability documentation mentions blobs and says nothing about archival strategy, you've found the question worth asking.