Quantum Art Lab

Every developer has heard the disclaimer: "not secure for post-quantum use." Most of us have ignored it. In 2026, that's no longer a safe posture. The migration is no longer hypothetical — the new standards are public, the libraries have shipped, and "harvest now, decrypt later" attacks mean the data you send today could be broken years from now. I'm a developer, not a cryptographer. This post is the practical lay-of-the-land I've built up reading the standards, running the tools, and figuring out what actually changes in a real codebase — the algorithms, what they replace, and the concrete migration steps for a web app or a smart contract. What "quantum" actually threatens Quantum computers threaten a specific class of classical math: factoring and discrete logarithms . RSA, elliptic-curve Diffie-Hellman (ECDH), ECDSA — the workhorses of TLS, SSH, and virtually every cryptocurrency — all rest on problems a sufficiently large quantum compu...

Quantum Key Distribution (QKD) is the rare quantum protocol that does something classical cryptography genuinely cannot: it lets two parties detect, in real time, whether an eavesdropper was listening to their key exchange. The security doesn't come from computational hardness — it comes from measurement disturbance, one of the few aspects of quantum mechanics that holds up even against an adversary with infinite computing power. This post walks through the oldest and most practical of these protocols, BB84 , from the raw qubits up to a working Qiskit implementation. No math degree required — just circuits, Python, and the willingness to re-sift a key. The problem BB84 solves Two parties, Alice and Bob, want to share a secret random bit string. A classic approach — Diffie-Hellman — is secure only if the enemy can't solve a hard math problem. But a future quantum computer (or a patient classic one) could break it. BB84 sidesteps the math entirely: Alice sends information enc...

When we first seeded Quantum Genesis, we ran circuits the old way: build a circuit, call execute() or backend.run() , and wait for a Result object with raw counts. It worked, but every run felt like negotiating with the machine directly. Since then the Qiskit SDK has moved to a model built around the primitives — first Sampler / Estimator (V1), now SamplerV2 / EstimatorV2 on Qiskit Runtime. This post is the mental model I wish I'd had, with code you can run today. If you've been following old tutorials and finding that qiskit.execute no longer exists, or that IBMQ.save_account is gone, this is the update you need. The days of manually transpiling and submitting a single circuit to backend.run() for every experiment are over. Modern Qiskit wants you to think in terms of what you want to compute , not how to shuffle bits from the QPU. Why the primitives exist The old flow forced you to become an expert in the transport layer: pick a backend, submit a job, poll for sta...

For the first fifteen years of crypto, "digital scarcity" meant one thing: social consensus enforced by code. Bitcoin's 21M cap holds up because miners keep agreeing on the rules. NFTs are "limited" because a smart contract and a marketplace agree on the number. An Art Blocks release is scarce because of artist reputation and platform curation. Every limited edition in crypto is limited because we all agree it is. That arrangement works — until it doesn't. Forks happen. Contracts get upgraded. Marketplaces delist. Narratives shift. The scarcity is only as strong as the consensus holding it, and consensus is something people can always change their minds about. With Quantum Genesis we tried a different foundation: physics. Let me explain what that actually means, because I don't think "physics-backed" should be a marketing buzzword. It should be a specific technical claim you can check. Consensus-based scarcity and its failure modes The con...

I used to do everything with Math.random() and a seeded PRNG, the same way every generative art platform does. Art Blocks, fxhash, most custom pipelines — they all start from a pseudorandom number generator. And whenever the question of "true" randomness came up, the answer was always the same: "It passes statistical tests. It's random enough for art." For aesthetics, that's true. For uniqueness, it's false — and that's the part that matters when you're promising someone a one-of-one. "Random enough" is a category error, and I want to show you the math, because in this post I'll make the full argument: every PRNG is deterministic, every PRNG is reversible, and every PRNG has a finite state space. Then I'll show where a quantum measurement breaks each of those limits. First, the claim everyone makes The stock defense of a PRNG is that its output is computationally indistinguishable from random — no efficient algorithm can t...

Quantum Genesis needed 100 quantum seeds, one per NFT. We started on Origin Quantum's WK_C180 and produced the first 18 pieces there. Then we switched to IBM Quantum (ibm_fez and ibm_torino) for the remaining 82. I want to be upfront about why: this wasn't a strategy we designed, it was a necessity forced on us, and the comparison below is honest field notes rather than a curated spec sheet. Before relying on vendors' claims, we'd spent the previous weeks building a working pipeline — the QRNG approach is laid out in the generator post , and my earlier Origin vs IBM comparison captured the first impressions. This post is the production version of that, at 100 jobs. The hardware, side by side Metric Origin Quantum WK_C180 IBM Quantum ibm_fez IBM Quantum ibm_torino Qubits 180 156 133 Topology Not fully public Heavy-hex (fixed coupling) Heavy-hex (fixed coupling) SDK pyqpanda3 Qiskit Runtime (SamplerV2) Qiskit Runtime (SamplerV2) Access model QCloudService API (privat...