In this article5 sections
Ethereum’s data blobs carry a protocol guarantee of roughly 18 days of availability, but that window was never a deletion date, and the network’s first blob shows it. On October 27, 2026, the Blobscan archive still listed three storage locations for a blob first published on March 13, 2024, according to Cointribune.
That first blob was included in block 19,426,589. Although it measures 131,072 bytes, the report says only 8,745 bytes were actually used. The transaction itself remains visible on Etherscan as a type 3 entry, so its reference stays in the chain’s permanent history while its contents depend on whoever keeps a copy.
Also read: Ethereum staking hits record 43.8M ETH as yields fall to 2.63%
Key facts
- The retention window is 4,096 epochs, which works out to about 18.2 days under the protocol’s 32-slot, 12-second epochs.
- A blob holds 128 KiB of raw data, made of 4,096 elements of 32 bytes each.
- Since January 7, 2026, blocks have been able to carry up to 21 blobs, with a target of 14, up from 6 at launch.
- Blobscan’s archive was consulted on October 27, 2026 and showed the March 13, 2024 blob stored at Google, on the WeaveVM network and on IPFS.
A guarantee window, not a countdown to erasure
The rules originate in EIP-4844, which Dencun activated on March 13, 2024. Layer 2 networks such as Base and Arbitrum use blobs to publish the verification data behind the transactions they batch, moving that job away from calldata, which is stored on-chain indefinitely. Blobs are carried in type 3 transactions and live in the consensus layer; smart contracts can only see a versioned hash, a cryptographic fingerprint. They also price separately from ordinary gas, with a floor tied to execution fees since EIP-7918.
Ethereum’s own guidance frames the 18 days as an obligation: for 4,096 epochs (1,572,864 seconds), nodes must produce blobs, or their fragments since Fusaka, on request. The specification does not expect blobs to be stored as long as a block’s execution data. The ethereum.org material on ZK rollups states that longer-term access falls to archiving services, and the storage strategies page places transactions and hashes, calldata, and contract state alongside blobs as categories with different durability.
PeerDAS raised capacity, not duration
Fusaka went live on December 3, 2025 and brought PeerDAS, under which an ordinary node samples fragments to confirm availability instead of downloading every blob. Ethereum’s documentation says half the data is enough to rebuild all of it. That saving is what allowed the per-block ceiling to climb: the Ethereum Foundation’s Fusaka announcement set out two stages, from 9 to 15 blobs on December 9, 2025 and to 21 with a target of 14 on January 7, 2026. The retention window held at 4,096 epochs throughout.
Why it matters
Anyone treating blob data as permanently retrievable from the network is relying on something the protocol stopped promising. Rollups use blobs to keep data available while transactions are verified, not as an archive, so a fingerprint alone cannot reconstruct the payload if no independent party kept it. Calldata and contract state remain on-chain; blobs are the odd ones out.
What to watch
Whether the first blob, or others like it, stays visible on Blobscan and its listed archives over time is the clearest test of how much blob history survives outside the guaranteed window.
Reported by Cointribune.
Source: Cointribune