Live Generative Artwork vs Preview Image

A collection page may need to display dozens of tokens at once. Executing dozens of JavaScript simulations or WebGL scenes would consume memory, battery and network resources and could expose visitors to untrusted code. A static image is predictable, cacheable and easy to crop.

The focused artwork view has a different job. It can provide motion, sound, interaction, responsive layout and current blockchain state. Generative art often needs this live execution because its behavior—not one captured frame—is part of the work.

The two-layer pattern resembles a film poster and a film, or a score reproduction and a performance. The preview supports discovery; it should not silently replace the richer object it represents.

ERC-721 defines an optional tokenURI function and a small JSON schema containing name, description and image. The image value is a URI representing the asset. The standard does not define an executable-artwork field.

Marketplaces later adopted animation_url as a convention for rich media. OpenSea documents support for video, audio, 3D files and HTML pages using JavaScript, Canvas and WebGL. A wallet may support only image, another may play video, and another may execute HTML.

This is why “standards-native” should be phrased carefully. tokenURI is part of ERC-721; image is in its published schema; animation_url is a widely used ecosystem convention rather than an ERC-721 function.

A preview image records one appearance at one resolution and moment. It can be carefully selected, automatically rendered from the token seed or manually composed for presentation.

For a static generative print, that image may be the intended final artwork. For animated or interactive work, it cannot preserve timing, input, audio or response to ownership and block state. A still from a dynamic work is evidence of an appearance, not a complete behavioral record.

Preview provenance therefore matters. Collectors should know whether it was generated from the same seed and code, edited afterward or only loosely represents the project.

A live generative artwork executes rules at viewing time. A deterministic work can rebuild the same composition at any size. An animated work can progress through time. An interactive work can respond to a pointer, keyboard or sensor. A dynamic work can read current state.

Live does not mean unpredictable. The stable seed, traits and source code can remain fixed while the browser repeatedly performs them. Nor does “live” prove that the work is on-chain: an animation_url can point to an ordinary hosted webpage.

Trace the retrieval path separately from the behavior. Ask where the HTML, script, libraries, seed and required assets originate.

Metadata fields alone cannot settle an artistic question. Some artists define a high-resolution static render as the final piece and provide animation only as process documentation. Others treat an executable system as canonical and use image only as a thumbnail.

Project documentation should state which representation carries artistic authority, whether a particular viewport or duration matters and whether outputs may legitimately vary over time.

Without that statement, marketplaces tend to privilege whichever field they can render. Technical convenience can then become accidental curation.

A broken marketplace embed does not automatically mean the source artwork is gone. Open the original animation_url or reconstruct it through the documented contract path. Conversely, a working marketplace frame does not prove independent preservation if it is serving a cached copy of a discontinued host.

An image decoder has a relatively narrow job. An HTML artwork can execute JavaScript and make network requests. Marketplaces therefore isolate it in sandboxed frames and may restrict popups, storage, same-origin access or interaction with the parent page.

Data URLs receive unique opaque origins in modern browsers. This reduces access to surrounding website state, but collectors should still use a deliberate viewer or sandbox for unknown token code rather than running arbitrary HTML in a privileged application context.

Self-contained art also improves privacy. An animation that contacts an artist-controlled server can reveal a viewer’s IP address and viewing time even when token ownership is public.

If the live work is canonical, preserving only a screenshot removes behavior. If only the code survives, future conservators may not know how the artist expected it to look. Source, inputs and reference captures answer different questions.

Museums preserving software-based art use video documentation, screen captures and technical narratives alongside executable files. Generative collections benefit from the same approach: preserve the live recovery path, representative stills, recordings, intended viewport and artist statement.

A hosted preview can therefore remain culturally useful even when it is not required for reconstruction. The mistake is treating its availability guarantee as if it were the guarantee for the live work.

The 256ART artist template asks a finished sketch to expose its canvas through window.rendered. The platform uses that signal to capture token previews that galleries and marketplaces can load without executing every artwork.

For modern releases, the collection’s tokenURI can include that lightweight image URL while its animation_url contains the Base64 HTML returned by tokenHTML. The contract builds the live document from the token hash, traits, libraries and compressed artist script stored through on-chain contracts.

The hosted image may stop resolving if preview infrastructure disappears. That would degrade grids and marketplace thumbnails, but it would not remove the chain-built animation_url or tokenHTML recovery path. 256ART should label these roles consistently: preview image and live on-chain artwork.