Trait Generator: URL State to Mint Metadata (Trait Generator Url State To Mint Metadata)

If trait choice vanishes, mint cannot be reproduced

The Bare Crypto generator app writes avatar pieces (skin, hair, accessories, …) into the address bar via react-url-query. Randomize, download, and share all flow through that URL state. Downloaded PNG/SVG plus the selected option set are the raw material for collection mint metadata attributes — the generator is not a toy; it is the visual vocabulary of the mint funnel.

Trait options (avatars OptionContext)
        ↓ sync
  URL query params (react-url-query)
        ↓
  Avatar render (SVG DOM)
        ├─ download PNG (canvas rasterize)
        ├─ download SVG (outerHTML blob)
        └─ shareable deep link
        ↓
  Mint metadata attributes[]
    trait_type / value pairs

This part shows how a URL-synced generator connects to the mint metadata path — and which contracts must be written down.

Concepts, defined where they first appear

📦 URL State
Trait selections living in query params so refresh and share keep the same look.

📦 OptionContext
Context holding all trait keys and option sets for the generator.

📦 Mint Metadata
JSON written to IPFS: name, description, image, attributes.

📦 Trait Attribute
`trait_type` + `value` pair — feedstock for marketplace Viewer filters.

A trait that never hits the URL cannot be recovered in support as 'give me the same avatar'.

Why URL?

The Create page binds option keys with UrlQueryParamTypes.string. Randomize samples options and pushes via onChangeUrlQueryParams. A look becomes a link — pasteable to Discord, reviewable before mint.

URL as source of truth
  ?topType=…&clotheType=…&avatarStyle=Circle
         ↓
  OptionContext.setData(props)
         ↓
  deterministic render

PNG and SVG download

SVG downloads as a blob from Avatar DOM outerHTML. PNG loads that SVG as an image, draws to canvas at 2× scale, and saves avataaars.png via file-saver. Mint usually pins raster or SVG to IPFS and writes the hash into metadata image.

Metadata contract

The marketplace mint form already puts fields such as artist into attributes. Generator traits must map to the same schema: each URL key → trait_type, selected value → value. Otherwise Viewer and later rarity tools speak different languages.

ADR sketch
  Decision: URL-synced traits as mint attribute source
  Why: shareable looks; reproducible before mint
  Trade-off: long query strings; need allowlisted keys
  Follow-up: freeze trait vocabulary version in metadata

Funnel link

Generator → download/share → mint-client metadata → IPFS → on-chain tokenURI. In Bare Crypto these are separate apps; if attribute vocabulary is not shared, the product surface tears.

The mappings that get confused most often

❌ Generator is only a marketing widget
✓ It is the source of mint metadata vocabulary

❌ Keeping traits only in React state is enough
✓ Share and support need URL or an equivalent

❌ Downloading PNG equals metadata
✓ Metadata JSON + image URI are separate; attributes must be mapped

❌ Accept every query key blindly
✓ Without allowlists and defaults, broken looks multiply

A checklist for auditing your own system

1. Which trait keys live in the URL vs local-only?
2. After randomize, does the link reproduce the same SVG in another browser?
3. Do mint metadata attributes match generator keys 1:1?
4. Is PNG size / SVG hash enough for the mint image field?
5. Where is trait vocabulary version frozen in metadata?

What to take away from this part

1. URL-synced traits make generative looks reproducible.
2. PNG/SVG download feeds mint image; attributes need an explicit map.
3. Generator and mint client must share one trait vocabulary.

An unshareable avatar is un-mintable metadata.