I Used a Real Quantum Computer to Generate Art - And the Randomness Is Nothing Like What Algorithms Produce

marceloclaudecode01 — Thu, 19 Mar 2026 14:37:38 +0000

I Used a Real Quantum Computer to Generate Art — And the Randomness Is Nothing Like What Algorithms Produce

What happens when you replace Math.random() with actual quantum measurements from a superconducting chip cooled to 15 millikelvin? I found out.

Last month I had a weird idea: what if I could create art that was genuinely, physically unique — not "unique" in the way a UUID is unique, but unique the way a snowflake is unique? Born from actual physical randomness that no algorithm could reproduce?

That rabbit hole took me from my apartment in Brazil to a quantum chip in Hefei, China — through three failed attempts, a broken SDK, a timezone nightmare, and eventually, 18 pieces of generative art that I can cryptographically prove were born from real quantum measurements.

Here's the full story.

The Problem With "Random"

Every generative art tool — from Processing to p5.js to DALL-E — relies on pseudorandom number generators (PRNGs). These algorithms look random, but they're deterministic. Same seed, same output. Every time.

This bothered me. Not because PRNGs are bad — they're excellent for most purposes. But because I wanted to explore something different: what does art look like when seeded by genuine physical randomness?

Not atmospheric noise (random.org), not mouse movements, not lava lamps. I wanted the deepest randomness physics allows: quantum measurement outcomes.

When you put a qubit in superposition and measure it, the result is fundamentally undetermined until the moment of measurement. This isn't a gap in our knowledge — it's how the universe works. Einstein hated it. But every experiment for 100 years has confirmed it.

So I set out to connect a real quantum processor to a generative art pipeline and put the results on a blockchain. Simple, right?

It was not simple.

Attempt #1: The Old SDK (Failed)

I started with pyqpanda (the original SDK, version 3.8.5). Got it installed. Wrote my first circuit. Tried to connect to the quantum cloud.

Unauthorized

The old API endpoints were deprecated. The documentation pointed to URLs that returned 401s. The chips I was targeting — d3, d4, d5 — were listed as "in maintenance." I spent two days on this before discovering that the entire API layer had been migrated to a new SDK.

Lesson learned: Always check if you're reading current documentation.

Attempt #2: The New SDK, Wrong Import (Failed)

I switched to pyqpanda3 (v0.3.4), the completely rewritten SDK. Different API surface. Different class names. Different everything.

My first import:

from pyqpanda3.qcloud import QCloudService

ImportError: cannot import name 'QCloudService' from 'pyqpanda3.qcloud'

The module existed, but the class was nested one level deeper than the documentation suggested. After digging through the actual package structure:

from pyqpanda3.qcloud.qcloud import QCloudService  # This works

Then I hit the measurement syntax. The old SDK used Measure(qubit, cbit). The new one needs explicit lists:

measure([0, 1, 2, 3], [0, 1, 2, 3])  # qubits AND cbits, both required

I only figured this out after three TypeError crashes and reading the C++ binding source code.

Lesson learned: When SDKs get rewritten, the docs lag behind the code.

Attempt #3: Connected — But to What?

Finally got the connection working. The QCloudService connected, I could list backends:

service = QCloudService(api_key, "http://pyqanda-admin.qpanda.cn")
backends = service.backends()
# {'HanYuan_01': False, 'PQPUMESH8': True, 'WK_C180': True,
#  'full_amplitude': True, 'partial_amplitude': True, 'single_amplitude': True}

HanYuan_01 (the original Wukong 72-qubit chip) was offline. But WK_C180 was online — a 180-qubit superconducting processor I hadn't even seen documented publicly.

Then I tried to run my circuit:

backend = service.backend("WK_C180")
job = backend.run(prog, 1000)  # 1000 shots

RuntimeError: This function is only for Full_AMPLITUDE.

The run(prog, shots) signature was for simulators only. Real chips needed a different overload with QCloudOptions:

opts = QCloudOptions()
job = backend.run(prog, 1000, opts)
result = job.result()

And then — after three days of failures — I saw real quantum data for the first time:

{'0000': 498, '1111': 487, '0010': 5, '0001': 4, '1110': 3, '1101': 2, '0100': 1}

Those small counts — the 5, the 4, the 3 — that's real quantum noise. Decoherence. Gate errors. Thermal fluctuations in a chip cooled to 15 millikelvin. You can't fake that distribution with a PRNG.

I stared at my terminal for a solid minute.

The Pipeline That Actually Works

Here's what I ended up building:

Quantum Circuit → WK_C180 Chip (1000 shots) → Measurement Results
     ↓
SHA-256(sorted results) → 256-bit Quantum Seed
     ↓
Seed bits → Color palette + Shape rules + Pattern complexity + Entropy viz
     ↓
SVG Generative Art + Quantum Authenticity Certificate
     ↓
IPFS (immutable storage) → ERC-721 on Polygon (on-chain proof)

Nine Circuit Topologies

I didn't want a one-trick pipeline. Different quantum states produce different probability distributions, which produce different art. So I designed 9 circuit families:

Circuit	Qubits	What Makes It Interesting
Bell State	2	The simplest entangled system possible
GHZ-3	3	Maximally entangled — measure one, know all three
W-State	4	Entanglement that survives partial measurement
GHZ-5	5	Deeper entanglement chain
Cluster-6	6	Graph-state entanglement (used in quantum error correction)
Surface-8	8	Topological code pattern
Cat-State	12	Schrödinger's cat at scale — macroscopic superposition
Ring-16	16	Circular entanglement topology
Full-20	20	Maximum entanglement across 20 qubits

