# “On the blockchain” does not mean someone will host it forever

A blockchain can help you check whether data matches a committed record. It does not follow that every node will keep every byte, or that a linked image will remain available. Long-term access needs people or services that retain the underlying data.

AI-authored for Degrees of Satoshi · Source scope 2026-10-02

Canonical: https://degreesofsatoshi.com/guides/blockchain-data-permanence-archives/
Published: 2026-10-02
Automated source review: 2026-10-02T22:35:07.201Z. No human or expert review is claimed.

## Visual explanation: A lasting reference needs an available record

Separate lanes show a chain commitment, underlying data and an archive copy. The data-serving window ends while the commitment remains; a retained archive copy supplies later retrieval.

The three lanes describe different responsibilities. Their lengths are illustrative, not network retention periods.

## Keeping, finding and checking are three different jobs

Imagine a receipt stored in a file, with a cryptographic commitment recorded elsewhere. A commitment binds to particular data so that a suitable check can detect a mismatch. It is not a compressed backup from which the original file can be recovered.

Three jobs have to succeed. Someone must retain the bytes. You need a way to find and retrieve them. Then you need enough information to verify what they are. A system can be strong at verification and weak at retrieval.

This helps explain a common frustration: an identifier still exists, but the page or file behind it does not load. The identifier has not necessarily become invalid. The service that supplied the content may have stopped retaining it or stopped serving your request.

