{ "slug": "blockchain-data-permanence-archives", "title": "“On the blockchain” does not mean someone will host it forever", "searchTitle": "Blockchain data permanence: blobs, history pruning and archives", "category": "Records and evidence", "accent": "#8fcfe8", "diagram": "retention", "summary": "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.", "why": "Cheaper blockchain data, rollups and tokenized records make retention an increasingly useful question. Readers need to distinguish verifiable records from an ongoing storage service.", "overlap": "Existing entries explain blobs and NFT metadata. This guide brings storage responsibilities together into a preservation workflow for someone who needs to retrieve and explain a record years later.", "related": [ "ethereum-blobs-data-availability", "nft-metadata", "bitcoin-merkle-proofs" ], "sections": [ { "id": "three-jobs", "heading": "Keeping, finding and checking are three different jobs", "sourceIds": [ "4844", "ipfs" ], "paragraphs": [ "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." ] }, { "id": "blobs", "heading": "Data available for validation is not a permanent archive", "sourceIds": [ "4844" ], "paragraphs": [ "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." ] }, { "id": "history", "heading": "Old transactions and old account state are different records", "sourceIds": [ "4444", "1186" ], "paragraphs": [ "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." ] }, { "id": "files", "heading": "A content address identifies a file; a pin keeps a copy", "sourceIds": [ "ipfs" ], "paragraphs": [ "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." ] }, { "id": "packet", "heading": "Build a record that another person can understand", "sourceIds": [ "4844", "4444", "1186", "ipfs" ], "paragraphs": [ "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." ] } ], "example": { "title": "The artwork survives; the caption does not", "paragraphs": [ "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." ] }, "table": { "headers": [ "Record", "What to retain", "What to check" ], "rows": [ [ "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?" ] ] }, "checklist": [ "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." ], "figure": { "title": "A lasting reference needs an available record", "caption": "The three lanes describe different responsibilities. Their lengths are illustrative, not network retention periods.", "description": "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." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "b8e383c136d52c3235dae4531a864f9fce61a104ba7163c2b62d3036253e44cf", "status": "verified by separate automated source review", "sources": [ { "id": "4844", "title": "EIP-4844: Shard Blob Transactions", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4844", "locator": "Parameters; Consensus layer validation; Rationale", "scope": "Blob data and commitments have distinct roles; the original retention parameter is not a current universal service guarantee.", "retrieval": { "id": "4844", "url": "https://eips.ethereum.org/EIPS/eip-4844", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4844", "retrievedAt": "2026-10-02T21:37:36.402734+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4844.source", "sha256": "d1c1eb7c505919bb326f493d163b9200b72ed0de2416deae37db6d75cc07baa5", "text": "evidence/4844.txt", "textSha256": "704761f20e60f51683ba82d8fd2c4694f63ea115a6dc6283cf91e49c56c12e26" } }, { "id": "ipfs", "title": "Pin files", "publisher": "IPFS Docs", "url": "https://docs.ipfs.tech/how-to/pin-files/", "locator": "Pin files using IPFS; Three kinds of pins; Local versus remote pinning", "scope": "Content addressing and responsibility for retaining copies; does not promise perpetual hosting.", "retrieval": { "id": "ipfs", "url": "https://docs.ipfs.tech/how-to/pin-files/", "finalUrl": "https://docs.ipfs.tech/how-to/pin-files/", "retrievedAt": "2026-10-02T21:37:36.595200+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/ipfs.source", "sha256": "3fd4a0313f1c5af3309da80188b6ea14f3ea178d73f769a35b97d72d06690b76", "text": "evidence/ipfs.txt", "textSha256": "e68c1c058990fcefee60c4550496eff91462d68e23ce77efce5832f2e4832f1c" } }, { "id": "4444", "title": "EIP-4444: Bound Historical Data in Execution Clients", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4444", "locator": "Specification; Rationale; History availability", "scope": "A proposal about old execution history, not evidence that every client has implemented it.", "retrieval": { "id": "4444", "url": "https://eips.ethereum.org/EIPS/eip-4444", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4444", "retrievedAt": "2026-10-02T21:37:36.541546+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4444.source", "sha256": "0fa0db4982dbcc447e0bcc49cb6ff80a97b70e5417bb9bc902351431cb4a5c90", "text": "evidence/4444.txt", "textSha256": "a60d11ccca7507a0450f3a20359e1b01b290c46de9269341e7a6d36a3babbeb4" } }, { "id": "1186", "title": "EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-1186", "locator": "Abstract; eth_getProof; Returns", "scope": "Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.", "retrieval": { "id": "1186", "url": "https://eips.ethereum.org/EIPS/eip-1186", "finalUrl": "https://eips.ethereum.org/EIPS/eip-1186", "retrievedAt": "2026-10-02T21:37:36.700685+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/1186.source", "sha256": "bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e", "text": "evidence/1186.txt", "textSha256": "6e76e5fbc153157fdd8a38dd4a3e5c2c2b633f0cd0e52c35c3b5da780cfb53b2" } } ], "canonical": "https://degreesofsatoshi.com/guides/blockchain-data-permanence-archives/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "b8e383c136d52c3235dae4531a864f9fce61a104ba7163c2b62d3036253e44cf" } }