QNERO: A Post-Quantum Privacy Chain for Adversarial Times

Version: 1.1-draft (research/testnet focus) Authors: QNERO Core Contributors Date: 2026-04-03

Abstract

Bitcoin showed that money can exist without a central issuer. Monero showed that privacy can be the default, not an add-on. QNERO starts from a different pressure point: the long-horizon risk that cryptographic assumptions used by modern blockchains may degrade under post-quantum advances, while surveillance pressure and metadata analysis continue to intensify.

QNERO is an attempt to engineer a privacy-preserving chain with explicit post-quantum direction, strict canonical transaction validation, and an operationally honest scope. The current implementation is intentionally narrowed to a restricted testnet profile with one live confidential amount backend (final_v1) and one canonical statement/proof family. This is not a finished production anonymity system. It is a serious, verifiable step toward one.

The purpose of this paper is twofold:

1. Explain why QNERO should exist at all.
2. Explain, in technical but honest terms, what QNERO currently is and what it is not.

1. Why This Chain Exists

A chain should not exist because “another token” sounds fun. A chain should exist because existing systems leave a structural gap.

QNERO is motivated by that gap.

1.1 The strategic gap

The modern blockchain stack has three unresolved tensions:

• Tension A: Durability vs cryptographic transition speed

Most chains rely on assumptions with uncertain long-term post-quantum durability for signatures and/or privacy constructions.

• Tension B: Transparency vs personal security

Transparent chains maximize auditability but often leak user behavior, balances, and social graphs by default.

• Tension C: Protocol ambition vs engineering discipline

New systems often claim broad guarantees before they have narrow, coherent, adversarially tested implementations.

QNERO exists to address these tensions with a single stance: narrow the live surface area, then harden it aggressively.

1.2 Threats that matter

QNERO is designed under the assumption that adversaries include:

• chain analytics operators with large historical datasets,
• active mempool and network observers,
• targeted deanonymization actors,
• future-capable cryptanalytic actors with stronger computational models,
• implementation attackers exploiting inconsistencies between wallet, mempool, and consensus.

The design is therefore not just cryptographic; it is also about reducing protocol ambiguity.

1.3 A Bitcoin-style first principle

Bitcoin’s core insight was not “number go up.” It was protocol minimalism around a crucial primitive. QNERO takes that spirit into a different domain:

A privacy chain should prefer one strict, auditable, canonical live path over many optional weakly-compatible paths.

This is why QNERO currently enforces a single live amount-proof route in restricted testnet mode.

2. Design Philosophy

QNERO adopts four practical principles.

2.1 Single-live-path discipline

If multiple proof families are simultaneously accepted, audit complexity explodes and downgrade vectors appear. QNERO’s current answer is simple: one live amount-proof backend (final_v1), one statement id, one proof version.

2.2 Canonicality over permissiveness

Protocol ambiguity is an attack surface. Canonical serialization, strict parser expectations, and policy gates reduce malleability and cross-component drift.

2.3 Context-bound proofs

A proof is only meaningful if it is tied to its exact transaction context: network domain, context hash, ordered commitments, output index, and fee commitment semantics.

2.4 Honesty in claims

A chain cannot claim what its code does not enforce. QNERO explicitly states that the current milestone is restricted testnet + research hardening.

3. QNERO Identity and Network Foundations

QNERO is a fresh chain identity (qnero), with dedicated binaries and frozen network parameters.

• Core binaries: qnerod, qnero-wallet-cli, qnero-wallet-rpc
• Mainnet genesis hash: 024428eebb0dc572759a10c20d8af550b5911c48650c9ed0279561c82756a291
• Testnet genesis hash: 7a286bb9a1fda711bab0edf5b83f4761edcc66c069e61131616a667ba4268723
• Stagenet genesis hash: e649a51869254d27cbffeff0e0097d555b8e3a8c1b75d0c3b34a70d38c620695

The choice of fresh chain identity is not cosmetic; it prevents accidental inheritance of assumptions and policy expectations from unrelated networks.

4. System Model

At a high level, QNERO maintains:

• private recipient metadata and one-time output ownership mechanisms,
• commitment-based amount accounting,
• strict per-output proof validation against a context-bound statement,
• transaction-level commitment balance checks in consensus paths.

Current live amount backend identity:

• backend id: qnero.pq.amount.final-v1
• statement id: qnero.pq.amount.balance.v4
• proof version: 4

This is an explicit “one door in” policy.

4.1 Core cryptographic components currently used

QNERO currently combines several cryptographic component classes in its active code paths:

