Provenance
A collection that claims a physical source of randomness has to be checkable, or the claim is decoration. Everything here exists so a stranger can regenerate all 2,048 tokens and compare them with what was minted.
The measurement
Three jobs, two processors, run before the mint opened. Every register in the collection comes from one of these. The timestamps on these jobs are also the reason we do not claim that minting performs a computation: the computation was already done.
| Backend | Circuit | Shots | IBM job ID |
|---|---|---|---|
| ibm_marrakesh | uniform | 1,408 | dag1nk1hvn6c73cq0h3g |
| ibm_fez | uniform | 512 | dag1nj8mhr3c73e4hskg |
| ibm_marrakesh | bell | 156 | dag1npfi3e6s738lqf6g |
ibm_kingston is available on the same account but
is not used: its queue ran to hours on every attempt, and a run that happens
exactly once cannot depend on a source that is not available on demand.
Pool hash
SHA-256 over the ordered raw registers. Uniform circuits first in the order
ibm_marrakesh, ibm_fez, then the Bell circuit; each
job's shots in the order the hardware returned them.
62d7157814c447df8349484fcd7a5eb27ccf3a6635372d705c31097dd784eeef
Salt generated, not yet on chain. The SHA-256 of the binding salt is fixed and published here; the salt itself stays secret until sellout. The mainnet collection that will carry both hashes on chain has not been created yet.
ba6bfdd6ca9390fe9121be6748158dfff9ab2dcf069f765682f0a02bb25f39ef
Code, hashed before the run
These files turn measured bits into traits. They were hashed before any hardware job was submitted, which is the part that matters: the tier cuts and trait weights could not have been tuned after somebody saw how the distribution landed. The site build fails if these stop matching.
| File | SHA-256 |
|---|---|
| entropy/analyze_pool.py | 07b31709df629ede2103f6f3c904604c99d8e220e102eea71d43054c94b85457 |
| entropy/collect_pending.py | 223a8c29e410c48a9226027e3efbf935a3fa705242fc47ca23cd26215fe53963 |
| entropy/generate_pool.py | 0cc8684037251e2092f6a6b9e40542c6acc10bbfbd62ccd5e35fbc781f22945c |
| entropy/pool.py | 8fad41477e2637f87e95624621bc376ff28a53a78885a8b8f34c71927a7b0477 |
| entropy/traits.py | cdb6fe39fedf70ee30329c9f71615c0c4a2076bf53c6b41a09e10e205dfacd8d |
What the hardware actually did
Real qubits are not fair coins, and the collection does not pretend otherwise. Readout error and decay pull individual qubits away from 50/50 — which is why the trait seed is a hash of the register rather than the register itself, and why the colour split is not exactly even.
| Backend | Shots | mean p(1) | min-entropy | Worst qubit |
|---|---|---|---|---|
| ibm_marrakesh | 1,408 | 0.5057 | 145.9 / 156 | q82 at 0.0582 |
| ibm_fez | 512 | 0.5012 | 147.1 / 156 | q72 at 0.6230 |
Which qubits drift changes between calibrations. An earlier run on the same processor had a different qubit stuck the other way. This is the sense in which the collection cannot be reproduced: not that the maths is secret, but that this state of these machines is gone.
How to verify
- Fetch the published pool file and confirm its SHA-256 matches the hash above.
- Confirm that hash equals the one in the on-chain commitment transaction.
- Run the published generator over the pool. It writes 2,048 images and metadata sets, deterministically.
- Compare any token's image and traits with what the marketplace shows.
- After sellout, take the published salt, recompute the permutation, and confirm that every token's mint index maps to the register it actually received.
Step 5 is why the salt stays secret until the end. The registers themselves are published early — you can see the whole collection before you buy — but with the salt withheld, knowing what each register looks like tells you nothing about which one a given mint receives. The commitment is what stops us re-shuffling afterwards.