How One Quantum Seed Becomes an Immutable Certificate: Quantum Genesis Provenance

Quantum Genesis #42 — seeded on IBM Quantum ibm_fez

Provenance is the boring part of art, which is why it's usually the forged part. In the traditional world it's a paper trail — certificates, gallery receipts, expert opinions — all of it forgeable, all of it dependent on trust in whoever holds the stack of paper.

Classical generative NFTs improved on that: provenance becomes a transaction hash plus an algorithm. But the seed is usually a PRNG output, which — as I covered in the min-entropy post — is deterministic and theoretically reversible. The provenance is better, but the "uniqueness" underneath it can be reconstructed.

What we built with Quantum Genesis is a different record: each piece embeds a quantum measurement certificate — a record of a physical event that happened once, on specific hardware, at a specific microsecond, governed by the Born rule. I want to show you the whole chain, from the seed to the on-chain record, so you can verify any piece yourself instead of trusting this blog post.

Why provenance needs to be checkable, not just claimable

A certificate that lives in one place isn't provenance, it's a marketing file. A record like the one below is only useful if three independent systems agree on it:

  • Immutable — stored on Polygon and IPFS
  • Verifiable — the open-source generator reproduces the art from the seed
  • Physics-backed — the measurement can't be replayed, by us or anyone

If all three hold, nobody — including the team — can retroactively change what a token claims to be. That's the property I care about, and it's the reason the contract is frozen with no admin keys.

The certificate: one metadata file

Every Quantum Genesis piece embeds this certificate in its metadata (on-chain reference plus IPFS content). This is the real one for #42:

{
  "name": "Quantum Genesis #42",
  "description": "Seeded by IBM Quantum ibm_fez measurement...",
  "image": "ipfs://bafybeifges7tei5x7drj37f34yhzqofwlz2icbo7z67isg6g446k65yw3a/42.png",
  "external_url": "https://quantumartlab.com/genesis/42",
  "attributes": [
    {"trait_type": "Quantum Seed", "value": "2cf1b4034f223f5c3e6a83019656e65597828ae375db07b2ef358ac523dde706"},
    {"trait_type": "Processor", "value": "IBM ibm_fez"},
    {"trait_type": "Entropy Level", "value": "Maximum"},
    {"trait_type": "Entropy Score", "value": 97},
    {"trait_type": "Qubit Configuration", "value": "GHZ-12"},
    {"trait_type": "Quantum Phase", "value": "Entangled"},
    {"trait_type": "Color Harmony", "value": "Triadic"},
    {"trait_type": "Complexity Score", "value": 84},
    {"trait_type": "Shots", "value": 4096},
    {"trait_type": "Timestamp", "value": "2026-03-19T14:23:12.000Z"},
    {"trait_type": "Circuit", "value": "12-qubit GHZ with H+CNOT ladder"},
    {"trait_type": "Entropy (Shannon)", "value": "3.998 bits/shot"},
    {"trait_type": "Min-Entropy", "value": "11.98 bits"}
  ]
}

The seed is the interesting line: a 256-bit hex string (2cf1b4...dde706) that came out of a 12-qubit GHZ measurement on ibm_fez. The rest of the file is the archaeological record around that seed — which processor, which circuit, how many shots, what the entropy was.

Two places, same record

The certificate lives in two places at once:

  1. On-chain (Polygon). The contract's tokenURI(tokenId) returns the IPFS CID. The CID is content-addressed, so the metadata can't change without the address changing too — an immutable pointer.
  2. IPFS (distributed). The JSON and the PNG are pinned redundantly on Pinata, a local node, and Filebase. Any change to the content produces a different CID, which breaks the on-chain pointer.

You can query the certificate directly against the contract:

# Via Polygon RPC — tokenId 42 is 0x2a
curl -X POST https://polygon-rpc.com \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x488fCfaEA5fDf1cF6BAED5e8A34D7858033E1a27","data":"0xc87b56dd000000000000000000000000000000000000000000000000000000000000002a"}],"id":1}'
# Returns IPFS CID → fetch from any IPFS gateway

What's pinned and where

Each piece gets two IPFS pins through Pinata (our gateway: maroon-bright-perch-405.mypinata.cloud):

AssetFormatSizePath
ImagePNG, 2048×2048~200–500 KBipfs://CID/{tokenId}.png
MetadataJSON (ERC-721 + extensions)~2–5 KBipfs://CID/{tokenId}.json

Redundancy: pinned to Pinata, a local IPFS node, and Filebase (S3-compatible) — three geographically separate copies. If you're curious about how the IPFS metadata scheme itself is structured, the IPFS metadata post goes deeper into the addressing.