Each topology creates a different structure in the probability distribution, which maps to visually distinct art. GHZ circuits produce sharp, symmetric patterns. W-states produce more organic, flowing forms. Cluster states generate lattice-like structures.

This is a creative dimension that simply doesn't exist in classical generative art. No PRNG can produce topology-dependent randomness because there's no physical topology — it's just an algorithm.

The Authenticity Certificate

Every generated piece includes a JSON certificate:

{
  "certificate_id": "499fd20848e18e0e",
  "quantum_seed": "2cf1b4034f223f5c3e6a83019656e655...706",
  "source": "quantum_real_WK_C180",
  "source_verified": true,
  "processor": "Origin Quantum Cloud — WK_C180 (real quantum chip)",
  "circuit": "H + CNOT seed-generation circuit (12 qubits, 8000 shots)",
  "timestamp_utc": "2026-03-18T14:50:07.071679+00:00",
  "integrity_hash": "499fd20848e18e0e01338eff3cb739f7...20d"
}

The integrity_hash chains the raw measurement data to the timestamp and circuit config. Anyone can verify: does this seed produce this art? Does this hash match this data? It's a cryptographic proof-of-quantum-origin.

The Surprising Part: Quantum Noise as Artistic Signature

Here's the finding I didn't expect.

When I analyzed the entropy of quantum-generated seeds versus PRNG seeds, they were measurably different:

Metric	Classical PRNG	WK_C180 Quantum
Shannon entropy (8-bit)	7.98-7.99	7.92-7.99
Chi-squared p-value	> 0.95	0.3-0.8
Serial correlation	~0.000	0.001-0.01

Classical PRNGs are too perfect. They produce suspiciously uniform distributions — a p-value above 0.95 means the output is more uniform than real randomness should be.

Quantum measurements show natural variance. The slight deviations from perfect uniformity aren't flaws — they're signatures of a real physical process. Gate imperfections, crosstalk between qubits, thermal noise at millikelvin temperatures. It's the difference between a photograph and a CGI render: both look real, but one actually is.

This variance translates directly to the art. Quantum-seeded pieces have a subtle organic quality that's difficult to reproduce algorithmically. The imperfection is the authenticity.

On-Chain Verification

The smart contract stores quantum provenance data directly on Polygon:

struct QuantumData {
    string quantumSeed;
    string processor;
    string circuitConfig;
    uint256 entropyScore;
    bool quantumVerified;
}

mapping(uint256 => QuantumData) public quantumProof;

This means quantum verification lives on the blockchain permanently. No API dependency. No trust required. Anyone can query the contract and verify the quantum origin of any piece in the collection.

What I Learned (The Honest Version)

Real quantum hardware is accessible — but rough around the edges.

The cloud platforms work. You can submit circuits and get results from real chips. But the SDK documentation lags behind the code, error messages are cryptic, and you'll spend more time debugging imports than writing quantum circuits.

Quantum cloud services operate differently from conventional cloud.

There's no "always-on" API. Chips go offline for maintenance. Queue times vary. Your circuit might run in 5 seconds or 90 seconds depending on load. If you're building production applications, you need robust fallback chains and circuit breakers.

The real value isn't "randomness" — it's verifiability.

Hardware random number generators (HRNGs) based on thermal noise or radioactive decay also produce true randomness. The unique advantage of quantum cloud computing is the audit trail: you get a timestamped record of exactly which chip, which circuit, and which measurement produced your data. That's what enables cryptographic certification.

Different quantum states really do produce different art.

This wasn't obvious going in. I expected all quantum randomness to look similar once hashed. It doesn't. The probability distribution structure imposed by circuit topology survives the hash and visibly affects the generative output. This is a genuinely new creative parameter space.

Current Status & What's Next

Done:

18 unique pieces generated and verified on WK_C180
9 circuit topologies tested and characterized
Full pipeline: quantum → art → certificate → IPFS → blockchain
Smart contract deployed on Polygon

Next:

Complete the 100-piece collection
Open-source the full pipeline (quantum circuit library + art generator + certificate system)
Explore higher qubit counts for richer entropy spaces
Experiment with quantum error correction codes as artistic motifs

Try It Yourself

The quantum computing barrier is lower than you think:

pip install pyqpanda3

from pyqpanda3.core import QProg, H, CNOT, measure
from pyqpanda3.qcloud.qcloud import QCloudService

# Sign up at qcloud.originqc.com.cn for an API key
service = QCloudService(your_api_key, "http://pyqanda-admin.qpanda.cn")

# Build a simple Bell state circuit
prog = QProg()
prog << H(0) << CNOT(0, 1) << measure([0, 1], [0, 1])

# Run on a real chip
backend = service.backend("WK_C180")
from pyqpanda3.qcloud.qcloud import QCloudOptions
job = backend.run(prog, 1000, QCloudOptions())
result = job.result()

print(result)  # Real quantum measurement data

That's it. ~10 lines to run a quantum circuit on real hardware from anywhere in the world.

Full project code: github.com/marceloclaudecode01/agency-manager

Acknowledgments

All quantum computations were performed on the WK_C180 superconducting quantum processor via the Origin Quantum Cloud platform using the pyqpanda3 SDK. The platform provides open access to real quantum hardware for researchers and developers worldwide — which is what made this experiment possible from a laptop in Brazil.

Marcelo Santos — Full-stack developer from Brazil building at the intersection of quantum computing and Web3.

If you're working on anything quantum-related, I'd love to connect — especially if you've found other creative applications for real quantum hardware.

Tags: #QuantumComputing #GenerativeArt #TrueRandomness #QuantumEntropy #Web3 #Blockchain #pyqpanda3 #OpenSource #SuperconductingQubits #QuantumCloud

DEV Community: marceloclaudecode01