Is it really a quantum computer?
Every Entanglement draw runs on an IBM quantum processor through IBM Quantum's public cloud. IBM doesn't sign its results, so no page can give a cryptographic proof of that. What we can do is show everything IBM itself records about each job, and give you the exact experiment to run on your own free IBM account. Here is all of it.
Qubit Milestone · 100 qubits at $1M
When $ENTNGL reaches a $1,000,000 market cap, we attempt to entangle 100 qubits at once on an IBM processor, live: one GHZ state (|00…0⟩ + |11…1⟩)/√2 spread over 100 physical qubits, a scale that until recently only research labs reached. At this size the chip's noise is the real opponent: the run counts as entangled only if its measured fidelity is above 0.5. Every count, the qubits used and the fidelity are published here, pass or fail. The run gets its own special draw and a one-of-one certificate.
1 · IBM's own record of the job
For each job, IBM's cloud reports when it was created, when it started on the processor, when it finished, and the seconds of quantum processor time it charged. Our commit on Solana comes a few seconds after IBM reports the job finished: the outcomes can't be committed before they exist.
2 · The hardware fingerprint
A real chip is imperfect in its own way: each physical qubit has its own readout error and coherence time, and each coupler its own gate error, measured and published by IBM several times a day. Here are the exact qubits the job ran on, with the calibration IBM published that hour. Real results land below the ideal value by about what these errors predict; numbers invented on a laptop would be either too perfect or not match that day's calibration.
3 · Every quantum job so far
Each dot is a real job on IBM hardware. Left of the dashed limit is what any classical system can produce; the right end is the quantum maximum. Every result sits in between, with the noise of a real chip.
4 · Run it yourself
The strongest proof is the one you make. With a free IBM Quantum account (10 minutes of quantum time per month), run the same Bell test on the same processors and compare your S with ours.
- Create a free account at quantum.cloud.ibm.com, then an API key and an instance on the free Open plan.
- Install Python and two packages:
pip install "qiskit==2.5.*" "qiskit-ibm-runtime==0.50.*"
- Download reproduce_bell.py (40 lines, read it first) and put your key in an environment variable:
export IBM_QUANTUM_API_KEY=your_key (Windows: set IBM_QUANTUM_API_KEY=your_key)
- Run it on a processor from the list above:
python reproduce_bell.py ibm_fez
About 3 seconds of quantum time. You'll get S around 2.6–2.75: above 2, so the qubits were entangled, just like in our draws. You can also see your job in your own IBM dashboard.
5 · What this proves, and what it can't
- IBM's own timestamps and QPU time for every job
- the physical qubits each job ran on, and their calibration that hour
- results above the classical limit, with real-hardware noise
- the commit on Solana always after IBM finished, and before the drand round
- a script anyone can run to get the same physics
- cryptographically that a given result came from IBM: IBM doesn't sign results publicly, and job details are visible only to the account that ran them
- that a classical machine couldn't fake numbers: a Bell test rules out classical physics only for an honest device
- We're users of IBM Quantum's public cloud, not affiliated with IBM.
What protects the draw itself doesn't depend on any of this: the outcomes are committed on Solana before the public drand beacon round exists, so whoever produced them couldn't aim at a winner. See Results.