• KEM for output transport/recovery: ML-KEM/Kyber-style public-key encapsulation for recipient-side shared-secret recovery (m_pq_kem_public_key, kem_ciphertext flow).
• Ring signature backend path: scheme2 wrapper with Falafl-backed sign/verify interfaces in active PQ ring code paths.
• Commitment and amount-proof path: final_v1 context-bound balance payload verifier stack.
• Linkability artifacts: link tags / key-image-like structures used in PQ ring spend semantics.

This means QNERO is not “one primitive only”; it is a composed system where transport, ownership tagging, spend authorization, and amount consistency are separate but coupled layers.

4.2 Data model objects on-chain for PQ outputs

QNERO PQ outputs carry a richer object than classical transparent UTXO fields. In practical terms, a PQ output object includes at least:

• pq_key (PQ public key field in output object; legacy notes exist in comments but still part of serialized object),
• kem_ciphertext (encapsulated secret material for receiver recovery),
• view_tag_pq (scan optimization/tag binding),
• one_time_spend_pk (output-unique spend public-key material),
• version marker (QNERO_PQ_OUTPUT_VERSION).

This richer object is what allows both private recipient recovery and chain-validated spend linkage semantics.

4.3 Vendor/backend note: Falafl

Falafl is not a cosmetic dependency in QNERO. It is directly wired into the live scheme2 sign/verify backend paths (pq_ring_scheme2.cpp, falafl_* wrappers/bundles).

In short:

• scheme2 signing calls Falafl wrappers,
• scheme2 verification calls Falafl wrappers,
• key-size and backend-readiness checks are enforced in these paths,
• failure codes bubble out with explicit backend error tags.

So the vendor/backend story is explicit: QNERO’s current ring-signature runtime behavior depends on Falafl-linked backend availability for scheme2 paths.

5. Algebraic Commitment Model

Let Com(a; r, ctx) denote a commitment to amount a with opening randomness r, bound to context ctx.

For a regular transaction, the enforced accounting relation is:

(Eq. 1) SUM_i C_in[i] - SUM_j C_out[j] - C_fee = 0_G

For PQ synthetic coinbase mode:

(Eq. 2) C_reward - SUM_j C_out[j] = 0_G

In implementation terms, QNERO enforces this through commitment set construction and proof-verifier pathways that are bound to canonical context.

6. Canonical Statement Construction

Every output proof is verified against a public statement tuple that includes:

• network domain,
• context hash (get_pq_amount_context_hash(tx) lineage),
• output index,
• ordered input commitments,
• ordered output commitments,
• proved commitment,
• fee commitment,
• backend id,
• statement id,
• proof version.

This explicitly blocks proof transplantation across altered contexts or altered commitment sets.

6.1 How keys are generated and derived (implementation-level view)

QNERO key material is not a single keypair; it is a key family with role separation:

1. Account-level long-lived keys

• PQ KEM public key for transport (m_pq_kem_public_key)
• PQ signature/ring-related public material (m_pq_sig_public_key, spend-base public material)

1. Per-output derivations

• Sender encapsulates to recipient KEM key, producing kem_ciphertext and shared secret.
• Shared secret + tx context + output index drive one-time output derivation (one_time_spend_pk, view_tag_pq).

1. Wallet receive side

• Receiver decapsulates with private KEM key,
• recomputes expected output ownership artifacts,
• matches against on-chain PQ output fields.

1. Spend side

• Ring members / chain pubkeys / commitment transcript are assembled canonically,
• scheme2 signing backend produces enveloped payload,
• verifier checks payload structure + transcript/key/link-tag consistency + backend verify result.

In practice, this is a layered key lifecycle: account keys -> per-output transport secret -> one-time ownership keying -> ring-signature spend authorization.

7. Coinbase in PQ Mode: Why Synthetic Input Exists

A miner reward has no ordinary spend input witness in the same way a regular transaction does. But for commitment-accounting consistency, the reward still needs a commitment-space representation.

QNERO’s approach is deterministic synthetic input construction:

1. derive context hash from final amount-context transaction shape,
2. derive deterministic non-empty opening bytes using labeled hashing,
3. build expected reward commitment,
4. require encoded synthetic pseudoOut match,
5. verify output proofs against the same context and full output set.

This model makes coinbase verification deterministic and consensus-recomputable without relying on hidden wallet-local secrets.

8. Security Goals

QNERO’s immediate security goals in restricted testnet are:

1. Canonical single-family acceptance for live amount proofs.
2. Context binding such that proof reuse across altered statements fails.
3. Conservation in commitment space for transaction accounting under enforced proof policy.
4. Policy coherence across wallet emission, mempool checks, miner construction, and consensus verifier paths.

These are engineering-security goals, not yet full production anonymity guarantees.

8.1 Why these specific technology choices were made

QNERO’s current stack selection is primarily engineering-driven:

