Artifacts

ERC metadata gives special meaning to image and a handful of common keys. An ABX token may anchor more: source files, print exports, models, datasets, stems, or derived renders.

Each artifact has three fields:

key -> { mimeType, uri }

• key is a creator field such as image, or a derived name such as render/image.
• mimeType comes from the source. It is not guessed from the bytes.
• uri may use data:, ipfs://, ar://, or https://.

The served token JSON lists artifacts beside standard metadata:

{
  "name": "Work 0",
  "image": "ipfs://...",
  "artifacts": [
    {"key": "image", "mimeType": "image/png", "uri": "ipfs://..."},
    {"key": "render/model", "mimeType": "model/gltf-binary", "uri": "ar://..."}
  ]
}

Consumers that do not know artifacts ignore it. Others get the full list without a second endpoint.

Every entry includes provenance. A value may be merely labeled, anchored by a hash or content address, or reproducible from public code and onchain inputs. See Metadata and Effects.

The artifact list is a resolver projection. Its entries may point to onchain bytes or offchain effect output. Use abx tokenuri for the onchain commitment and the artifact list for served locations.

Reading it directly

abx artifacts <address> --token <id> reads this list on its own, without fetching the whole served document, and adds what the served document deliberately omits: every registered effect output, current and stale, each labeled against the token's active inputsHash (see Effects → Checking currency directly). --remote <name|url> reads the hosted resolver instead of this node's local projection.