Code, ownership and preservation

Code NFTs, historical data, metadata modes and verification.

The work is recreated from its program and edition inputs. Images and hosted metadata make that work convenient to browse; preserving the source and the inputs is what lets another viewer reconstruct it.

The code page is an NFT

Reserving an eligible unclaimed page on Immutables Code, currently Immutables.co, mints an ERC-721 page NFT to the reserving account. The page name maps to that token, and the page has its own royalty manager. Artists can hold their project's code-page NFT separately from the art editions they issue.

Code posts are immutable entries in the page's history. Posting another revision does not erase an earlier post, and posting content does not mint a separate NFT for every revision. Ownership of the page and copyright or reuse rights in its content are distinct; choose and state the license.

The possible future name code.immutables.art is a branding direction, not a change to these deployed contract addresses or token identities.

Where source and edition identity live

The code contract's anyonePostPageTagContent(page, tag, content) receives the text in transaction calldata and emits it in AddressPostedPageTagContent. It does not save the full text into a Solidity string mapping for arbitrary later contract reads.

The art project's scriptTransactionHash points to a particular code-post transaction. The current live client requests that transaction, decodes its three string arguments and extracts the fenced JavaScript. It then reads art mint events and provides each mint transaction hash plus project, edition and token IDs to the renderer.

The mint hash is recovered from chain history by the viewer; it is not a random seed variable stored by the mint contract. The project and token mappings remain separate from the historical transactions and logs needed for a full reconstruction.

Two metadata modes

The platform's useMetadataServer setting controls tokenURI:

• Hosted mode: return the configured base URI plus the global art token ID. This URL can serve pre-generated JSON from static object storage; it does not require a continuously running application server.
• Contract-generated mode: return a data:application/json;base64,... URI assembled by the contract. It includes project metadata and an image reference. If the project has an image base and extension, the image still points there; otherwise the contract supplies a basic SVG.

“Serverless metadata” describes how the JSON is produced, not a claim that every rich preview image or generative renderer is embedded in Solidity. Neither metadata mode executes the JavaScript artwork inside the EVM.

The metadata-mode switch is a platform owner setting. Artists can manage their own project's image base and extension through the artist/team function. Hosted JSON generation and marketplace caching may need a refresh after a change.

Current image hosting

This repository's services/metadata-art/ generates static metadata and uploads assets to R2. There is no Cloudflare Worker metadata server in this checkout. Image URLs are formed from a project base URL, the global token ID, and an extension such as .png or .gif—not the project's edition number.

Use the image generator and test the output against live rendering. For an endlessly evolving artwork, an animated thumbnail is a sample of its progression, not the complete work or a claim that its animation repeats.

Preserve more than a link

Historical transaction data must remain obtainable from some source. A deployed immutable contract does not guarantee that every future RPC provider will serve its full historical calldata and logs. Keep the exact posted bytes, transaction receipts/logs, edition inputs, renderer dependencies, styling and external assets. Preserve the chain/network and project identifiers alongside them.

The art download packages the available scripts and edition snapshot with a viewer. The whole-interface download packages the broader app. They reflect the build's snapshot, not future editions or transfers. Connected writes require a wallet and network; an offline copy is not a way to transact offline.

Use the verification page and hash file to check the exact downloaded bytes. A future on-chain archive extension is proposed work, not something the current mint method silently provides.

Source basis: code contract, art contract, BlockchainProvider.getProjectScript, and services/metadata-art/.