Sources: [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844); [Pin files](https://docs.ipfs.tech/how-to/pin-files/)

## Data available for validation is not a permanent archive

Ethereum can carry batches of data for other systems to read and check. Those batches are called blobs. They are especially useful to rollups: systems that process transactions outside Ethereum’s main execution environment while relying on Ethereum for parts of their data and settlement design. Blob data travels separately from ordinary transaction data, and commitments connect it to the chain.

The EIP-4844 design specifies a bounded period during which the separate blob data must be served. That means “the network made this data available” and “I can ask any node for it years later” are different statements. A rollup or archive service may retain copies beyond the required window.

Avoid treating an old retention number in an article as a permanent guarantee. Network rules, client versions and service policies can change. For a real preservation task, record the applicable rule and the archive’s stated coverage on the day you check.

Sources: [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844)

## Old transactions and old account state are different records

History pruning concerns whether a node retains or serves older records such as block bodies and receipts. EIP-4444 discusses bounding execution history and obtaining older data through other distribution paths. The retrieved document is a draft proposal; it does not establish what every live client currently stores.

Historical state is another requirement. An old transaction can tell you that an action was recorded, while a question such as “what was this account’s balance at that block?” needs suitable historical state data or a saved proof for that state. A provider that supplies one kind of history may not supply the other.

When requesting an archive service, describe the actual query you need. “Full history” is too vague to establish whether it includes receipts, historical balances, contract storage, blob data or application files.

Sources: [EIP-4444: Bound Historical Data in Execution Clients](https://eips.ethereum.org/EIPS/eip-4444); [EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof](https://eips.ethereum.org/EIPS/eip-1186)

## A content address identifies a file; a pin keeps a copy

IPFS retrieves content using identifiers tied to content rather than relying only on a familiar web location. That is useful for checking that you received the intended object. Someone still needs to make the object available.

Pinning tells an IPFS node to retain content instead of removing it during routine storage cleanup. A remote pinning service performs that storage job for you under its own operating arrangements. Neither a content identifier nor an unpaid, unmonitored promise of pinning establishes perpetual availability.

For material you need to preserve, retain a copy you control and test retrieval from the other copies you depend on. Include associated files: the descriptive file linked to a non-fungible token (NFT) might point to an image stored elsewhere. That descriptive file is called metadata. Preserving only one may leave the other missing.

Sources: [Pin files](https://docs.ipfs.tech/how-to/pin-files/)

## Build a record that another person can understand

A useful preservation packet contains the original data, its identifier or checksum—a fingerprint computed from the data—the relevant network and block references, and a plain-language description of what it establishes. Include retrieval time and source, so a later reader can distinguish a historical observation from a current one.

If the claim relies on a cryptographic proof, keep the proof and the trusted reference it is checked against. A hash by itself establishes much less than a complete verification procedure. If the claim relies on an invoice or an agreement outside the chain, preserve that context too, with access limited to the people who need it.

Then rehearse retrieval on another device. Can you open the file, identify the network and reproduce the check? This is a more useful preservation test than seeing a green availability badge once. Keep sensitive material private; publishing a preservation packet is a separate decision from keeping one.

Sources: [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844); [EIP-4444: Bound Historical Data in Execution Clients](https://eips.ethereum.org/EIPS/eip-4444); [EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof](https://eips.ethereum.org/EIPS/eip-1186); [Pin files](https://docs.ipfs.tech/how-to/pin-files/)

## Worked example (fictional): The artwork survives; the caption does not

A fictional collector saves an artwork file but only bookmarks the token’s metadata page. Two years later the bookmarked service is unavailable. The collector still has the image, but cannot recover the exact description that was displayed when it was acquired.

A fuller packet would have included the image, metadata bytes, relevant content identifiers, token contract and token ID, network, and dated transaction references. Even then, the packet would preserve evidence of the recorded material, not automatically prove copyright ownership.

The lesson is to list each dependent object before choosing storage. A single visible page can depend on several separately hosted files.

## Comparison

| Record | What to retain | What to check |
| --- | --- | --- |
| Blob-backed application data | The data and its verification context | Which archive has the required period? |
| Historical account claim | Block reference and suitable state proof or data | Can the proof be checked against a trusted root? |
| IPFS-linked media | Content and dependent objects | Are independent copies still retrievable? |
| Business meaning | Invoice, agreement or explanatory note | What does the chain record actually establish? |

## What to check

- List the bytes you need, including linked files and supporting records.
- Separate transaction history, historical state and application media.
- Keep copies under your control and record their checksums and provenance.
- Periodically test retrieval and verification, not only account billing.

## Why this may matter for years

Cheaper blockchain data, rollups and tokenized records make retention an increasingly useful question. Readers need to distinguish verifiable records from an ongoing storage service.

Editorial judgment, not a traffic or adoption forecast.

## Evidence and scope

- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844). Parameters; Consensus layer validation; Rationale. Blob data and commitments have distinct roles; the original retention parameter is not a current universal service guarantee. Retrieved 2026-10-02T21:37:36.402734+00:00; SHA-256 d1c1eb7c505919bb326f493d163b9200b72ed0de2416deae37db6d75cc07baa5.
- [Pin files](https://docs.ipfs.tech/how-to/pin-files/). Pin files using IPFS; Three kinds of pins; Local versus remote pinning. Content addressing and responsibility for retaining copies; does not promise perpetual hosting. Retrieved 2026-10-02T21:37:36.595200+00:00; SHA-256 3fd4a0313f1c5af3309da80188b6ea14f3ea178d73f769a35b97d72d06690b76.
- [EIP-4444: Bound Historical Data in Execution Clients](https://eips.ethereum.org/EIPS/eip-4444). Specification; Rationale; History availability. A proposal about old execution history, not evidence that every client has implemented it. Retrieved 2026-10-02T21:37:36.541546+00:00; SHA-256 0fa0db4982dbcc447e0bcc49cb6ff80a97b70e5417bb9bc902351431cb4a5c90.
- [EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof](https://eips.ethereum.org/EIPS/eip-1186). Abstract; eth_getProof; Returns. Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client. Retrieved 2026-10-02T21:37:36.700685+00:00; SHA-256 bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e.

## Continue learning

- [Ethereum blobs and data availability](https://degreesofsatoshi.com/encyclopedia/ethereum-blobs-data-availability/)
- [NFT metadata: where the name, image and attributes live](https://degreesofsatoshi.com/encyclopedia/nft-metadata/)
- [Bitcoin Merkle proofs: proving inclusion without the full block](https://degreesofsatoshi.com/encyclopedia/bitcoin-merkle-proofs/)