QVRF demonstrates quantum entropy injection for on-chain randomness

QVRF is our reference implementation of QRNG injection into a verifiable on-chain randomness service. Its purpose is not to replace existing VRF infrastructure but to demonstrate, concretely, that quantum entropy can be mixed into any VRF-style pipeline without compromising verifiability, speed, or developer ergonomics.

What QVRF demonstrates

QVRF takes three independent entropy inputs and mixes them into a single randomness seed that the coordinator uses to generate the random words requested by a consumer contract:

• QRNG-sourced bytes — fresh quantum entropy from our QRNG device, bound cryptographically to the specific request
• Request commitment — deterministic per-request data (chain ID, coordinator address, consumer, nonce, callback gas) that binds each result to exactly one request
• Recent blockhash — commits the randomness to the state of the chain at request time

The mixed seed is keccak256(domain || chainId || coordinator || quantumHash || commitment || blockhash). No single input decides the result — biasing the QRNG, predicting the blockhash, or front-running the commitment is not enough on its own to steer the output. The raw QRNG bytes are published on-chain with every result, so anyone can recompute the seed and check it against the proof.

Measured latency

Network	Verifier	Avg Latency	Min	P90
L2 A	UltraFast	462ms	331ms	627ms
L2 A	Full	670ms	322ms	898ms
L2 B	UltraFast	1,742ms	1,484ms	1,787ms
L2 C	UltraFast	2,243ms	1,481ms	2,941ms

Sub-second average fulfillment on the fastest network tested, with P90 under one second. The latency comes from three engineering decisions:

• WebSocket inline fulfillment — events are detected in under 100ms and proof generation starts immediately, rather than waiting on a polling interval.
• L2-native block handling — Arbitrum uses the ArbSys precompile for L2 block numbers rather than L1; OP Stack chains use block.number directly. No waiting on L1 confirmations.
• Parallel fulfillment — concurrent transaction submission via a NonceManager enables parallel fulfillments per chain.

On-chain attestation

Every fulfillment emits device provenance data alongside the ECVRF proof — device ID, delivery timestamp, self-test status, and compliance metadata. A consumer can verify not only that the randomness came from our coordinator, but that the underlying entropy came from a specific QRNG device in a specific, self-tested state.

The point of the demonstration

QRNG injection is not specific to QVRF. The same mixing construction can be applied to existing VRF oracles, randomness beacons, and commit-reveal schemes. Any randomness system is only as strong as its entropy source. QVRF shows that upgrading the entropy source is structurally straightforward — the consumer contract doesn't change, the proof verification doesn't change, and the developer experience doesn't change. What changes is the underlying guarantee.

Status

QVRF is a reference deployment ahead of mainnet. The coordinator, verifiers, and sample consumers are open to partner inspection.