NixeonAlphanixprotocol.com
Nixeon · Testnet alpha

The post-quantum privacy chain.

Nixeon is being built for privacy by default and auditable on demand. The design has amounts hidden, the transaction graph hidden with them, and the owner rather than the chain deciding who sees either. The post-quantum chain is live on a public testnet today. The privacy lane is not, and each chip below says how far its piece has got.

Privacy lanein buildTransaction graphin designSelective disclosureresearchTransparent testnetlive
connecting
Why now

The deadlines aren't ours. They're already set.

The move to post-quantum security is when, not if. These are not our dates; standards bodies set them, and anything signed today still has to verify decades from now. The same logic applies to privacy: traffic recorded now can be read later, so a ledger that is public today is public forever.

2027
US government begins its post-quantum migration for software signing (CNSA 2.0).
2030
EU and ETSI target for moving critical infrastructure to post-quantum.
2033
Hard deadline for US national-security systems.
30 yrs
Long-dated bonds and archives signed today must still verify in 2050.
Where it fits

Built for value that stays yours to disclose.

One property serves all of them. What you hold and what you send is built to be private by default, and disclosure is yours to give. Permissioned where it needs to be.

Everyday payments and payroll

Salary, rent, an invoice between two people. Built to be nobody else's business by default, and provable to whoever you choose when it needs to be.

Businesses and treasuries

Supplier payments and balances leak margin, counterparties and runway to anyone reading the chain. Amounts are built to stay private, with the holder deciding who sees them.

Tokenized assets and long-dated records

Treasury tokens, private-credit notes, title and identity records. Anything signed today that must still verify in 2050, held on a chain with no classical cryptography left to break.

Regulated issuers and auditors

Where disclosure is mandatory, viewing keys make it selective rather than public. Selective disclosure is a research track, not a live feature.

What is hidden, and from whom

Privacy by default. Auditable on demand.

Privacy is worth little if you cannot prove what you did when you need to, so this is being built holder-first. Nothing is disclosed by default and anything can be disclosed on request. That is the design and not today's testnet, where amounts are still public. The table below says exactly which parts change and which do not. The one thing that stays public either way is how much value enters and leaves the pool, which is what lets anyone check that no money was invented.

WhatToday (live)Privacy lane (in build)Who can disclose
AmountsPublicHiddenHolder
Sender and recipientPublicHidden (in design)Holder
Transaction graphPublicHidden (in design)Holder
Value entering or leaving the poolPublicPublic by designn/a
FeesPublicPublicn/a
ValidityChecked by every validatorChecked by every validatorn/a
What you get

The everyday things, built to outlast quantum.

Everything in this section runs on the public testnet today, with no real funds at stake. What is still being built lives further down, in the progress log.

No classical crypto to break

Live

Every layer is post-quantum, so there is no RSA or elliptic curve here for a quantum computer to unpick. That describes the threat model rather than a guarantee. Post-quantum schemes are young and can still be weakened, which is why authorization is moving off any single one of them.

Harvest-now-decrypt-later

Live

An attacker can record traffic today and break it once quantum matures. Nothing settled here rests on cryptography a quantum computer is expected to solve, so recording it buys far less than it does on a classical chain.

Quick settlement

Live

Sub-second blocks with deterministic finality. Measured throughput, and the conditions it was measured under, are published in the progress log. You do not trade speed for post-quantum security.

Transparency you can verify

Live

Every block, balance and parameter is visible in the explorer, with published benchmarks and an open progress log. You check the chain rather than take a number on faith.

Self-custody

Live

Keys are held by the holder, not a bank and not us. No custodian can freeze, seize or move funds.

A wallet that works

Live on testnet

A browser wallet with a recovery phrase, send and receive, and a full block explorer. The cryptography is invisible; it feels like a normal wallet.

Progress

An order of operations, not a calendar.

Each track says how far it has got and where its code actually lives. The cryptography ships when the analysis is solid, not when a quarter ends.

Privacyin build

Private amounts

Range, balance and booleanity over lattice commitments, proved in one protocol so the cost does not grow with the number of amount bits. The client proves; the node only verifies.

80%

