Quantum safety
This page is for someone deciding whether "quantum-safe" on the front page means anything. It says exactly which signatures change, which cannot, what the L1 mitigation buys and what it does not, and what is actually running. Like the rest of this section, it is written so the limits are as easy to find as the claims.
A new identity created on the testnet today signs with Falcon-512 (ML-DSA-65 selectable), and its 12-word recovery phrase reproduces that post-quantum key. That is what shipped, with the ledger engine at Activeledger 4.7. It is a testnet: no real funds. What did not change, and is named below: the settlement gateway's signing key is still classical secp256k1; identities created before the release still sign with secp256k1; and the L1 chains are ECDSA and will stay so. QER, the withdrawal-path discipline for that last point, is a design and is not built. The roadmap carries the same rows.
The threat, precisely
Until this release every signature Varnir touched was ECDSA over secp256k1 — the identity key that authorises ledger transactions, and the L1 wallet keys that move value on Ethereum, Tron and BNB Smart Chain. Shor's algorithm, run on a large enough fault-tolerant quantum computer, derives a secp256k1 private key from its public key. No such machine exists; nobody credible will give you a date; and the risk is not symmetric across time, because a public key that is visible now can be attacked whenever the machine arrives.
That last point is the signature-side version of harvest now, decrypt later. For encryption an attacker records ciphertext and waits. For signatures the attacker records public keys, waits, and then forges. So the question for any system is not only "which scheme do you use?" but "how many public keys have you already exposed, and how much value do they still guard?"
Varnir has two different answers, because it has two different kinds of key.
| Identity key (Varnir ledger) | L1 wallet key (Ethereum, Tron, BSC) | |
|---|---|---|
| Who chooses the signature scheme | Varnir — it is our ledger | The L1 chain. Varnir cannot change it |
| Scheme today | Falcon-512 by default for new identities, ML-DSA-65 selectable; secp256k1 for identities created before the release | secp256k1 |
| Where it goes from here | Classical keys stay valid beside post-quantum ones; the gateway's signing key is still secp256k1 and is on the roadmap | secp256k1, permanently, until the chain itself migrates |
| What Varnir can do about it | Replace the primitive — done for the identity key | Reduce how much value any exposed key guards — QER, below. Not built |
| Honest label | Post-quantum, for the identity key and its recovery | Not post-quantum. Exposure reduced, not removed — once QER is built |
The rest of this page is those two columns, in turn.
Post-quantum identities on the ledger
An identity is a stream on Varnir's own ledger, and the key that signs for it is validated by Varnir's own nodes. That is the whole reason this half is straightforward: there is no external chain whose validators have to agree.
Activeledger 4.7, which the public testnet nodes now run, makes post-quantum signature schemes a first-class key type on an identity:
| Scheme | Standard | Role | Public key | Signature |
|---|---|---|---|---|
| Falcon-512 | FN-DSA — NIST's forthcoming standardisation of Falcon (draft FIPS 206, not yet finalised) | Default for new identities | 897 bytes | ~666 bytes |
| ML-DSA-65 | NIST FIPS 204 | Selectable alternative | 1,952 bytes | 3,309 bytes |
Both are lattice-based; neither has a known efficient quantum attack. Falcon's signatures are roughly a fifth the size of ML-DSA-65's, and every transaction on the ledger carries its signatures with it, which is the practical case for it as the default. Two trade-offs run the other way, and together they are why both are on offer rather than just the smaller one:
- Standardisation. ML-DSA-65 is a finalised NIST standard — FIPS 204, published in 2024. Falcon's FN-DSA is not: it is the forthcoming FIPS 206 and is still in draft. If your requirement is a signature scheme that is already a ratified federal standard today, ML-DSA-65 is the one that meets it, and it is a selectable key type for exactly that reason.
- Implementation. Falcon's signing uses a floating-point Gaussian sampler that is harder to implement in constant time, where ML-DSA's arithmetic is integer-only.
Which of those you weigh more is a judgement a security reviewer is entitled to make, so the choice is yours per identity — Falcon-512 for size, ML-DSA-65 for a finalised standard.
Three properties follow from how the engine models keys:
- Post-quantum and classical keys coexist on one identity. An identity is not forced to abandon a secp256k1 key to gain a Falcon one. This is what makes a migration possible without a flag day, and what lets a key with a classical-only client keep working while the client catches up.
- New identities are post-quantum by default. The default is a property of onboarding, so a fresh identity starts on Falcon-512 without the caller having to know what Falcon is. Identities created before the release keep the secp256k1 key they were onboarded with; nothing migrates them automatically.
- Authority is unchanged. The stake model — which key may propose, which may confirm, that no key confirms its own proposal — is evaluated at consensus exactly as before. The scheme under the signature changes; the rules about who may sign do not.
The 12-word recovery phrase is post-quantum too
This is the part worth pausing on, because it is where most "post-quantum wallet" claims quietly fall back to classical. A Varnir identity is backed up as a 12-word phrase, and for a post-quantum identity the phrase does not derive a secp256k1 key that then guards a Falcon key. It derives the Falcon key itself: the phrase is stretched to a seed, the seed is bound to the scheme name, and Falcon-512 (or ML-DSA-65) key generation runs from that seed deterministically. The same twelve words and the same scheme reproduce the same key, byte for byte, and therefore the same identity. There is no classical key anywhere in the recovery path.
Two limits, stated plainly:
- The recovery is Varnir-internal. It restores the identity within Varnir. There is no cross-wallet HD standard for post-quantum keys yet — nothing like BIP32/BIP44 for Falcon or ML-DSA — so the words do not import into a third-party wallet, and a phrase from another wallet does not produce a Varnir post-quantum identity.
- The scheme is part of the derivation. The same phrase yields a different key under Falcon-512 than under ML-DSA-65, on purpose, so the two identities can never collide. Recovering an identity means the phrase and the scheme it was created under.
What is post-quantum, and what is not
The honest version of the claim is a list, not an adjective. For an identity created on the testnet today:
| Signature scheme | State | |
|---|---|---|
| The identity's own signing key | Falcon-512 (default) or ML-DSA-65 | Post-quantum, live on testnet |
| Its 12-word recovery phrase | Derives the same Falcon / ML-DSA key | Post-quantum, live on testnet — Varnir-internal, see above |
transferOnLedger and every other L2 transaction the identity signs | The identity's key | Post-quantum |
| Authorising a withdrawal on the L2 | The identity's key | Post-quantum — the L2 authorisation only, see the next row |
| Signing the withdrawal on the L1 | The settlement gateway's signing key: secp256k1 | Classical. The L1 would accept nothing else, and that key itself is on the roadmap to move |
| Every order on the exchange — make, take, cancel | The identity's key | Post-quantum |
| A scoped key added to an identity | Its own Falcon-512 (default), ML-DSA-65 or secp256k1 | Follows what you generated. VarnirClient.generateKey() returns Falcon-512, and header-signed REST requests verify it with the right primitive |
| Identities created before the release | secp256k1 | Classical. Nothing migrates them automatically; the coexistence rule above is what lets that happen later without a flag day |
| L1 wallet keys (Ethereum, Tron, BSC) | secp256k1 | Classical, permanently. QER, below, is the mitigation — and it is not built |
On the exchange row: a make, a take and a cancel are each a transaction signed
by the identity and settled by Varnir.Swap on the L2. The off-ledger matcher
only relays the terms a maker signed; it never signs, so it adds no classical
signature into the path. With the identity key post-quantum, the authorisation
and the settlement of an order are post-quantum end to end.
That is the basis for the line on the front page. As far as we know, no other venue authorises and settles its order book under NIST post-quantum signatures end to end. "As far as we know" is doing real work in that sentence: we cannot prove a negative about every exchange in existence, and we are not trying to.
What the line does not say is that a Varnir account is quantum-safe as a whole. An identity created before the release still signs with a classical key. The gateway that signs your withdrawal onto Ethereum, Tron or BSC signs with a classical key. And the value the identities are trading was deposited on, and will be withdrawn to, an L1 chain — which brings us to the second column.
L1 stays secp256k1
Ethereum, Tron and BNB Smart Chain all authenticate transactions with ECDSA over secp256k1. On each of them an address is a hash of the public key, so an address that has only ever received has not exposed its key; the public key becomes visible on-chain the first time the address spends. From that point, a sufficiently large quantum computer could derive the private key and spend whatever the address holds, then or later.
Varnir cannot change that. No layer built on top of a chain can change what the chain's validators accept as a valid signature. Anyone who tells you their Ethereum wallet, bridge or L2 has made the Ethereum side quantum-proof is describing something that does not exist. If the chains migrate — Ethereum has published research and proposals in that direction — Varnir will follow them; it cannot lead them.
What Varnir controls is the shape of its own L1 activity: which wallet signs, how often, how much it holds when it does, and how the signed transaction reaches the network. That is where QER operates.
QER — Quantum Exposure Reduction
QER is Varnir's own settlement pattern for the L1 withdrawal path. It is not an Activeledger feature and it is not cryptography; it is discipline about public-key exposure, enforced by the code that picks and signs with pool wallets. The goal is stated in one line:
Any L1 public key that does get exposed should, at the moment of exposure, guard almost nothing.
Four rules:
- A fresh wallet signs each withdrawal. The wallet chosen to sign a withdrawal is one whose key has never signed before — so its public key has never been on-chain. This builds directly on the existing way keys are held: users do not own a specific L1 wallet — the L2 balance is the balance, and any wallet in the network's pool may sign — so the signer can be chosen at signing time rather than fixed at deposit time.
- No address is reused. Once a wallet has signed, it is retired. It does not sign again.
- The change leaves with the withdrawal. Whatever the signing wallet held beyond the withdrawal amount is swept to a brand-new, never-exposed wallet as part of the same withdrawal. So the exposed key guards, after that transaction confirms, approximately zero.
- On Ethereum, the signed transaction goes through a private relay, not the public mempool. A transaction in the public mempool exposes the public key before it is included; a private relay closes that window, delivering the transaction to a block builder directly. It is the same route used to prevent front-running and sandwich attacks, and Varnir gets that protection at the same time.
What QER buys, and what it does not
It buys a small, bounded value-at-exposure. Under QER, the value guarded by any exposed key on Varnir's side is one withdrawal, for the duration of its own confirmation, and then nothing. There is no long-lived hot wallet whose public key has been visible for years while balances flow through it.
It does not make L1 quantum-safe. The withdrawal itself is still an ECDSA signature that Ethereum, Tron or BSC verifies. A quantum adversary fast enough to derive a key and out-race a transaction during its confirmation window could still contest that one withdrawal. QER shrinks the target; it does not remove it.
It does not protect the far side. The address a withdrawal pays out to is the recipient's, on the recipient's chain, under the recipient's key hygiene. Nothing Varnir does reaches that.
It is uneven across chains. The private-relay rule is Ethereum-specific. On Tron and BNB Smart Chain, QER is rules 1–3 only: fresh wallet, no reuse, change swept away. The mempool window on those chains is not closed by Varnir.
An address that has only received has exposed nothing. That is a property of the L1 chains, not of QER: on Ethereum, Tron and BSC the public key is revealed by spending, not by receiving. QER is the discipline for the moment an address does spend.
Cost
Fresh wallets are not free. Each one is a key generated inside the confidential VM under a node quorum, then Shamir-split across the nodes — and MPC-TSS wallets are considerably more expensive to produce than standard ones. Sweeping change to a new wallet is also more L1 gas than a single transfer. Those costs are real, they are why QER is scoped to the withdrawal path, and they are to be measured before it is switched on rather than assumed away.
Status, in one table
| State | |
|---|---|
| Post-quantum identity keys on the ledger | Live on the public testnet — Activeledger 4.7 |
| Falcon-512 default, ML-DSA-65 selectable | Live on the public testnet |
| 12-word recovery phrase deriving the post-quantum key | Live on the public testnet — Varnir-internal; no cross-wallet import |
| Post-quantum and classical keys coexisting on one identity | Live on the public testnet |
| Exchange orders authorised and settled under post-quantum signatures | Live on the public testnet, for identities with a post-quantum key |
| Withdrawal authorised on the L2 | Follows the identity key — post-quantum |
| Scoped keys added to an identity | Follow their own type — Falcon-512 by default |
| Settlement gateway's signing key | Classical secp256k1 — roadmap |
| Identities created before the release | Classical secp256k1 — not migrated automatically |
| QER rules 1–3: fresh signer, no reuse, change swept | Not built — design only |
| QER rule 4: private-relay broadcast on Ethereum | Not built — design only, Ethereum only |
| L1 (Ethereum, Tron, BSC) quantum-safe | No. Cannot be made so by Varnir |
| Real funds | No — public testnets only |
Next
- How keys are held — the key model QER's fresh-wallet rule relies on: pooled wallets, split keys, no owner of a specific address.
- Distribution and jurisdiction — what is actually running, which is the honest baseline every row above is measured against.
- Roadmap — where post-quantum keys and QER sit relative to everything else that is shipped, limited or not built.