Preserve a work you can run again

Keep the program, edition inputs and an account of how the work behaves.

Preserve the materials needed to run the work, together with an account of how it should behave. This applies to personal collections and institutional archives.

An archive inventory

• Identity and provenance: chain, contract, global token ID, project, edition number, mint transaction hash, acquisition records and relevant transfer receipts.
• Artist and project records: title, credit, description, license, agreed presentation terms and instructions about behavior or acceptable display changes.
• Exact source: referenced code-post transaction, original content bytes, receipt/logs and extracted JavaScript. Keep the code-page identifier too.
• Edition inputs: mint receipt and event data used to recover its original mint hash and identifiers. Save project configuration with a date and block reference where available.
• Runtime and dependencies: tested viewer build, library versions, styling, fonts, images and other required assets. Record dependency URLs alongside preserved files.
• Playback record: operating system, browser, graphics hardware, viewport, clock conditions, interactions and reference captures explaining what they demonstrate.

Storage and metadata explains why calldata, logs, project state and preview images are distinct archival materials. An immutable deployed contract does not guarantee that future data providers will serve all historical transactions.

Download and verify

Keep the art bundle and, where useful, the whole-interface bundle. Save the matching hash file and acquisition date, then compare the downloaded bytes using the verification page.

A matching hash checks agreement with that published build. It does not replace provenance records or prove every external dependency is present. Downloads contain snapshots; ownership information can become historical.

Reconstruct from a fresh copy

Use a fresh browser profile without relying on an existing site's cache. Confirm identifiers and initial composition, then test significant behaviors: animation, text, controls, clock changes and exports where applicable.

For offline display, test separately with the network disconnected. Record what works and what requests external data. Keep missing dependencies visible in the record rather than calling an untested package self-contained.

Preserve identity and behavior

Reproducible inputs do not imply pixel-identical output on every browser or GPU. Font rasterization, shaders and device capabilities can affect rendering. Use artist instructions and the reference installation to identify meaningful differences.

Keep an untouched original when adapting a viewer or preparing an emulation. Document the reason, changes, runtime versions and comparison results in a separate working copy. Evolving work may need starting conditions and elapsed runtime; clock-dependent work may need its reference time.

The proposed on-chain archive is future work. You can begin this practical archive now; do not describe the proposed extension as an already-deployed service.