How Quantum Genesis launched: 100 NFTs, two processors, zero classical fallback

This is the launch post I never got around to writing — the post-mortem version, months after the fact. In March 2026 we minted a complete collection where every single piece was seeded by a real quantum measurement on real hardware. No simulators, no classical fallbacks, no "quantum-inspired" marketing fluff. This is what actually happened, the numbers we hit, and what I'd do differently next time.

Quantum Genesis #1 — generated on the Origin Quantum WK_C180

The result was Quantum Genesis: 100 unique NFTs on Polygon, each carrying a quantum seed that didn't exist until a qubit was measured on real hardware.

> Key stat: 100 NFTs. 2 quantum processors (IBM Quantum ibm_fez + Origin Quantum WK_C180). 0 classical fallbacks. 5% royalties via EIP-2981. Total mint cost: under $10 in gas.

Two computers, one collection

We started with Origin Quantum, a Chinese quantum computing company. Their WK_C180 chip — potentially 180 qubits — was reached through the pyqpanda3 SDK via their QCloudService API. Each circuit ran with 8,000 shots, and the first 18 NFTs were generated this way. Getting access to the chip, debugging the SDK, and figuring out the measurement syntax — measure([0,1], [0,1]) with explicit classical bits — was a journey in itself.

Those 18 pieces carry a provenance that's hard to overstate: they're among the very few NFTs in existence generated from a Chinese quantum processor.

Quantum Genesis #50 — the midpoint of the collection

For the remaining 82 NFTs we switched to IBM Quantum. Using Qiskit Runtime's SamplerV2, circuits ran on ibm_fez (156 qubits) and ibm_torino (133 qubits) with 4,096 shots each. IBM's infrastructure was noticeably more stable for batch generation — each NFT took roughly 19 seconds on ibm_fez, with generate_preset_pass_manager at optimization level 1 adapting the 12-qubit circuit to each processor's physical topology.

The entire batch of 82 was generated, converted to PNG, uploaded to IPFS, and minted on Polygon without a single classical fallback. Every seed is verifiably quantum.

Qubit to NFT: the pipeline

  1. Quantum circuit: 12-qubit circuit applies Hadamard gates (superposition) and CNOT gates (entanglement) to create a maximum-entropy state.
  2. Measurement: the circuit runs on real hardware (8,000 shots Origin / 4,096 shots IBM). The measurement distribution becomes raw data.
  3. Quantum seed: distribution hashed through SHA-256 → 256-bit hex seed (e.g., 2cf1b4034f223f5c3e6a83019656e65597828ae375db07b2ef358ac523dde706).
  4. Deterministic RNG: the seed initializes the custom QuantumRNG (xorshift128+ style, seeded via SHA-512) producing a reproducible random stream.
  5. SVG generation: the RNG drives every visual decision — circles, rectangles, ellipses, bezier curves, polygons, gradients, and the color harmonies (complementary, analogous, triadic, split-complementary, tetradic).
  6. PNG conversion: SVGs rasterized to PNG via headless Chrome.
  7. IPFS upload: art plus metadata pinned to IPFS via Pinata.
  8. Polygon mint: each NFT minted on Polygon mainnet as ERC-721 with 5% EIP-2981 royalties.

The clever part: once you have the quantum seed, the art is fully deterministic — you can regenerate the exact same image. But the seed itself came from quantum physics, and it can never be reproduced again.

Quantum Genesis #100 — the final piece of the collection

What's on chain

Each NFT carries metadata stored on-chain and on IPFS:

  • Quantum Seed: the SHA-256 hex (immutable, verifiable).
  • Entropy Level: Low / Medium / High / Maximum.
  • Entropy Score: 0–100 (calculated from the measurement distribution).
  • Qubit Configuration: GHZ-3, Steane-7, etc.
  • Quantum Phase: Interfering, Superposition, Entangled, Decoherent.
  • Color Harmony: Complementary, Analogous, Triadic, Split-Complementary, Tetradic.
  • Complexity Score: 0–100 (visual complexity metric).
  • Processor: Origin WK_C180 / IBM ibm_fez / IBM ibm_torino.
  • Shots: 8000 / 4096.
  • Timestamp: exact measurement time (ISO 8601).

Anyone can verify a piece: take the seed from the metadata, run our open-source generator, get the exact same SVG — a quantum measurement at a specific microsecond on a specific processor.

The Polygon bill

We deployed a custom ERC-721 contract on Polygon mainnet (0x488fCfaEA5fDf1cF6BAED5e8A34D7858033E1a27, on PolygonScan) with:

  • Batch minting (multiple NFTs per transaction).
  • EIP-2981 royalty standard (5% to creator).
  • Metadata frozen via setTokenURI after the full batch upload.
  • Gas optimization: ~35,000 gas per NFT versus ~150,000 on Ethereum mainnet.

Total cost for all 100 NFTs: ~$8.40 in MATIC. The same batch on Ethereum mainnet would have run ~$200–400 depending on gas prices.

OpenSea verification

The collection is live on OpenSea. Verification was granted after we submitted the standard set:

  • Contract address plus a verification message signed by the deployer wallet.
  • Collection metadata (name, description, external link to this blog).
  • Trait standardization so the filters work consistently.

For that last point we'd learned the lesson the hard way — trait strings had to be normalized ("High", not "high" or "HIGH") or the filters on OpenSea turn into a mess.

Lessons we'd repeat or redo

  1. Hardware access is the bottleneck. Origin Quantum access took weeks of negotiation; IBM was faster but queue times vary.
  2. SDK stability matters. pyqpanda3 had breaking changes mid-project. Qiskit Runtime was noticeably more stable.
  3. Batch everything. Single-piece minting is expensive even on Polygon — batch 10–20 per transaction.
  4. Document the seed immediately. We built a seed registry (CSV + JSON) at generation time, and it saved us during metadata assembly.
  5. IPFS pinning needs redundancy. Pin to Pinata plus a local IPFS node plus Filebase. One provider going down shouldn't risk your metadata.
  6. Normalize traits before upload. Use consistent string values for every filterable trait.

If any of this sparks a question about how a specific layer was built, the code and the full pipeline are on GitHub, and the deeper "how it works" writeup lives in the infrastructure post.

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