Hardware Abstraction

Quantropy does not run on simulators. It uses a multi-vendor QPU fleet of real quantum processors. The hardware abstraction layer is what lets the protocol talk to different vendors through a single, consistent interface.

Multi-vendor QPU fleet

The fleet includes quantum processing units from multiple providers, including:

• IBM — IBM Quantum systems

• IonQ — IonQ trapped-ion systems

• Rigetti — Rigetti superconducting systems

Diversification reduces single-vendor risk and lets the network route jobs for availability and latency. From the API user’s perspective, entropy is “from Quantropy”—the underlying vendor is an implementation detail.

Bypassing simulations to engage live processors

Quantropy is built on the principle that real randomness comes from real physics. Simulators are deterministic: given the same initial state and gates, you get the same output. That is the opposite of non-deterministic entropy.

The hardware abstraction layer:

• Schedules entropy jobs across the fleet based on capacity and latency targets.

• Translates a generic “entropy request” into vendor-specific job formats.

• Sends jobs to live processors, not simulators, so the randomness is produced by subatomic particle collapse.

• Normalizes raw outputs in the Velocity Engine so the API returns consistent, high-fidelity entropy regardless of vendor.

So when you call the API, you are not getting “simulated quantum randomness”—you are getting output derived from real quantum measurements on real hardware.

What this means for you

• Verifiability — Every response is tied to a real job on real hardware and anchored on Solana.

• No vendor lock-in — The API and Quantum Job ID are vendor-agnostic; you do not need to know which QPU served your request.

• Scalability — The fleet can grow (more vendors or more qubits) without changing the API contract.

For latency and normalization: Velocity Engine. For on-chain anchoring: Solana Settlement.