Qanovra is an independent blockchain network developed in Germany — built for value intended to last for decades. Every version is independently reviewed, sealed and published with recomputable checksums. Decisions rest on evidence, not on promises.
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.
Four properties that matter once real assets are involved — for individuals and businesses alike.
There is no office that can freeze your balance or hold back a transfer. You hold the key — and with it the responsibility.
If a state is unclear the software stops the operation rather than making an assumption. A transfer that is not executed can be repeated — a wrong one cannot.
Holding or passing on value across long periods requires a system that remains verifiable and unchanged after decades. The base layer is designed for that.
Every published file carries a checksum that can be recomputed locally. Our statements can be checked independently.
No mockups, no drafts: real captures of the running wallet v0.30.17 from the audit environment. The interface states its status at every step — testnet, no monetary value, public value transfer remains NO_GO.
Captured from the running browser extension in the Chrome-for-Testing audit environment, state v0.30.17 from the frozen audit surface; the image files carry SHA-256 checksums in the source package. Before sending, the wallet confirms four checks — two independent nodes, recipient status, daily limit, cryptographically confirmed balance — and only then releases via passkey. 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.
Install the SDK, set the endpoint, make the first call. Everything else is in the 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 derives from the genesis hash: “qnv-” plus its first 24 hex characters. 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.
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 weakness should be able to report it — confidentially and without risk.
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.
For questions about the technology, an independent review or operating a validator, you can reach us directly by email.