Verifying a piece, end to end

This is where the whole scheme either holds up or doesn't. Full verification is three commands, no trusted third party:

# 1. Pull the seed from the NFT's metadata
curl https://maroon-bright-perch-405.mypinata.cloud/ipfs/bafybeifges7tei5x7drj37f34yhzqofwlz2icbo7z67isg6g446k65yw3a/42.json | jq .attributes[0].value
# "2cf1b4034f223f5c3e6a83019656e65597828ae375db07b2ef358ac523dde706"

# 2. Run the open-source generator
git clone https://github.com/marceloclaudecode01/quantum-art-lab
cd quantum-art-lab
pip install -r requirements.txt
python generate.py --seed 2cf1b4034f223f5c3e6a83019656e65597828ae375db07b2ef358ac523dde706

# 3. Compare output
# SVG → PNG → IPFS hash matches the NFT's image CID exactly

If the generated SVG renders to a PNG whose IPFS hash equals the on-chain CID, the physics, the code, and the blockchain all agree. No trust required — or at least, no trust beyond the standard assumption that you believe IPFS content addressing and the Ethereum state trie do what they say.

Standards we comply with

  • ERC-721 — full compliance, verified on PolygonScan
  • EIP-2981 — royalty interface, read by the major marketplaces
  • ERC-721 Metadata — tokenURI returns valid JSON with image, attributes, external_url
  • IPFS — content-addressed, immutable, gateway-agnostic
  • OpenSea — verified collection (blue checkmark), traits filterable

I'll grant that this is a lot of moving parts for what amounts to "the art's record of birth." But provenance is the one part of a token you can't redo after the fact, so it's worth being obsessive. The contract behind the pointers — frozen supply, no admin keys — is the subject of the smart contract walkthrough, which is where the whole thing gets pinned down in Solidity.

Comments

Post a Comment

Popular posts from this blog

Getting Your Collection Visible on OpenSea, Step by Step

Image
Once the contract is deployed and the tokens are minted with metadata on IPFS, the next step is making them discoverable somewhere people actually browse. For us that meant OpenSea, and the process turned out to be less obvious than the one-and-done marketing made it sound. This guide is the step-by-step I ended up following, using our own collection ( Quantum Genesis on Polygon) as the running example. The good news if you're on Polygon, like us: listing a token for sale is gas-free for the seller because it's a signed off-chain order, not a transaction. Before you start Make sure these are in place first: A deployed ERC-721 or ERC-1155 contract — OpenSea auto-detects contracts on Ethereum, Polygon, Arbitrum, Optimism, Base, Avalanche, and other supported chains. Minted NFTs — tokens must exist on-chain; OpenSea reads directly from the blockchain. Metadata on IPFS or a reliable host — each token's tokenURI must resolve to valid JSON with name , description , imag...
Read more

Polygon versus Ethereum for an NFT contract, from the gas bills up

Image
When we set out to put the Quantum Genesis collection on-chain, the first question wasn't about art or metadata. It was: where do we deploy? The answer looks obvious in hindsight, but only because we sat down and counted the actual costs before writing a single transaction. We minted 100 pieces on Polygon for roughly $1 in gas. The same operations on Ethereum mainnet would have run us $500 to $2,000 depending on the day. That gap shaped every decision that followed, so I want to walk through the numbers we saw and the tradeoffs we accepted along the way. Fair warning up front: Polygon is not a strict upgrade over Ethereum. It's a different security model with real compromises. Our reasoning was that for recording ownership of generative art, those compromises were acceptable. Here's the comparison that convinced us, and the cases where I'd make the other choice. The numbers that mattered Ethereum gas is a moving target, so any figure you read is a snapshot. A stand...
Read more

Quantum Error Correction, or Why Your Qubits Forget What They Were Doing

Image
Every time I ran a circuit on IBM's ibm_fez to generate art for the Quantum Genesis collection, the results were never perfectly clean. There was always noise. Errors crept into every measurement, every gate operation, every qubit interaction. Most people read that as a problem. I turned it into the whole point of the project. But before I could appreciate the noise, I had to understand what it actually is. Quantum computers leak information. They forget. They are not like your laptop, where a bit stays a bit until you tell it otherwise. A qubit is a fragile thing, and the whole industry is spending enormous effort just trying to keep one honest. This post is about how that works — the error correction codes, why the naive "copy it three times" trick fails, and where the field actually stands today. Why qubits fail A classical bit stored as a voltage in a transistor stays 0 or 1 reliably as long as the circuit has power. Copy it a billion times and it won't deg...
Read more