• ML-KEM-style transport layer gives deterministic receiver recovery and tight wallet integration for private output discovery.
• Falafl-backed scheme2 ring path provides an explicit runtime backend for post-quantum ring authorization experiments rather than abstract placeholders.
• Single final_v1 amount-proof family minimizes acceptance ambiguity and verifier branch explosion.

The strategic tradeoff is clear: fewer simultaneous “live” options in exchange for stronger auditability and faster hardening feedback.

9. What QNERO Is Not Claiming Yet

To avoid overstatement, QNERO does not currently claim:

• final production-grade anonymity completeness,
• final hidden-range maturity across all future deployment conditions,
• complete cryptographic closure against all future post-quantum attack classes,
• public-mainnet readiness at full claim level.

This is deliberate and healthy. Premature claims are technical debt disguised as marketing.

10. Economic and Operational Philosophy

A privacy chain fails if operational reality is ignored.

QNERO therefore treats the following as first-class concerns:

• verifier cost asymmetry under complex proof validation,
• DoS pressure on public RPC and mempool paths,
• deterministic rejection semantics for malformed payload families,
• staged rollout discipline (restricted testnet before broad claims).

A credible privacy chain is as much about strict rejection behavior as it is about proof construction.

11. Why QNERO Matters If Bitcoin Already Exists

Bitcoin solved decentralized issuance and settlement under a transparent model.

QNERO explores a different requirement profile:

• preserving operationally meaningful privacy,
• reducing metadata leakage by design,
• preparing for a post-quantum direction at protocol layers where transition is hardest,
• preferring narrow, auditable live paths to broad but fragile compatibility matrices.

This is not a replacement thesis; it is a specialization thesis.

12. Bitcoin-Style Credibility Rule

A protocol should be judged by what independent operators can verify, not by prose elegance.

Therefore QNERO adopts a simple rule:

The paper follows the code. If code and wording diverge, wording must narrow first.

This rule is central to this draft and remains in force for all future revisions.

13. Roadmap to Production-Grade Claims

The path from restricted-testnet prototype to stronger claim level requires:

1. full formalization of security assumptions and reduction arguments,
2. parameter freeze and transparent rationale,
3. broad adversarial benchmark publication,
4. repeated external review cycles,
5. operational hardening under realistic hostile traffic,
6. only then, any claim expansion.

13.1 Cryptography-specific completion checklist

Before expanding claims, QNERO should publish and freeze:

• exact algorithm identifiers and parameter sets for KEM and ring backends in release manifests,
• deterministic key-derivation transcripts for output ownership derivation,
• formal domain-separation registry for all transcript hashes,
• backend-failure behavior policy (what is consensus-fatal vs wallet-local rejection),
• migration strategy for vendor/backend replacement if Falafl or any dependency changes.

14. Deployment Guidance for Public Explorer Surfaces

A public explorer should expose chain metadata only:

• block height/hash/timestamp,
• tx count per block,
• node connectivity indicators,
• difficulty/target-derived hashrate estimates.

It should not attempt identity-layer attribution.

Operationally, public surfaces should use restricted endpoints and hardened proxy controls where possible.

15. Conclusion

QNERO exists because the ecosystem needs serious work at the intersection of privacy, canonical verification discipline, and post-quantum trajectory.

The current implementation is intentionally constrained: one live backend, one statement family, one strict policy posture in restricted testnet mode. That is a feature, not a weakness. Narrowness is how systems get hardened.

If Bitcoin’s lesson was “decentralization is possible,” QNERO’s working thesis is:

Privacy + post-quantum direction + strict canonical engineering can be made coherent, but only if claims remain subordinate to implementation reality.

16. Parameter Registry (Draft, to Freeze Before Production Claims)

This section should become a strict release manifest.

16.1 Identity and protocol constants

• Live amount backend id: qnero.pq.amount.final-v1
• Live statement id: qnero.pq.amount.balance.v4
• Live amount proof version: 4
• Network-domain discriminator mapping used by PQ statement verifier paths.

16.2 PQ output object fields

• pq_key
• kem_ciphertext
• view_tag_pq (16 bytes)
• one_time_spend_pk (32 bytes)
• version marker QNERO_PQ_OUTPUT_VERSION

16.3 Sizes to explicitly freeze in next revision

The following must be documented as hard numbers in the next draft revision:

• KEM public key bytes / ciphertext bytes / shared secret bytes
• ring member public-key byte requirements in scheme2 backend
• proof payload byte ranges (min/typical/max)
• tx-level size overhead by output count and ring-size policy

17. End-to-End Algorithms (Protocol Walkthrough)

Algorithm 1 — Address material generation

1. Generate account-level PQ KEM keypair for transport/recovery.
2. Generate account-level PQ signing/ring-related public material.
3. Publish public payload in address format; retain secrets in wallet keystore.

Algorithm 2 — Sender output construction

