Skip to content

Quantova/apps

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14,186 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Quantova Apps

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.


What Quantova does with this repo

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 restricted author_ 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).


Post-quantum features

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 0x EVM addresses. Hashes, where shown, are 0x hex — 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, and nominate operate 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.


Overview

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.

Development

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.

  1. Clone the repo: git clone https://github.com/Quantova/apps <optional local path>
  2. Use a recent LTS Node.js (Node >= 18 recommended).
  3. Use a recent Yarn (Yarn >= 1.22).
  4. Install dependencies: yarn install --frozen-lockfile
  5. Launch the UI (assuming a Quantova node is reachable): yarn run start
  6. 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).

Docker

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

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.

Desktop App

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-accounts if set)
  • Windows: %APPDATA%\quantova-apps\quantova-accounts

License

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.

About

A browser portal into the Quantova network — explorer, accounts, signing, staking, and governance — adapted from the Polkadot-JS apps portal and made post-quantum end to end. Connects to any Quantova node over the q_ JSON-RPC API.

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages

  • TypeScript 99.9%
  • Other 0.1%