PQR SDKs
Post quantum ready client libraries that connect institutions to the Quantova Virtual Machine. Every transaction is signed on the device with NIST approved post quantum algorithms, and every signature is verified by the protocol before any state change.
The SDKs are available for JavaScript, Python and Rust, alongside a REST and WebSocket API. Banks, treasuries and supervisory bodies integrate them directly into existing systems without holding cryptographic trust at the network edge.
One toolset across three languages and an API
Each library exposes the same post quantum primitives so teams adopt Quantova in the language their systems already run.
| Library | Runtime and use |
|---|---|
| qweb3.js | JavaScript and TypeScript for browsers, wallets and Node services |
| qweb3.py | Python for back office systems, settlement scripts and data pipelines |
| qweb3.rs | Rust for high assurance services and validator tooling |
| @quantova/api | REST and WebSocket access for systems that read and submit without a client |
| Signature schemes | Falcon 512, Dilithium ML DSA, SPHINCS+ SLH DSA |
| Hashing | SHA3 256 |
| Standard | NIST approved |
Four packages, one post quantum contract
Each package connects to the QVM, derives Q addresses, signs with post quantum keys, calls contracts, resolves QNS names, reads the fee oracle and streams events. The surface is identical, so an institution can read in Python, sign in Rust and serve from Node without changing behaviour.
qweb3.js
The client for browsers, wallets and Node services. It connects to a Quantova node, derives Q addresses from post quantum public keys, signs transactions on the device with Falcon 512, Dilithium ML DSA or SPHINCS+ SLH DSA, calls QVM contracts, resolves QNS names and subscribes to execution events. The QMask wallet is built on this library.
- ✓Connect over HTTP and WebSocket, derive Q addresses, manage on device keypairs.
- ✓Sign and submit transactions, call QVM contracts, resolve QNS names.
- ✓Read the fee oracle and stream live events for monitoring.
// Illustrative. Sign a transfer on the device with a post quantum key import { Qweb3, Signer } from "qweb3.js"; const q = new Qweb3("https://rpc.quantova.org"); const signer = Signer.fromSecretKey(secret, "Falcon 512"); const to = await q.qns.resolve("treasury.q"); // QNS name to Q address const fee = await q.feeOracle.estimate(); // capped, predictable const tx = await q.tx.transfer({ to, amount: "1000", fee }) .sign(signer) // secret key never leaves .submit(); // QVM verifies before state change q.events.on(tx.hash, (e) => console.log(e.status, e.proof));
# Illustrative. Back office settlement with on device signing from qweb3 import Qweb3, Signer q = Qweb3("https://rpc.quantova.org") signer = Signer.from_secret_key(secret, scheme="Dilithium ML DSA") addr = signer.q_address() # SHA3 256(public_key) as Q1 to = q.qns.resolve("custody.q") # resolve QNS name fee = q.fee_oracle.estimate() # read the fee oracle tx = (q.contract("qvm1settlement...") .call("release", to=to, amount="1000000", fee=fee) .sign(signer) .submit()) # protocol verifies the signature receipt = q.wait(tx.hash) # proof + hash commitment
qweb3.py
The client for back office systems, settlement scripts and data pipelines. It connects to a node, derives Q addresses, signs with post quantum keys, calls QVM contracts and resolves QNS names, and returns execution proofs and hash commitments for reconciliation. Treasuries and finance teams integrate it directly into existing Python infrastructure.
- ✓Derive Q addresses from Dilithium ML DSA, Falcon 512 or SPHINCS+ SLH DSA keys.
- ✓Call QVM contracts, resolve QNS names, read the fee oracle.
- ✓Receive execution proofs and hash commitments for audit.
qweb3.rs
The client for high assurance services and validator tooling. It provides the same connect, derive, sign, call, resolve and subscribe surface with the memory safety and performance Rust offers for systems under load. SPHINCS+ SLH DSA gives a hash based option for the most conservative signing requirements.
- ✓Sign with SPHINCS+ SLH DSA, Falcon 512 or Dilithium ML DSA on the device.
- ✓Call QVM contracts and resolve QNS names with strong type guarantees.
- ✓Stream events over WebSocket for validator monitoring and reconciliation.
// Illustrative. High assurance signing with a hash based scheme use qweb3::{Qweb3, Signer, Scheme}; let q = Qweb3::connect("https://rpc.quantova.org").await?; let signer = Signer::from_secret_key(secret, Scheme::SphincsSlhDsa); let to = q.qns().resolve("reserve.q").await?; // QNS to Q address let fee = q.fee_oracle().estimate().await?; // fee oracle let tx = q.tx() .transfer(to, "1000", fee) .sign(&signer) // secret key stays local .submit().await?; // QVM verifies first let receipt = q.wait(tx.hash).await?; // proof + commitment
# Illustrative. Read state and submit a pre signed transaction GET /v1/account/q1treasury... # balance, nonce, pinned key GET /v1/qns/resolve?name=custody.q # QNS name to Q address GET /v1/fee/estimate # fee oracle POST /v1/tx/submit { "signed": "0x...", "scheme": "Falcon 512" } # verified by QVM # WebSocket stream of execution events WS /v1/events?topic=tx.q1treasury... # status + proof
@quantova/api
Direct REST and WebSocket access for systems that read state and submit transactions without a bundled client. It resolves QNS names, reads accounts, blocks and contract state, exposes the fee oracle and streams execution events. Signing remains on the integrator system, so transactions are submitted already signed and verified inside the QVM.
- ✓Read accounts, blocks and contract state, resolve QNS names over REST.
- ✓Submit pre signed transactions; the QVM verifies before any state change.
- ✓Subscribe to execution events over WebSocket for live reconciliation.
What the SDKs do
On device signing
Keypairs are generated and held by the integrator. Every transaction is signed locally with Falcon, Dilithium or SPHINCS+, and the secret key never leaves the system.
Account and key handling
Addresses are derived as the SHA3 256 hash of the public key and shown as Q1 identities. Public key pinning binds each account to the key it first signs with.
Transaction lifecycle
Build, sign, submit and track transactions through to deterministic finality, with execution proofs and hash commitments returned for independent checks.
QVM precompiles
Call post quantum cryptographic operations exposed inside the QVM, so applications inherit protocol verified primitives without reimplementing them.
Bridge and asset access
Read and move assets across 36 blockchains and 78 assets held on the QVM, with near zero stablecoin fees on outward transfers.
Chain state and events
Query balances, accounts, blocks and contract state over REST, and subscribe to live execution events over WebSocket for monitoring and reconciliation.
From keypair to verified state change
The SDKs follow the same path the protocol enforces, so behaviour matches across every language and the API.
Create a keypair
The SDK generates a post quantum keypair using Falcon, Dilithium or SPHINCS+ on the integrator system.
Derive the address
The account address is the SHA3 256 hash of the public key, shown as a Q1 identity for display and reconciliation.
Construct the transaction
The library assembles the payload and execution context, then prepares the message for signing under protocol rules.
Sign on the device
The transaction is signed locally. The signature binds the payload, the execution context and the sender identity.
Submit to the network
The signed transaction is broadcast. The protocol verifies the post quantum signature before any state change is applied.
Confirm at finality
The SDK returns execution proofs and hash commitments, confirmed at deterministic finality in about three seconds.
No part of this path holds final cryptographic trust in the client. The SDKs construct and submit, while all verification occurs within the QVM during execution.
Quantum secure from first principles
The SDKs are not a post quantum wrapper over a quantum vulnerable base. Every primitive a client touches is post quantum by construction, and final trust always rests with the protocol rather than the library.
No quantum vulnerable signing
There is no elliptic curve path. Every signature is Falcon 512, Dilithium ML DSA or SPHINCS+ SLH DSA, so there is no fallback for an attacker to target.
Hash based identity
Addresses are the SHA3 256 hash of the post quantum public key, shown as Q1 identities. SHA3 256 is used for hashing throughout, with no quantum weak digest in the path.
Verification in the protocol
The client builds and submits; it never holds final trust. The QVM verifies every post quantum signature before any state change, identically on every node.
Secret keys stay local
Keypairs are generated and held by the integrator and signing happens on the device. The secret key never crosses the network edge in any package.
Protocol verified primitives
QVM precompiles expose post quantum operations to applications, so contracts inherit primitives the protocol verifies rather than reimplementing cryptography.
One contract, four packages
qweb3.js, qweb3.py, qweb3.rs and @quantova/api share the same post quantum contract, so behaviour is identical across every language and the API.
# Every primitive the SDKs touch is post quantum by construction signatures = [ Falcon 512, Dilithium ML DSA, SPHINCS+ SLH DSA ] hashing = SHA3 256 addresses = SHA3 256(public_key) to 20 bytes # Q1 Bech32m precompile = ML KEM # exposed inside the QVM signing = on device # secret key never leaves trust = QVM verifies before state change # not the client
The result is that every deployment on the Quantova Virtual Machine inherits post quantum security by default, not by application choice. A team does not configure quantum resistance or pick a fallback. The protocol enforces post quantum verification for every transaction the SDKs submit.
Built for banks, treasuries and supervisors
The SDKs place cryptographic trust inside the protocol rather than in client software. Verification is a QVM execution rule, applied identically on every node, so an integrating team relies on protocol behaviour rather than its own libraries. Execution is deterministic, which lets auditors and oversight bodies replay historical state and confirm authorisation without privileged access to node internals.
- ✓On device signing keeps secret keys within the institution at all times.
- ✓Post quantum signatures and SHA3 256 hashing across accounts, validator keys and finality.
- ✓Execution proofs and hash commitments support audit, reconciliation and supervisory review.
- ✓A capped transaction fee of about five cents, capped at ten cents keeps cost predictable at scale.
| Property | Detail |
|---|---|
| Signing | On device, secret keys never leave |
| Verification | Inside the QVM, before state execution |
| Finality | Deterministic, about 3 seconds |
| Transaction fee | About five cents, capped at ten cents |
| Execution | Deterministic and independently replayable |
Maintained by a dedicated research team
The libraries are extended and corrected by the Quanto Organisation research team in Singapore, formed of PhD graduates and certified specialists.
- ✓The team finds active bugs in IBM Qiskit and Google Cirq and publishes fixes live on GitHub.
- ✓The SDKs track NIST approved post quantum algorithms as standards advance.
- ✓Work is conducted alongside IBM, Google and Microsoft.
- ✓The QMask wallet at https://qmask.io is built on the same libraries, signing every transaction on the device.
Owned by Quantova Inc. Released under the Business Source License 1.1.
