Metadata
Token metadata is an ERC-721 style JSON document served from /api/collections/[slug]/tokens/[token]. Its contents are what make a token here keep working after every hosted-image NFT around it has quietly gone dark.
The document
{
"name": "Spectra #7",
"description": "Beams of dispersed light crossing a dark field.",
"external_url": "https://pons.example/collections/spectra",
"image": "https://pons.example/api/render/spectra/7?w=1024&h=1024",
"animation_url": "https://pons.example/t/spectra/7",
"attributes": [
{ "trait_type": "beams", "value": 4.31 },
{ "trait_type": "angle", "value": 1.257 },
{ "trait_type": "dispersion", "value": 0.86 },
{ "trait_type": "speed", "value": 0.42 },
{ "trait_type": "seed", "value": "d41c8e2a91f07b33" }
],
"properties": {
"generator": "pons/v2",
"chain": "Robinhood Chain",
"network": "mainnet",
"chain_id": 4663,
"on_chain": true,
"seed": "d41c8e2a91f07b33...",
"shader_sha256": "9f2ab6...",
"shader_wgsl": "struct Params { ... }",
"params": { "beams": 4.31, "angle": 1.257 },
"tx_hash": "0x..."
}
}image vs animation_url
image points at a server-rendered PNG, generated on request at /api/render/[slug]/[token] and cached immutably: since a seed always renders the same frame, that PNG never needs to change. It's what marketplaces, social cards, and non-WebGPU browsers show.
animation_url points at the live token page, /t/[slug]/[token], which recompiles the shader and renders it in the viewer's own browser. That's the real artwork: moving, rendered fresh, at whatever resolution the viewport happens to be.
attributes are the shader's own params
Every seeded parameter becomes one trait: its WGSL field name as trait_type, its derived value as value. There is no separate concept of "traits" layered on top, the parameters that shaped the artwork are the traits, which is also what makes rarity on pons collections meaningful: filtering by a trait is filtering by an actual input to the shader. A truncated seed trait rides along for reference.
properties: the rest of the record
| field | what it is |
|---|---|
| generator | fixed string, "pons/v2" |
| chain, network, chain_id | Robinhood Chain, mainnet, 4663 |
| on_chain | true when tx_hash is a real transaction, false for an off-chain allocation |
| seed | the full 64-char seed hash |
| shader_sha256 | hash of the shader source, so an edited shader is provably a different artifact |
| shader_wgsl | the complete shader source, embedded directly in the metadata |
| params | the same key/value pairs as the attributes, as an object |
| tx_hash | the mint transaction, or an off-chain allocation id |
Why metadata stays alive
A hosted-image NFT has exactly one point of failure: whoever is serving that JPEG. A Pons Shader Launchpad token carries its own recipe. Because shader_wgsl and every parameter value live directly in the metadata, any device with WebGPU can rebuild the artwork from the metadata document alone, without ever calling back to pons, indefinitely.
On-chain, tokenURI(tokenId) points at baseURI + tokenId, set once at deploy time. That route, /api/metadata/[tokenId], reads the contract to resolve the global token id into a collection and token number, then redirects to the canonical document above.