1. Encapsulate shared secret to recipient KEM public key.
2. Derive one-time output ownership artifacts from shared secret + tx context + output index.
3. Populate PQ output fields (kem_ciphertext, view_tag_pq, one_time_spend_pk, pq_key path as used by code).
4. Construct output commitment and corresponding final_v1 proof statement context.

Algorithm 3 — Receiver output detection/recovery

1. Parse candidate PQ outputs from chain tx.
2. Decapsulate shared secret from kem_ciphertext using wallet secret key.
3. Recompute expected one-time artifacts.
4. Match against on-chain output object.
5. If owned, derive spendable wallet record and validate commitment/proof consistency checks.

Algorithm 4 — Spend authorization (scheme2 + backend)

1. Build canonical ring member set + chain pubkey set + commitment transcript input.
2. Build message hash with required context.
3. Produce scheme2 signature payload via Falafl-backed signer wrappers.
4. Envelope signature payload in canonical structure.
5. On verification: decode envelope, enforce structural checks, enforce transcript/key/link-tag consistency, call backend verify.

18. Security Assumptions and Guarantee Mapping

18.1 Assumptions (explicit)

• Soundness/security of chosen KEM implementation for transport secrecy.
• Soundness/unforgeability of the active scheme2 + backend signing/verification composition.
• Binding/hiding properties of commitment primitives in implemented parameter domain.
• Correctness of canonical serialization and transcript domain separation.
• Honest implementation assumptions (no catastrophic wallet key leakage, no undefined behavior exploitation).

18.2 Guarantees (current scope)

• Canonical live amount-proof family acceptance in restricted testnet mode.
• Context-bound output-proof verification in consensus paths.
• Transaction-level commitment balance checks in enforced paths.
• Deterministic PQ coinbase synthetic-input recomputation and policy checks.

18.3 Non-guarantees (current scope)

• Full production-grade anonymity maturity.
• Final parameter-proof security claim under all post-quantum attacker models.
• Broad public-launch readiness claims.

19. Performance & Benchmark Plan

This section is normative for the next milestone: publish numbers, not adjectives.

19.1 Benchmarks to publish

• Send/proof generation time by output count and ring-size profile.
• Verify time per output proof and per full transaction.
• Block validation throughput under mixed valid/invalid traffic.
• Incremental node sync cost (CPU/RAM/storage/network).
• Wallet scan and receive-detection overhead for PQ output-rich blocks.

19.2 Reporting format

Each benchmark should include:

• machine profile,
• build flags,
• dataset/workload shape,
• median + P95 + P99 latencies,
• failure-mode notes.

20. Attack and Failure Analysis

20.1 Cryptographic/backend failure modes

• Falafl backend not linked/available in runtime paths.
• scheme2 payload malformed/truncated or transcript mismatch conditions.
• KEM payload malformed or size-out-of-bounds objects.

20.2 Protocol-level adversarial patterns

• malformed proof flood against mempool admission
• payload-family downgrade attempts
• output-set substitution/proof transplant attempts
• synthetic coinbase commitment mismatch attempts

20.3 Operational security controls

• strict policy gating before deep verification,
• restricted RPC exposure and proxy controls,
• peer/rate controls and alerting around malformed traffic bursts,
• deterministic rejection codes for forensic traceability.

21. Migration and Governance for Cryptography Upgrades

QNERO should treat cryptographic upgrades as consensus-critical governance events.

21.1 Required upgrade artifacts

• rationale for change (security/performance/maintenance),
• compatibility matrix,
• hardfork activation policy,
• rollback/fail-safe policy,
• external review window.

21.2 Deprecation policy

Any deprecated cryptographic family should move through:

1. disabled-by-default in pre-release,
2. explicit warning phase,
3. consensus rejection after activation epoch.

21.3 Vendor replacement resilience

Because backend dependencies (e.g., Falafl-linked paths) may evolve, QNERO should maintain:

• backend readiness probes,
• deterministic error taxonomy,
• migration test vectors ensuring no silent semantic drift.

References

1. W. Alberto Torres, R. Steinfeld, A. Sakzad, J. K. Liu, V. Kuchta, N. Bhattacharjee, M. H. Au, J. Cheng, Post-Quantum One-Time Linkable Ring Signature and Application to Ring Confidential Transactions in Blockchain (Lattice RingCT v1.0), 2018.
2. QNERO internal specs and implementation references: CHAIN_SPEC.md, NETWORKS.md, GENESIS.md, FINAL_V1_SPEC.md, LIVE_BACKEND_SELECTION.md, TESTNET_SECURITY_CLAIMS.md.

Scope Notice

This whitepaper is intentionally framed as a research/testnet document. It is not an offer, not a production security certification, and not a final anonymity claim.