8 of 10 milestones

  • 2026-07-16Direct range proof chosen over folding
  • 2026-07-16Booleanity, range and balance unified into one protocol
  • 2026-07-17Prover and verifier end to end
  • 2026-07-18Prover compiled to wasm, in-browser round trip
  • 2026-07-19Production parameters
  • 2026-07-23Zero-knowledge tail closed
  • 2026-08-10Wallet scan over RPC
  • 2026-08-12Throughput re-measured against current proof sizes
  • openProof size reduction
  • openPrivacy lane in the browser wallet
Privacyin design

Hiding the transaction graph

Amounts alone are not privacy: who paid whom is still readable. Membership proofs and nullifiers hide the graph. The nullifier switch and membership are one piece of work, because doing half of it would let an observer precompute every note's nullifier.

33%

2 of 6 milestones

  • 2026-08-10Tree layer completed
  • 2026-08-13Specification written
  • openNullifier serial moved to gadget digits
  • openMembership proof bound to the spend proof
  • openAnchor retention, with the root in consensus state
  • openImplementation
Authorizationin design

Proof-carrying authorization

Spending proves knowledge of a key instead of publishing a signature, so no key that guards funds is ever on the wire. HAWK was withdrawn from NIST standardisation on 29 July 2026, which is what makes this work urgent rather than tidy: a chain that verifies a proof relation can change signature scheme without changing addresses or consensus.

50%

3 of 6 milestones

  • 2026-07-28HAWK key-recovery result assessed
  • 2026-07-30Replacement design written
  • 2026-08-01Internal review found a key-recovery defect in the ownership commitment and specified the fix
  • openHiding randomness and re-derived width
  • openTransparent lane through the prover
  • openImplementation
Consensuslive

Chain and consensus

A UTXO ledger with lattice commitments, multi-validator BFT consensus with deterministic finality, and sub-second blocks. This is the only track whose code is on main, and everything above is built on it. The build deployed to the public testnet is ahead of main and carries the signature migration tracked under Authorization, so read the two together rather than either alone.

80%

4 of 5 milestones

  • 2026-05-07UTXO state with lattice commitments
  • 2026-06-02Multi-validator BFT consensus merged
  • 2026-06-03Security review, with four network and RPC fixes
  • 2026-06-07Node hardening deployed
  • openHeader aggregation for light clients
Transparent throughput
2,161 tx/s
no target set

1,000 independent-UTXO transactions, 200 ms blocks, release build, macOS arm64. A lab burst on one machine, not a sustained network figure. Re-measured after the move to ML-DSA-44: the same fixture gave 2,425 tx/s on HAWK-512, so the migration cost about 11%, consistent with ML-DSA-44 verify being dearer per call. Sustained figures on a strictly-chained workload are far lower, around 200 tx/s, where the ceiling is block policy and admission rather than signing.

measured 2026-08-23

Privacy-lane batch verify
121 - 168 tx/s
target 100 tx/s · met

Eight cores, release build, M1 Pro. The consensus-path cost of verifying private transactions in a batch. The conservative endpoint is used for the percentage. This is CPU throughput and it is not the lane's ceiling; see the relay row.

measured 2026-08-12

Privacy-lane ceiling, 1 Gbit relay
40.8 tx/s
target 100 tx/s · 41% of target

Every validator ingests the whole proof before verifying it, so the real ceiling is link bytes per second divided by proof bytes: 4.1 tx/s on 100 Mbit, 408 tx/s on 10 Gbit. This is the number that binds the lane, not batch verify, and it is why proof size is the open item on the private-amounts track.

measured 2026-08-12

All tracks and benchmarks →
Try it out

Four steps. Testnet alpha.

Send a post-quantum signed transaction in under a minute.

01

Create a wallet

Your wallet and keys are created right in your browser. The private key never leaves your device.

Open wallet →
02

Claim test tokens

Grab free testnet tokens to try it. Rate-limited per IP. They have no monetary value.

Visit faucet →
03

Send a transaction

Hit Send to submit a post-quantum signed transfer and watch it land on-chain.

Send a tx →
04

Verify in the explorer

Browse recent blocks and confirm your transaction. Validators confirm each block by re-executing it and matching the state root.

Open explorer →
For procurement and security review

The questions your security team asks first.

