QryptoRand: quantum randomness for Solidity applications

QryptoRand explores how a quantum random-number generator can supply values to a Solidity application. iQrypto’s public prototype connects an off-chain source to on-chain storage through a Rust controller. It gives developers concrete contracts and an integration example to inspect alongside the engineering questions that arise when physical randomness reaches a blockchain.

This case study brings together the Tremplin Web3 project context, the QryptoRand bridge and its companion lottery application, with a practical route for discussing an evaluation with iQrypto.

The Tremplin Web3 project

Digital Wallonia’s 2024 selection announcement lists iQrypto among the selected projects. It describes an intended verifiable-random-function demonstrator based on quantum random numbers, together with a white paper.

The later DigitalWallonia4.Trust programme results, published on 23 December 2025, describe the wider programme’s proof-of-concept work and lessons from blockchain experimentation. That programme report provides context; it is not an independent validation of QryptoRand’s security or performance.

The public technical resource is the iQrypto/QryptoRand repository, whose initial publication is dated 18 August 2025. The implementation described here is the revision fcb98e9, reviewed for this article on 31 October 2026. The repository labels the project alpha.

The application: bringing external randomness into Solidity

A Solidity contract cannot directly open a connection to a physical QRNG. An off-chain service must obtain values and submit transactions that make them available on-chain. Ethereum’s developer documentation describes this general role as an oracle.

A useful evaluation case is randomized selection in an application: obtain a value, then use it to select an item from a defined set. The QryptoRand tutorial illustrates this with a list of strings. Games and randomized allocations raise the same integration question, but their fairness also depends on when choices are fixed, when values become visible and who can influence delivery.

Solidity’s security guidance points out that contract data is public, including variables marked private. The complete application must therefore account for observers and transaction ordering when using randomness.

A concrete example: the Queno lottery demonstrator

The companion lottery-app-qryptorand repository shows how an application can consume the QryptoRand bridge. Its React interface is labelled Queno. The repository describes a local Anvil simulation using test-only balances; it is presented here as an engineering demonstrator.

The reviewed application snapshot, initially published on 18 August 2025, contains the frontend, a Solidity lottery contract and local setup documentation. The application flow is:

1. Choose inputs. The React interface lets a user select up to four numbers from a grid of 32.
2. Submit a round. The frontend sends the selection to the Solidity lottery contract through the connected local-development wallet.
3. Consume a random value. The lottery contract requests one stored value from QryptoRand. Its extraction helper derives four distinct numbers in the range 1 to 32 from that value.
4. Display the result. The contract compares the selections and emits WinningNumbersGenerated. The frontend listens for the event and displays the result and session history.

The React source separates the player’s optional Auto Pick from the draw: browser pseudorandomness chooses player inputs, while the draw consumes the value returned by the storage contract. Whether that stored value came from the hardware or PRNG development path depends on the configured QryptoRand backend.

In the published lottery contract, the request sets verifyProof to false. This demonstration does not perform the optional VRF verification on retrieval. The public-pool timing and delivery questions below therefore remain part of evaluating a complete application.

Together, the two repositories show different engineering layers: QryptoRand supplies the bridge and storage interface; the lottery application supplies a concrete consumer and user interface. The example demonstrates that integration structure, without establishing production-game fairness or a quantum-resistant application.

From the source to the contract

1. Off-chain sourceA hardware adapter obtains random values and the associated hash, signature and proof data. A separate development mode uses a PRNG.
2. Rust controllerThe controller follows contract events, requests values and submits them through the generated Solidity bindings.
3. Solidity storage and consumerThe storage contract checks submissions and maintains a pool. A consumer requests stored values, with an optional VRF verification path.

The Rust controller listens for capacity and consumption events. Its supporting library packages values, hashes, signatures and proofs for single or batch submission. The hardware path is written around a TCP interface.

The storage contract includes owner-managed generator-key registration, hash and signature checks, nonces, and single or multiple-value requests. The prototype also contains token-accounting logic. This article describes its software architecture; it does not offer a token product.

At the consumer interface, askRandomNumber(bool verifyProof) retrieves a value from the pool. Setting the proof flag selects the verification path implemented by the contract. It does not turn the request into a fresh, secret, request-bound hardware measurement.

Read the code and Solidity example

The resources are available without an enquiry form:

• Project README and source code: architecture, setup and the separate hardware and PRNG modes. The repository carries an MIT licence.
• Lottery application and source: the React/Queno consumer, Solidity draw logic and local Anvil setup. The repository is labelled alpha and links QryptoRand as a submodule. Align the frontend addresses and dependency revisions with the local deployment.
• Solidity integration tutorial: linking contracts, requesting a stored value and selecting an entry from a list.
• Consumer example: the corresponding Solidity source. Check example calls against the storage contract at the same revision.
• Reviewed source snapshot: the revision used for this article, so later repository changes can be distinguished from this explanation.

The documented local workflow uses Foundry’s Anvil development chain. The PRNG mode is useful for exploring the software path without hardware; it does not provide quantum entropy. The public crate’s hardware-backend dependency is commented out, so a hardware evaluation also needs compatible backend software and configuration. Contact iQrypto to discuss that integration.

What an application evaluation needs to establish

The prototype makes the hardware-to-contract interfaces inspectable. Its alpha status and public code do not establish an audited production service. Before choosing an architecture, define the following with the application team:

• Visibility and timing. Values submitted to on-chain storage are public before a later consumer retrieves them. A game or allocation protocol needs a design that prevents participants from exploiting that visibility.
• Delivery and control. Decide who operates the source and controller, registers keys, submits transactions and handles missing or delayed values.
• Proof and source assessment. A signature authenticates a message under a key; a VRF proof checks a cryptographic relation. Neither independently proves that the physical source supplied the claimed quantum entropy.
• Integration behaviour. Check nonces, replay handling, proof-to-value binding, access control, transaction ordering and failure recovery across the complete path.
• Operational evidence. Measure latency, transaction overhead and capacity on the chosen chain and hardware, and review the contracts before use with assets or consequential decisions.

These are questions for evaluating the whole application. A QRNG source alone does not make a blockchain application quantum-resistant or remove trust in the delivery system.

Discuss a QryptoRand evaluation

Contact iQrypto with questions about QryptoRand, the lottery demonstrator, the source code or the hardware interface. Useful starting details are your Solidity or EVM environment, the decision that consumes randomness, when participants commit their inputs, and the evidence you need from an evaluation.

If your first step is a hardware assessment, VERA-Q’s evaluation page explains the current shortlist-access route. Compatibility with this prototype’s hardware backend should be discussed separately. The entropy-source explanation and integration-path guide provide the broader QRNG background.