A portal into the Quantova network. Quantova Apps is a browser-based view and interaction layer for the post-quantum Layer 1 — block explorer, account management, transaction signing, staking, governance, and direct RPC access — running against any Quantova node.
This repository is Quantova's adaptation of the Polkadot/Substrate apps portal. Quantova is built on the Substrate framework, so the portal gives the network a mature, battle-tested interface; Quantova's work in this repo is to make that interface post-quantum end to end and wire it to the Quantova network. See What Quantova does with this repo and Post-quantum features.
The portal can be run locally (see Development) or accessed at the
Quantova-hosted instance linked from https://quantova.org. To connect to the public testnet, point
it at wss://testnet.quantova.io.
Chain developers / integrators: local configuration (API types, settings, logos, endpoints) lives in the apps-config package, with instructions for what goes where.
Quantova uses this portal as the network's primary browser interface. The upstream portal is a generic Substrate UI; Quantova's contribution in this repository is to:
- Bind it to the Quantova network — the apps-config
package carries Quantova's endpoints (testnet
wss://testnet.quantova.io), chain metadata, type definitions for Quantova's on-chain structures, branding, and default settings. - Make the account and signing layer post-quantum — accounts, keys, and the signing flow use Quantova's NIST post-quantum schemes rather than the classical elliptic-curve schemes the upstream portal assumes (detailed below).
- Expose Quantova's consensus and economics — the explorer reflects deterministic, no-VRF block authorship and deterministic finality; the staking and governance views work against Quantova's Nominated Proof-of-Stake and on-chain governance.
- Talk to nodes over the Quantova RPC surface — the portal communicates with nodes over the
q_JSON-RPC namespace (reads, transactions) and the restrictedauthor_namespace (validator session-key operations).
The result is a single place where a user can explore the chain, hold post-quantum accounts, sign and submit transactions, stake, and participate in governance — without running anything beyond a browser (or the desktop app).
This is where Quantova's adaptation matters. A standard Substrate portal builds accounts and signs extrinsics with classical cryptography (sr25519 / ed25519 / ECDSA). On Quantova there is no elliptic-curve trust model, so the portal is adapted at every point that touches keys or signatures:
- Post-quantum accounts. Account creation uses Quantova's NIST schemes — CRYSTALS-Dilithium (ML-DSA), Falcon (FN-DSA), and SPHINCS+ (SLH-DSA). The scheme is chosen per account and is encoded in the account's address variant.
- Q-format addresses. Accounts are displayed and entered as Q-format addresses
(Q-prefixed), not 20-byte
0xEVM addresses. Hashes, where shown, are0xhex — a hash is raw bytes, not an account. - Post-quantum signing. Every transaction signed in the portal is authorized with the
account's post-quantum key. On-chain, signatures are verified through Quantova's post-quantum
precompiles (Falcon / Dilithium / SPHINCS+) — there is no
ecrecover/secp256k1 path. - Validator session keys. The portal exposes session-key rotation (
author_rotateKeys) and registration, so a validator's authority keys — which are Falcon at the finality layer — can be managed from the UI. Session keys are kept distinct from funded accounts. - Staking against NPoS. Bonding,
validate, andnominateoperate against Quantova's Nominated Proof-of-Stake. Validator and nominator flows mirror the become-a-validator guide. - Consensus-aware explorer. Block views reflect Quantova's deterministic, no-VRF slot leadership and deterministic finality (~3s); there is no VRF/randomized-eligibility surface to display because the chain has none.
- Governance. The governance views support Quantova's on-chain governance, which drives forkless runtime upgrades — including, over time, advancing cryptographic parameters.
For the protocol-level detail behind these, see the developer documentation and the consensus-specs repository.
The repo is split into a number of packages, each representing an application (account management, explorer, staking, governance, developer/RPC tools, and so on), plus the shared apps-config package that holds all Quantova-specific configuration.
Contributions are welcome.
This repo uses yarn workspaces to organize the code. After cloning, install dependencies via
yarn, not npm — npm will produce broken dependencies.
- Clone the repo:
git clone https://github.com/Quantova/apps <optional local path> - Use a recent LTS Node.js (Node >= 18 recommended).
- Use a recent Yarn (Yarn >= 1.22).
- Install dependencies:
yarn install --frozen-lockfile - Launch the UI (assuming a Quantova node is reachable):
yarn run start - Open the UI at http://localhost:3000
By default the UI connects to the endpoint configured in
apps-config; set it to a local
node (ws://127.0.0.1:9944) or the testnet (wss://testnet.quantova.io).
Build and run a container with local changes:
docker build -t quantova/apps -f docker/Dockerfile .
docker run --rm -it --name quantova-apps -e WS_URL=wss://testnet.quantova.io -p 80:80 quantova/apps
Then access the UI at http://localhost. Set WS_URL to whichever Quantova
node you want the portal to connect to.
IPFS allows sharing files in a decentralized manner, similar to how the network exchanges blocks. IPFS works best when many nodes seed the same data; nodes seed specific data by pinning it. Pinning the Quantova Apps UI (which only changes on releases) makes it faster for you and others.
Pin the published build by its CID (the current CID is published with each release; replace
<CID> below):
ipfs pin add --progress <CID>
You can automate pinning with a cron task. Save a script such as
/usr/local/bin/quantova-apps-ipfs-pin.sh:
#!/usr/bin/env bash
IPFS='/usr/local/bin/ipfs'
$IPFS pin add --progress <CID>
Then run crontab -e and add:
SHELL=/bin/bash
HOME=/
0 * * * * /usr/local/bin/quantova-apps-ipfs-pin.sh >/dev/null 2>&1
Confirm a CID is pinned with ipfs pin ls | grep <CID>, inspect contents with ipfs ls <CID>,
and see how many peers seed it with ipfs dht findprovs <CID> | wc -l.
The main advantage of the desktop app is that it stores encrypted accounts on the filesystem instead of in the browser's local storage. Local storage is susceptible to XSS (Cross-Site Scripting) attacks; files stored on disk are not exposed to that risk — which matters all the more when those accounts hold post-quantum keys.
The desktop app uses the Electron framework and provides the same features as the web app; the only difference is account storage. Accounts are stored in:
- macOS:
~/Library/Application Support/quantova-apps/quantova-accounts - Linux:
~/.config/quantova-apps/quantova-accounts(or$XDG_CONFIG_HOME/quantova-apps/quantova-accountsif set) - Windows:
%APPDATA%\quantova-apps\quantova-accounts
This project is a fork of the Polkadot-JS apps portal and combines two licenses:
- Upstream (Polkadot-JS / Parity). The original polkadot-js/apps code is licensed under the Apache License, Version 2.0, © Parity Technologies and the Polkadot-JS authors. Those files retain their original Apache-2.0 license and copyright headers; this fork does not relicense upstream code. Full text: https://www.apache.org/licenses/LICENSE-2.0
- Quantova additions. Quantova-specific code, configuration, branding, and post-quantum integration in this repository are © 2026 Quantova Inc and licensed under the Business Source License 1.1 (BUSL-1.1), except where a file carries an upstream Apache-2.0 header, which governs that file.
In short: the Polkadot-JS foundation remains Apache-2.0; Quantova's modifications are BUSL-1.1. Where the two would conflict for a given file, the license header in that file applies.
"Quantova", "QVM", "QRC20", "QNS", and "QTOV" are trademarks or technology identifiers of Quantova Inc. © 2026 Quantova Inc.