What exactly is "post-quantum" here?

Every layer, not just the signature.

LayerPrimitiveHard problemStatus
SignaturesML-DSA-44 / ML-DSA-65Module-LWE / Module-SISintegrated
State commitmentAjtai / Ring-SIS (PQE_Q ring)Module-SISintegrated
Block proofnone todayModule-SISplanned
HashingSHA3-256 / SHAKE-256SHA-3 preimageintegrated
Attestation aggregationChipmunk-PoAModule-SISplanned

One ring, one parameter set. The cryptography is published research; the integration is ours. Two things we would rather state than have you find. HAWK-512 was withdrawn from NIST standardisation on 29 July 2026, and we have since removed it from every path. The chain produces no block proof at all today.

How strong is the security?

Stated layer by layer, because a single headline number would hide more than it tells you. Spending authorization on the testnet is set by the signature layer, ML-DSA-44, with ML-DSA-65 on blocks and validator identity; both are FIPS 204 at NIST categories 2 and 3. This replaced HAWK-512 outright after the July 2026 cryptanalysis cut its key-recovery cost to no more than 2108. The state-commitment layer is independently estimated at roughly 280-bit classical and 250-bit quantum by the standard lattice estimator as of 21 June 2026, and it is enforced on every block. The chain produces no block proof today, so there is nothing there to count toward live security either way. Parameters are published, not asserted. There are no real funds on the testnet.

And the block proof itself?

There isn't one right now. The folding prover was removed from the node. It took about a second to fold a single block against a sub-second block time, so it could never keep pace, and each proof ran to 2.29 MB against a 50 KB design target. Validators confirmed state by re-execution regardless, and no block header ever committed to a proof, so nothing on the live chain depended on it. Re-introducing a proof layer, from a construction that verifies directly rather than by folding, is tracked in the progress log, and we will say so here when it lands rather than before.

How fast is it?

About 2,161 transactions per second on a single validator, measured 23 August 2026 under ML-DSA-44 with 1,000 independent-UTXO transactions and 200 ms blocks. Thinner block policies measure far lower, around 200 tx/s on a strictly-chained workload, so the ceiling is block policy and admission, not signing. Blocks tick well under a second with deterministic finality. That measurement and its date are in the progress log.

Can we run it permissioned?

Yes. Multi-validator consensus runs the testnet today. Header aggregation for fast light-client verification is an open milestone on the chain and consensus track.

How does this fit NIST and CNSA 2.0?

SHA3-256 and SHAKE-256 are FIPS 202. HAWK was withdrawn from the NIST additional-signatures process on 29 July 2026, after cryptanalysis that recovers a key from the public key alone; its authors judged that larger parameters would make the scheme uncompetitive. Our published contingency confined a move to ML-DSA (FIPS 204) to the signature layer alone. That move is done: ML-DSA-44 authorizes spends and ML-DSA-65 signs blocks and validator identity, which also improves the CNSA 2.0 posture. Separately we are moving spending authorization to a proof of key knowledge, so that the chain stops depending on any one signature scheme.

That withdrawal is also why authorization is moving off signatures altogether. When the chain checks a proof relation instead of running one named algorithm, changing scheme is a wallet update rather than a rewrite of addresses, balances and consensus rules. Post-quantum cryptography is young enough that this will happen again, so the useful question is not whether a scheme breaks but what breaking one costs.

What's the procurement surface?

Settlement only today. No untrusted smart-contract VM. Programmability comes after the cryptography reaches audit-grade.

Can we adopt incrementally?

Yes. Run Nixeon as a sidecar settlement layer, or integrate the full stack.

What about privacy?

Auditable privacy, not anonymity. The privacy lane hides amounts, and viewing keys let a holder disclose to counterparties, regulators and auditors. Amounts are public today. Hiding them is in build, and viewing keys are still at the research stage. Status per track is in the progress log.

Is it audited? Ready for real funds?

Not yet, and we say so plainly. This is a public testnet alpha. An external post-quantum security audit is the gate before production use with real funds.

Talk to the team

Evaluating post-quantum settlement? Tell us what you're building.

Custodians, issuers, and builders weighing the migration: send a note and we'll pick it up. Tell us your use case and where you are in planning.