The Layer-1 for verifiable digital action. Any blockchain lets you verify transactions; Qanovra goes further: the software itself, every document and every step towards launch is sealed individually and can be recomputed — and when in doubt, the system prefers not to execute. Built in Germany, as a foundation for wealth meant to outlast generations.
Four questions, four short answers — understandable without any background. The switch at the top right takes you to the technical wording at any time.
A register kept on many computers at the same time. Every new entry is cross-checked by all participants and linked to the previous one. A later change would be noticed immediately, because it would contradict every other copy.
Our own blockchain. Not built on top of someone else's, but written from scratch — and reviewed from the outside, piece by piece, before anything counts as finished.
The unit this chain counts in. Transferring value means transferring QNV. Think of a balance in your account, without a bank in the middle.
Not yet. The software is finished and reviewed, but the network is not running. Exactly what is still missing is listed openly further down — including the things holding us up.
Technology is a means. In the end it comes down to four situations everyone knows.
No account that gets frozen. No transfer someone holds back. No provider changing the rules overnight. What belongs to you, you control yourself — with the responsibility that comes with it.
Everyone knows the fear of the wrong click. So the system checks before anything is executed — and if something is not unambiguous, nothing happens. A stopped transfer can be repeated. A wrong one cannot.
Digital assets are lost far too often when their owner dies — families left facing accounts no one can reach. Qanovra is built as a foundation on which a digital estate can be passed on in an orderly way. heritari, the first application for it, is in development.
You do not have to believe us: every version, every figure, every document carries a checksum you can recompute yourself. Those who want to, verify. Those who do not, know that others do.
No mockups, no drafts: real captures of the running wallet v0.30.17 from the audit environment. The interface states its own status — testnet, no monetary value.
Captured from the running browser extension in the Chrome-for-Testing audit environment, state v0.30.18 — the German/English localisation of the audited v0.30.17 baseline; its own review cycle is in progress. The image files carry SHA-256 checksums in the source package. The phone views are byte-identical to the checksummed originals in the source package; the desktop view is merely scaled to web width. Before sending, the wallet confirms four checks — two independent nodes, recipient status, daily limit, cryptographically confirmed balance — and only then releases via passkey. Public value transfer is deliberately not yet enabled; the steps still open are listed in the gate status below. Views of the heritari inheritance product will follow once its rebinding to v3.7.5 is complete.
The same input always gives the same result — on any machine, at any time. Nothing depends on chance.
If something is unclear, nothing happens rather than the wrong thing. In doubt we stop, we don't pay out.
We claim nothing you cannot recompute yourself. Every version ships with the evidence.
Every version gets a fingerprint and is never touched again. Whatever builds on it knows exactly what it stands on.
Each layer is a separately audited state with its own version line. Select one to see the detail.
Decides what happens to digital assets when someone can no longer act — traceably, and without a single person deciding alone.
The app where you see your balance and approve transfers — like online banking, without a bank in between.
A toolbox for developers who want to connect their own software to the chain.
The machinery around the chain that keeps the network running and keeps proving it works correctly.
The foundation: the chain itself. It stores the entries and makes sure everyone sees the same truth.
QNV is the native unit of account of the network. The full supply of 10 billion QNV exists from the first block — nothing is created or “minted” afterwards. All figures come from whitepaper and yellow paper v2.4.2 for the frozen v3.7.5 baseline.
Genesis allocation: 51.75% community and network security, 15.00% treasury and ecosystem, 15.00% founder, 8.00% core team, 0.25% ambassador programme, 10.00% remaining canonical allocations. Disclosed openly: the founder allocation is available from genesis by design and is not protocol-locked or vested — the whitepaper states the resulting concentration and liquidity risk explicitly. For core team grants the launch policy provides 48 months with a 12-month cliff and monthly linear release thereafter; this may only be represented as technically enforced once canonical vault evidence exists. Effective reward is funding-bounded and may fall below target. No yield is guaranteed. Slashing applies to a validator's entire bonded stake including delegations — choosing a validator is therefore a security decision, not merely a yield decision.
Qanovra is assembling its initial independent validator cohort across Europe, North America, South America, Asia and Africa. Five slots, organisationally independent operators, admission on evidence rather than intent.
The admission process is fail-closed: a slot stays open until the operator, the host and the key custody are evidenced. Complete evidence takes precedence over a fast start.
No shared ownership, staff or infrastructure with Qanovra or with another cohort operator.
Validator signing keys in an audited HSM, KMS or Vault. Non-exporting custody, evidenced.
Documented host with declared region, provider and isolation. Shared consumer hosting does not qualify.
The operating entity is named publicly. Anonymous operators cannot be part of a founding cohort.
You receive the operator package: runbooks, device matrix, build verification and the declaration template.
You declare entity, region, host, provider and intended key custody. Nothing is assumed on your behalf.
Both sides review independence, jurisdiction and operational fit. Either side may stop here without cost.
HSM, host and operator evidence is produced and bound to SHA-256 checksums.
The gate opens only when the evidence is complete. Incomplete evidence keeps the slot closed.
No compensation, listing or return is promised here. Staking and slashing policy is documented in the whitepaper; the exact unbonding duration is still to be taken from the frozen configuration.
Developers, operators and auditors have a dedicated handbook: the Qanovra Developer Documentation v1.1 — task-oriented from Learn through Build and Run to Verify, every value evidence-bound, every code block labelled TESTED, ILLUSTRATIVE or PSEUDOCODE. The normative specification remains the yellow paper v2.4.2 under “Documentation”.
# Qanovra SDK · Python pip install qanovra-sdk >>> from qanovra import Client >>> c = Client("https://rpc.qanovra.example") >>> c.status().height 148902
Today's signature schemes rest on problems ordinary computers cannot solve. Powerful quantum computers could solve exactly those problems. Anyone holding value for decades has to plan for that before the chain launches — not afterwards.
That is why this section exists. It describes an intention, not a property of the frozen v3.7.5 baseline. Schemes, timetable and review are still outstanding.
No post-quantum security is claimed for v3.7.5 — the baseline is “migration-prepared”. A later move to successor schemes such as ML-DSA or SLH-DSA requires a versioned protocol upgrade, new conformance vectors, orderly rotation of validator and system keys, and an authenticated rebinding path for user accounts.
A digital fingerprint was taken of the finished base and published. Anyone can recompute whether the software in front of them is exactly this one — change a single character and the fingerprint no longer matches.
Candidate archive v3.7.5 · SHA-256The chain ID is bound to the genesis identity; both values are pinned and compared as independent trust anchors. A node must not accept a chain ID configured otherwise.
Each component is reviewed on its own — with explicitly positive and negative findings, concrete improvements and a remediation package for the next round.
The chain itself — the part that stores the entries and keeps everyone on the same state.
Everything that keeps operations safe: tools, checks and evidence so the network runs reliably.
The app for everyday use: check your balance and approve transfers.
The first finished application: a digital estate solution that passes assets to the right people when the time comes.
Traditional blockchains prove that a transaction happened. Qanovra is being built to prove more: Who acted? Were they authorized? Were the limits respected? What evidence exists afterward? And ultimately: can you prove it?
Equal voices. Verifiable trust. Deterministic finality.
Under EquiQuorum, admitted validators vote with equal weight; a block is final once more than two thirds of the validator set confirm it. The operator’s economic stake secures participation and is liable under slashing — it does not buy additional consensus votes.
Stake secures participation. It does not buy votes.
heritari makes sure digital assets reach the right people when you no longer can. You check in briefly at regular intervals. If the check-in stops, the trustees you named review the situation and release the handover.
Signing and broadcast stay fail-closed: if a state remains unclear, nothing is paid out. heritari attaches to the sealed v3.6.9 state and deliberately introduces no tradable token of its own.
Every state passes the same four steps. Nothing is sealed until all findings are closed.
tools/release_gate.py checks the state automatically. If the gate breaks, there is no package.
An external review returns findings with explicitly positive and negative aspects, plus concrete improvements.
Handoff file, remediation report, tools/remediation_gate.py and the previous audit under external-audits/.
Evidence package, SHA256SUMS, self-check and parity_probe. From then on the digest is the reference.
Security here is a process, not a state. Anyone who finds a vulnerability should be able to report it — confidentially, without risk, and with a dependable response.
Please: no denial-of-service attempts, no social engineering against staff or service providers, and no testing against third-party systems. While no public network is running, reports mainly concern the published artefacts: software, documents, checksums and this website.
Developers, operators and auditors have a dedicated handbook: the Qanovra Developer Documentation v1.1 — task-oriented from Learn through Build and Run to Verify, every value evidence-bound, every code block labelled TESTED, ILLUSTRATIVE or PSEUDOCODE. The normative specification remains the yellow paper v2.4.2 under “Documentation”.
Read the developer documentation (PDF) All documents with checksums
81ff22c2…2fa1a3, under “Documentation”.CHAIN_ID qnv-78cefe355c7fb55c53dd173c GENESIS 78cefe355c7fb55c53dd173c9ca9d340306054a7fd5718e70d1d3193be7b93a3 L1_v3.7.5 1c41b8e5e7f757de2a79937ab5e408021718a456e2eb29f9b1c596a6ccab2414
curl -fsSLO https://qanovra.org/papers/SHA256SUMS.txt curl -fsSLO https://qanovra.org/papers/Qanovra_Yellow_Paper_v2.4.2_Technical_Specification_Layout_Final_Candidate_2026-08-23.pdf sha256sum -c SHA256SUMS.txt --ignore-missing
The searchable web edition is being built at docs.qanovra.org, generated from Developer Documentation v1.1, the canonical registry and the OpenAPI description — without creating a second source of truth. This section lists only what exists today.
Whitepaper and yellow paper in revision v2.4.2 of 23 August 2026 — the final, frozen publication revision. Every file carries its SHA-256 checksum from the freeze manifest and can be verified locally before reading.
The strategic and institutional description: network identity, ledger and supply integrity, QNV tokenomics with the full genesis allocation and funding horizon, staking and slashing policy, security architecture, governance, readiness and risks.
The technical specification in 33 sections: state model, transaction and block semantics, consensus quorum, validator reconfiguration, monetary accounting, privileged operations, replay protection, threat model and conformance requirements.
The operator briefing for the program: requirements, the five-step admission, what operators receive, economics and risk in brief, current gate status and how to apply — two pages.
The record of the publication freeze: canonical hashes of all four document files, the lineage of the revision, and the rule that from now on not a single byte changes.
Checksums for every published document, so each file can be verified locally.
Results of the independent review, once the external security gate is complete.
How the inheritance solution works. heritari v1.1 remains bound to L1 v3.6.9; a repin review against v3.7.5 is outstanding.
Legal classification and law-firm documents.
Both papers are available as PDF and DOCX — byte-identical to the canonical hashes in the freeze receipt of 23 August 2026. After this freeze not a single byte of the documents changes; any future change receives a new revision with new checksums.
No date promises — five phases as set out in white paper v2.1. A phase counts as complete only once its evidence exists.
v3.7.5 stays free of silent drift in consensus, genesis, tokenomics or runtime.
Independent L1 attestation, the real key ceremony, independent validators, a geographic recovery rehearsal and the security and legal gates.
Controlled external participation, operational qualification and integration evidence.
Governed go/no-go based on technical and real-world evidence.
Grow integrations, applications and tooling without bypassing the change discipline.
The same board we work from internally. A gate counts as closed only when its evidence exists — a passing test is not a closed real-world gate.
Frozen baseline, candidate archive checksum published.
Frozen line, evidence closure audit.
Software freeze, no open software remediation item.
Closed.
Executed and closed.
Dry run passed with 4 of 7 signatures, observer attestation and negative controls. The production ceremony and genesis seal are still outstanding.
Revalidation required against the current source tree; the earlier cross-platform pass does not carry over automatically.
Five operator packages prepared, zero operators admitted. Gate blocked on real infrastructure.
Ceremony KMS keys must not be relabelled as production HSM evidence.
Real region loss and measured restore still to be executed.
Scheduled after real validators are in place.
Final external sign-off outstanding.
Regulatory review for the intended launch context outstanding.
The readiness matrix in white paper v2.1 records for each area where it stands today and what is missing before broader activation: L1 attestation against the exact candidate, verification that the launch artefact matches the canonical hash and chain ID, wallet and browser qualification in a real environment, production deployment of explorer, RPC and SDK, the real 4-of-7 ceremony with observer evidence, independent validator operators, a genuinely geographic recovery rehearsal, the external security gate and the legal review.
No. The current audited state is v3.7.5 and the testnet is in preparation. The roadmap shows where things stand.
Qanovra UG (haftungsbeschränkt) i. G., based in Germany: formation initiated on 13 August 2026 and notarised on 21 August 2026. Until registration in the commercial register the project trades explicitly as a company in formation.
No. There is no sale and no presale. Anyone offering you QNV is not acting on our behalf.
Nothing is “minted” on Qanovra: all 10 billion QNV exist in full from the first block, distributed across the defined genesis allocations. The real long-term question is therefore: what pays staking rewards once the community allocation reserved for them is spent? The whitepaper states this openly: if the 5.175 billion QNV allocation were used solely for the reward curve, it would last roughly 9.4 years at 55% staking participation, roughly 10.4 years at 62.5% and roughly 12.3 years at 70%. After that, rewards are paid exclusively from fee revenue or other already-funded, explicitly authorised sources. Creating new QNV as a fallback is ruled out — if funding declines, the effective reward declines, not the reliability of the total supply.
Because what an inheritance solution needs — very long horizons, fail-closed behaviour, replaceable cryptography — reaches all the way into the base. You cannot retrofit those properties onto someone else's chain.
An independent external review before every release. We summarise the results and publish them under “Papers”.
That the cryptography is built to be replaced and a migration path exists — not that every scheme has already been switched. The post-quantum paper has the detail.
As a developer through the SDK and docs, as an auditor through an audit enquiry, or as an early user through the invite testnet.
Almost. Yellow paper v2.1 fixes the semantic rules and twenty security invariants normatively. Twelve byte-exact details — transaction schema, state-root construction, fee formula, unbonding duration and others — are explicitly marked as “to be copied from the code” rather than invented. Only after that can anyone build a byte-compatible independent client.
It will need identity. Authority. Limits. Recovery. Evidence. Trust that can be verified. How Qanovra is laying that foundation — for humans, organizations and autonomous machines — is described in the vision. The audited present state is shown in the gate status.
For questions about the technology, an independent review or operating a validator, you can reach us directly by email.