The post-quantum client library for the Quantova network.
@quantova/api is the high-level JavaScript/TypeScript library for talking to a
Quantova node. It provides a clean, promise-based wrapper around the chain's RPC,
fully typed access to runtime state and storage, live subscriptions, and the
tooling to build, sign, and submit Quantova transactions — including
transactions authorised by post-quantum keys.
It is the layer applications, the Qmask.io wallet, and the Qdock.io IDE use to
read the chain and send transactions. For the underlying cryptography — the
post-quantum key pairs and the signature envelope — it builds on its companion
library, @quantova/common
(@quantova/keyring, @quantova/util, @quantova/util-crypto).
For full interface documentation, visit the documentation portal. Existing users should track the CHANGELOG when changing versions.
Quantova authenticates every transaction with a NIST post-quantum signature (CRYSTALS-Dilithium, Falcon, or SPHINCS+) and hashes with SHA3-256 throughout the protocol. This library makes the standard query/submit workflow post-quantum aware so that a transaction signed in JavaScript verifies on the Quantova runtime without any extra steps.
The integration is concentrated in the extrinsic (transaction) layer:
- SHA3-256 signing payloads. When a transaction is signed by a Quantova post-quantum account, the signing payload is hashed with SHA3-256 rather than the default Blake2 used by the upstream library. This matches the hash the Quantova runtime uses to verify the signature.
- Quantova signature envelope (
QSignature) awareness. The extrinsic layer detects Quantova's signature types in the type registry (quantova_account::QSignature/QSignature, and the Falcon scheme) and produces a scheme-tagged signature, so each signature carries the identifier the runtime needs to verify it. - Built on
@quantova/common. The actual key pairs (Dilithium / Falcon / SPHINCS+),Q-address derivation, and theqsignatureenvelope come from@quantova/keyringand@quantova/util-crypto;@quantova/apiorchestrates them into the construct → sign → submit flow.
Outside the post-quantum signing path, the API behaves like the well-known upstream client: the same query interface, derives, RPC wrapper, contract API, and type system.
Quantova has added and maintains the following in this repository.
The extrinsic signing helper chooses the correct payload hash based on the account and registry:
sign(...)hashes the payload with SHA3-256 for Quantova post-quantum accounts and falls back to Blake2 for non-Quantova accounts — preserving upstream behaviour for everything else.- A registry check (
isQuantovaSignature) recognises thequantova_account::QSignature/QSignaturetypes and the Falcon scheme. ExtrinsicPayloadenables scheme-tagged (“with type”) signing whenever the signature type is an enum or a Quantova/Falcon signature, so the submitted signature is self-describing for the runtime.
By consuming @quantova/keyring and @quantova/util-crypto, the API works with
Dilithium, Falcon, and SPHINCS+ accounts directly — deriving canonical
Q-addresses and signing with the chosen scheme through the normal
signAndSend / signer interfaces.
The test keyring and mock provider support post-quantum (e.g. Falcon) accounts, so integrations and the API’s own test-suite exercise the real Quantova signing path.
The types, RPC, derive, and contract packages are kept current so that Quantova’s runtime types and the chain’s RPC are fully and correctly described to clients.
Connect to a Quantova node and read state — the same code works against mainnet, testnet, or a local development node by changing only the endpoint:
import { ApiPromise, WsProvider } from '@quantova/api';
// Mainnet: wss://mainnet.quantova.io · Testnet: wss://testnet.quantova.io
const api = await ApiPromise.create({
provider: new WsProvider('wss://mainnet.quantova.io')
});
// Read an account balance
const { data } = await api.query.system.account(
'Q0b22901ba019b7f48327a891d21a9af2547493'
);
console.log(data.free.toString());Signing and submitting a transaction uses the standard signAndSend flow with a
post-quantum keyring pair from @quantova/keyring.
The repository is organised as a set of internal packages (yarn workspaces). The
post-quantum signing changes live primarily in types (the extrinsic layer);
the remaining packages provide the full client surface:
api— the mainApiPromise/ApiRxclient.api-base,api-derive— core API machinery and higher-level derived queries.api-augment— runtime/RPC type augmentation.api-contract— the contract (QVM) interaction API.rpc-core,rpc-provider,rpc-augment— RPC layer and providers (WebSocket/HTTP).types,types-codec,types-create,types-known,types-augment,types-support— the SCALE type system, including the post-quantum extrinsic signing logic.typegen— type generation from chain metadata.
This repo uses yarn workspaces, so after cloning, install dependencies with
yarn — not npm (npm will produce broken workspace dependencies).
Requirements:
- A recent Node.js (this project targets
>= 18.14). - A recent Yarn (Berry, v4+).
# 1. Clone
git clone https://github.com/Quantova/api.git
cd api
# 2. Install dependencies (yarn, not npm)
yarn
# 3. Build all packages
yarn buildAdditional scripts (lint, test, and others) are defined in
package.json.
Licensed under the Apache License, Version 2.0. See LICENSE for
the full text. Quantova's post-quantum additions and modifications are
© 2026 Quantova Inc, provided under the same license.
This project builds on @polkadot/api © Parity Technologies and the polkadot-js
authors, used under Apache-2.0; the original copyright and license notices are
retained, and we thank its maintainers for the foundational client library this
work extends. "Polkadot", "polkadot-js", and "Substrate" are the property of
their respective owners and are referenced here for attribution only.
Quantova™, QTOV™, QVM™, Qmask.io™, and Qdock.io™ are trademarks of Quantova Inc.
© 2026 Quantova Inc