How 256ART Reconstructs Live Artwork Entirely From Chain

Each minted token has a stored 32-byte hash. tokenHTML places that hash and the token ID into the inputData object before the artist’s script runs.

The same hash drives deterministic decisions. Unlike a request to a private generator API, the relationship between token and seed is available from the collection contract. This fixed identity can be combined with state that intentionally changes later.

For each trait index i, the implementation hashes uint256(seed) + i with keccak256 and reduces the result modulo 10,000. It compares that number with the trait’s cumulative weights and selects the first matching value and description.

Those selected values are inserted into inputData and into the tokenURI attributes. The live script and marketplace metadata therefore originate from the same contract-side trait definitions.

tokenHTML also provides ownerOfPiece, the previous block hash, block number, timestamp, base fee, block fee recipient, prevrandao, total supply, the owner’s token balance and the owner’s native-token balance in wei.

An artist can ignore these values or make them part of the work. Because they are read when the document is assembled, a dynamic artwork can respond to current state without receiving a payload from 256ART.

This also means two tokenHTML calls at different blocks need not return byte-identical HTML. The seed and derived traits remain fixed, while owner and block fields reflect the selected read context. An archive-capable RPC can execute eth_call against an earlier block when historical reconstruction is required.

The generated document defines a small loader named ls256. It Base64-decodes a compressed file, passes it through the browser’s gzip DecompressionStream and appends the resulting JavaScript as a script element.

An async orchestration function awaits each ls256 call for the listed libraries, then awaits one final call for the concatenated artist script. This preserves dependency order while keeping the stored data compressed until the browser needs it.

DecompressionStream is a web-platform API standardized for gzip and broadly available across current browser engines. It is still a runtime dependency: an older browser without the API cannot execute this exact loader, even though a separate gzip implementation could recover the same stored bytes.

The contract concatenates the input script, viewport rules, canvas layout and loader into HTML. It Base64-encodes that HTML and returns a data:text/html URI.

No HTTP content URL is required to execute the live work. The browser receives the document from an RPC call or explorer and operates on the bytes returned by the contract. A different RPC reading the same chain state can reproduce the response.

Modern browsers treat data URLs as opaque origins, and marketplaces commonly place token HTML inside sandboxed frames. This isolation can limit storage and cross-origin behavior. As with any third-party HTML, collectors should execute unknown artwork code in an isolated context.

The source material and assembly response come from blockchain contracts. Execution happens in a browser because JavaScript generative art is designed for a browser runtime; the EVM is not drawing pixels.

This is different from an off-chain rendering service. The browser is an interpreter under the collector’s control, while a rendering service is an external source of token-specific data or media. Browser compatibility remains a software-conservation concern, but loss of the 256ART frontend does not remove the source package.