QMask — Quantova Wallet

QMask is the native wallet of Quantova, the post-quantum Layer-1 blockchain. It is a browser extension that manages your quantum-resistant Quantova accounts and signs your transactions, and it injects a Quantova post-quantum signer into the page so any compatible dapp can request signatures from your accounts.

Quantova built quantum resistance into the wallet and signing layer. QMask is Quantova's own implementation: account creation, key management, and signing are post-quantum from the ground up, using the NIST post-quantum signature schemes Quantova supports — CRYSTALS-Dilithium, Falcon, and SPHINCS+ — and Quantova's QSignature authorization type. So that the existing dapp ecosystem works with Quantova out of the box, QMask implements the widely-adopted injected-signer interface; the post-quantum cryptography underneath is Quantova's own work.

As it stands, QMask manages accounts and signs transactions with those accounts. It exposes accounts and a post-quantum Signer to dapps through the injected interface.

Installation

• On Chrome, install via the Chrome Web Store.
• On Firefox, install via Firefox Add-ons.
• On Brave, install the Chrome extension build (Brave supports Chrome extensions).

Always install QMask from qmask.io or the official store listings it links to.

What you can do with QMask

• Create a quantum-resistant account. QMask generates a Quantova account secured by a post-quantum scheme; its canonical address begins with Q.
• Get test funds. Use your address to claim free TQTOV from the faucet at Qtox.io on the Quantova Testnet.
• Buy a name. Connect QMask at Qname.io to register a .qtov name, paid in QTOV.
• Sign transactions. Approve post-quantum-signed transfers, contract calls, governance votes, and naming operations — for the Quantova app UI or any dapp that uses the injected signer.

Documentation and examples

Guidance for using QMask as a dapp developer, a cookbook, and answers to common questions are available in the Quantova developer documentation. Runnable examples of signing and submitting Quantova transactions (in qweb3.js and qweb3.py) are in the Quantova examples repository.

Building from source

The build process is the same family of steps you may know from Substrate-ecosystem extensions:

1. Uncompress the source archive.
2. Run corepack enable.
3. Install dependencies via yarn install.
4. Build all packages via yarn build.

The /packages/extension/build directory will contain the exact code used in the add-on, and should match the published build.

Development build

Steps to build the extension and view your changes in a browser:

Chrome / Brave

1. Build via yarn build:chrome (you may need corepack enable first).
2. Go to chrome://extensions/, enable the Developer flag.
3. "Load unpacked" and point to packages/extension/build.
4. After making changes, refresh the extension.

Firefox

1. Build via yarn build:ff (you may need corepack enable first).
2. Go to about:debugging#addons, check "Enable add-on debugging".
3. Click "Load Temporary Add-on" and point to packages/extension/build/manifest.json.
4. After making changes, reload the extension.

When visiting the Quantova app UI, QMask will inject its accounts and signer. Once added, you can create an account from a generated post-quantum mnemonic, or import an existing one.

Project structure

The repository is split into a number of packages:

• extension — all injection and background processing logic (the main entry).
• extension-ui — the UI components for the extension popup.
• extension-dapp — a convenience wrapper to work with the injected objects, simplifying data extraction for any dapp that wishes to integrate QMask (or any wallet that supports the interface).
• extension-inject — a convenience wrapper that lets wallet developers inject their wallet for use by any dapp.

It also contains a manifest_chrome.json and a manifest_firefox.json for per-browser configuration, plus a manifest.json used by the build.

For dapp developers

A dapp does not need to handle post-quantum keys or signatures directly. Include the extension-dapp convenience wrapper and call the enabling function to retrieve the available wallets and their interfaces; QMask handles deriving the Quantova address and producing the post-quantum signature when the user approves.

The injection interface is generic: it lets any wallet that conforms to the interface inject itself, and lets any dapp enable the interfaces from multiple wallets at once. It is not all-or-nothing — the user chooses which wallet to use.

API interface

When enabled, a compliant wallet exposes the following to the dapp:

interface Injected {
  // the interface for Accounts, detailed below
  readonly accounts: Accounts;
  // the standard Signer interface used by the Quantova client libraries
  readonly signer: Signer;
  // (optional, not injected yet) a subscribable provider for client injection
  // readonly provider?: Provider;
}

interface Account {
  // canonical Quantova address (begins with 'Q')
  readonly address: string;
  // the genesisHash of the network this account applies to (empty if any)
  readonly genesisHash?: string;
  // (optional) display name
  readonly name?: string;
}

// exposes accounts
interface Accounts {
  // retrieve the current list of accounts
  get: () => Promise<Account[]>;
  // (optional) subscribe to account changes
  subscribe?: (cb: (accounts: Account[]) => unknown) => () => void;
}

// a post-quantum signer that communicates with the wallet via messages
interface Signer extends SignerInterface {
  // exposes the standard `sign` interface; signatures are post-quantum
  // (Dilithium / Falcon / SPHINCS+), verified on-chain as a QSignature
}

Injection information

The information in this section may evolve, so it is recommended to access the wallet through the extension-dapp (for dapps) and extension-inject (for wallets) wrappers rather than the low-level globals.

The extension injects an injectedWeb3 object into the page, exposing each installed wallet by key:

window.injectedWeb3 = {
  // the key for this wallet; multiple wallets may be injected, each with its key
  'qmask': {
    // semver of the wallet
    version: '0.1.0',

    // called to enable injection; resolves to an Injected object with the
    // accounts and post-quantum signer (or rejects if not authorized)
    enable(originName: string): Promise<Injected>
  }
}

Mnemonics, passwords, and imports/exports

Using the mnemonic and password

When you create a keypair, QMask supplies a recovery mnemonic and asks you to set a password. The password encrypts the post-quantum private key on disk, so it is required to sign transactions or to import the account from backup. The password does not protect the mnemonic phrase itself: anyone who obtains the mnemonic can restore the account without the password. Back up your mnemonic offline and never share it.

Choosing a signature scheme

Quantova accounts are post-quantum; there is no classical-key option. Where QMask offers a choice, any of Dilithium, Falcon, or SPHINCS+ is valid — all three derive into the same Quantova address space, and Dilithium is a balanced default.

Importing and deriving accounts

QMask supports importing an account from a mnemonic, and deriving child accounts from an existing account. When deriving, you provide the parent account's password along with the name and password for the derived account, and a derivation path. As with creation, the password you set encrypts the private key on disk and need not match any other password.

License

QMask is licensed under the Business Source License 1.1 (BUSL-1.1), © 2026 Quantova Inc. See LICENSE and LICENSE-OVERVIEW.md. This license governs QMask — Quantova's wallet, its key management, and its post-quantum signing implementation.

The injected-signer interface that QMask implements for dapp interoperability follows the conventions established by the polkadot-js extension, which is available under the Apache-2.0 license. That permissive license applies to that upstream project; QMask's own implementation and its post-quantum cryptography are Quantova's work and are licensed under BUSL-1.1 as above. Where any upstream Apache-2.0 material is referenced, its required attribution and license notice are retained.