CIP-0197? | Post-Quantum ZK Signatures for HD Wallets

[paweljakubas]

CIP: Post-Quantum Zero-Knowledge Signatures for Cardano HD Wallets

Summary

This PR adds a new CIP proposing an optional, additive post-quantum signing layer for Cardano HD wallets built on CIP-1852's BIP32-Ed25519 derivation, based on the ZKPoSP construction (ePrint 2026/1508), with a concrete proof system already validated end-to-end on Cardano.

Problem

Cardano keys are Ed25519, broken by a quantum adversary via Shor's algorithm. A CIP-1852 wallet derives its entire key hierarchy from one root seed — recovering a single signing scalar lets an adversary forge transactions. Replacing the derivation scheme would invalidate every existing address and break hardware wallets, CIP-1854 multisig, and governance keys.

Proposal

Keep keys, addresses, and derivation unchanged; accompany the classical Ed25519 signature with a zero-knowledge proof of knowledge of the seed witness behind the existing public key. Security reduces to the conjectured quantum hardness of SHA-256/SHA-512 and the soundness of the proof system — no migration, no re-registration, no address change.

Why STARK is not viable

ZK-STARK (RISC Zero) is transparent and post-quantum, but produces proofs of ≈219 KB — far above Cardano's transaction size limits and impractical for bandwidth-constrained wallets. Verification is ≈9–10 ms and signing ≈12.5 s per transaction, with a one-time derivation cost of ≈156 s. These numbers make STARK a useful research baseline, but not a deployable solution for a UTxO chain where every byte in the redeemer counts.

The viable path: NovaSlim (transparent folding + sumcheck)

NovaSlim is a transparent, trusted-setup-free proof system that NIFS-folds step-circuit witnesses into a Relaxed-R1CS accumulator and compresses it with a sumcheck argument. It is already working end-to-end on Cardano with an Aiken/Plutus V3 on-chain verifier.

For a Cardano key-ownership step circuit (~7.7K constraints, 255 steps, BLS12-381):

Metric	NovaSlim	STARK (RISC Zero)
Proof size	~1.0 KiB slim	~219 KB
Verify time	~0.7 ms	~9–10 ms
Fold/prove time	~138 s total (~543 ms/step)	~12.5 s (signing) / ~156 s (derivation)
Trusted setup	None	None
On-chain verifier	Aiken/Plutus V3 (validated)	Requires new native primitive
Fits in maxTxSize	Yes	No

The slim proof strips commitment openings, keeping only the sumcheck protocol data. It is commitment-scheme-agnostic (Pedersen, SIS, or Hash) and verifies with native field operations only — no pairings, no curve cycles, no EVM precompiles.

Deployment phases

Phase 1 — off-chain, adoptable immediately (recommended): the classical Ed25519 signature stays on-chain; NovaSlim proofs are verified out-of-band by wallets, exchanges, and indexers. No ledger change — quantum readiness now.

Phase 2 — native sumcheck verifier in the node (future): NovaSlim proofs become the on-chain witness, verified by a native (non-Plutus) sumcheck primitive. Requires a consensus change. The ~1.0 KiB proof size is already within current transaction limits, so Phase 2 is gated only by ledger development, not by fundamental proof-size constraints.

Key design points

• Proofs are anchored at the hardened account node — required because non-hardened leaves are forgeable from public keys (paper Prop. 6.3/7.2), and every Cardano leaf is non-hardened.
• Split proofs: a one-time derivation certificate per account plus a per-transaction signing proof, bound by a shared hash (hkR).
• Backend-agnostic payload: the CIP defines the witness relation (seed → BIP32-Ed25519 derivation → public key); the proof format is versioned so that the specific argument system (currently NovaSlim sumcheck) can evolve.

Open questions for reviewers

1. Should the CIP mandate NovaSlim as the reference implementation, or keep the payload format generic enough to admit future transparent schemes?
2. Native sumcheck verifier in the ledger — should the specification include a concrete Plutus V3 cost model, or defer to a future CIP?
3. Proof-format versioning and parameter handling — how should wallets negotiate backend versions?

---

(latest rendered version from branch)

[perturbing]

Hi Pawel very nice CIP; this was also on my mind!

I really like the dual route of signature and proof; it's smart to optionally bind still to the old path (in case the zk has a bug or QC takes a while still).

A few initial review + questions below

[perturbing]

I think these numbers need to be specified more. What machine and more context of these timings are needed?

Especially I am interested in

1. Peak memory consumption (proving generally has one peak at the end)
2. Can you try running this via WASM in the browser?

The latter is interesting because it is generally the worst-case environment.

[paweljakubas]

Hi, and thank you for taking the time to look at the cost numbers so carefully — these are genuinely useful points, and they hit exactly where our data is thinnest. Let me respond to each one.

A small caveat first, to be fully transparent: this CIP is written from the ZKPoSP paper (ePrint 2026/1508), and we don't have our own prototype yet. So all numbers below are the paper's, and we've committed to re-measuring them on our own reference implementation before relying on any of them.

1. Machine and context of the timings — You're absolutely right, "16-core box" was too vague. The paper (§9) actually specifies it precisely: a dedicated OVH EU-central cloud server with an AMD Ryzen 9 9950X3D (16 cores / 32 threads @ 4.5 GHz, 64 GB RAM, no GPU), Ubuntu, Rust over RISC Zero v5.0.0-rc.1. I've added that exact spec to the CIP's cost table and noted that these are reference figures for that machine, not for end-user devices.

2. Peak memory consumption — Great question, and your intuition is correct: STARK proving does have one dominant memory peak at the end, in the FRI commitment phase. The honest answer is that the paper does not benchmark prover memory — the ~8.4 MB figure it reports is verifier-side. So I don't have a number to give you, and I'd rather not guess. I've added peak-memory measurement (including its profile across the proving phases) to the acceptance criteria. And if it turns out to be prohibitive, the paper's own design already has the escape hatch: the one-time derivation proof can be delegated to a proving server, leaving only the cheap per-tx signing proof to run on-device.

3. WASM in the browser — Agreed, that's the worst-case environment and very much where Cardano wallets live. The paper doesn't cover it, and without a prototype we can't run it yet, so here's our reasoning instead:

• What a browser wallet needs per transaction is verification — ~9–10 ms, constant, sub-10 MB. That's trivially fine in WASM.
• The heavy part is proving (~12.5 s signing, ~156 s one-time derivation on that desktop-class machine); browser WASM will be slower still. The paper's own plan (§11) delegates the one-time derivation proof to a proving server — exactly what Phase 1 assumes.
• I've added a browser/WASM benchmark (prove + verify, timing and peak memory) to the implementation plan, and will publish results as soon as I have them (of course if we agree we are pursuing this path first;-)).

Until then, please read all timings as the paper's reference figures on the machine above — not as a promise about end-user devices.

[perturbing]

Going the Risc0 route means that the circuit will be bigger than a handwritten one.

The CIPs current rationale is less audit surface, but I think that is not entirely true.

We have in Midnight-zk all the tools (audited) to create such a circuit (I even have a heavily optimized one ready, 114,662 rows @ k=17). I believe that for FRI, you add two orders to this for the blowup.

The only downside is that it is using pairing crypto... That said, the midnight-zk current KZG PCS can easily be swapped out for FRI PCS.

How big is your Risc0 impl?

[paweljakubas]

Thanks — very helpful comment. A few points in response:

1. The Implementation Plan is tentative. I am not committing to one backend; it's a menu of options to pursue, and the CIP now enumerates them explicitly (RISC Zero zkVM as the paper's baseline, Halo2/midnight-zk with the KZG PCS swapped for FRI, Plonky3-style native FRI-STARKs, and Nova as a comparison-only bound). The one hard constraint is a post-quantum prover.

2. You're right about the audit claim. The zkVM buys lower engineering risk, not a smaller audit surface — its own arithmetization and prover still need auditing. I have reworded the rationale accordingly.

3. On quantum-proofness. This is the point we can't bend, and it excludes the options as they currently stand: the midnight-zk circuit (KZG is pairing-based, broken by Shor's), out-of-the-box Halo2 (same pairing issue), and standard Nova (discrete-log folding + trusted setup). That's why the CIP defaults to FRI-STARKs. I'd genuinely welcome the Halo2/midnight-zk route with FRI — your 114,662-row @ k=17 circuit is a great starting point — but the PCS swap is real work and re-opens the security argument, and we'd then benchmark it head-to-head against RISC Zero. I'll also try my optimized Nova (I have the groth16 and nova prover) purely as a performance comparison.

4. How big is our RISC Zero impl? Honest answer: I have no prototype yet — the CIP is based on the paper, which reports the signing circuit as constant (two SHA-256 calls via the accelerator, ~12.5 s) and the derivation proof at ~156 s, but doesn't publish per-scheme cycle/segment counts. Also, a RISC-V zkVM trace and a PLONKish circuit aren't directly comparable row-for-row; what I'll benchmark is proving time, peak memory, proof size, and audit cost. I'll publish those numbers as soon as the reference implementation exists. Of course, if there is decision to pursuit this path first ;-)

[perturbing]

Will you, or is it your goal, to add a benchmark on a POC implementation to the CIP?

I think this design makes or breaks with the possibility of running it.

Also because having some exact size metric is important (after all blocks have only 90112 bytes of space).

[paweljakubas]

At some time (within several months) I will have several POCs. Right now I was more into if we are pursuing this path or not. I enumerated several candidates (five atm) that might be interesting to check at Phase 1. My hope/ask would be also that on your side you could also give it a check with your prover:-) Detailed benchmarks of all plus comprehension of trade-offs plus proper analysis of them could point to Phase 2 IMHO. So I would say right now, it would be good to make this strategic decision. Not the last one if we want premium quantum proof blockchain.

[perturbing]

Of course; I think time and space-wise verification may fit in phase 1. I just fear that any proof size is just to large to put in blocks (without having 1 tx per block)

[perturbing]

@paweljakubas, is it the goal of this CIP to never put the proofs in blocks?

That is, given that along with normal transactions we also gossip the proofs across the network, a node keeps a cache of the proofs and only adopts blocks of signatures for which it has seen a zk proof? This way consensus forces only zk witnesses + normal ed25519 signatures in blocks.

I think the CIP does not say it now, but I think that we should consider this. This way we have a "cheap" way of making Cardano quantum secure without too many code changes (some nuance here is in place ofc). The only gap that I see that remains is the VRF (not derived this way). Also, people slowly need to switch to derived keys instead of generated ones.

[paweljakubas]

hi @perturbing That is what I was considering as back-up plan to be frank. In case we are not able to put proofs in blocks. Of course, given new developments coming we could have the following plan.

1. Try to come up with post-quantum proof system that is able to produce proofs small enough to fit in the tx
2. (if 1 not feasible) Try to produce the proofs that fit in several txs (as we can reference them mutually)
3. (if 2 not feasible/practical) A node keeps a cache of the proofs and only adopts blocks of signatures for which it has seen a zk proof (here we need to handle VRF thing)

Sounds like a plan worth adding to CIP?

[perturbing]

I think that a CIP should gather evidence on what is the best path and then describe that.

So I believe that this CIP is "not final" until more research is done on the topic of block impact and mitigation.

Of course, it is okay to pivot a CIP slightly when implementing it (see, for example, some PRs on the Leios CIP), but those are not big shifts.

[paweljakubas]

Fair point. I will gather more evidence with the proof systems I am developing/deploying and return with data 👍

[rphair]

thanks @paweljakubas and I feel sure we will be ready to confirm this as a candidate in Triage at the next CIP meeting: https://hackmd.io/@cip-editors/141

Now that it's being reviewed, please make sure any further forced pushes also contain any commits to this PR branch from other reviewers / GitHub UI 🙏 (to demonstrate constructive peer review).

cc reviewers on PQ CIPs so far (besides @perturbing): @kozross @hjeljeli32 @mgajda + ecosystem impact: @ptrdsh @KtorZ

[paweljakubas]

Hi Thomas @perturbing , thank you very much for taking a look and giving helpful answers wrt cryptography.

I would like to add one more data point worth sharing: Zcash's ecosystem is converging on the same conclusion. The Tachyon zkVM (kroma-network/tachyon, ex-PSE) already implements Halo2 with a FRI polynomial commitment scheme — so "Halo2 with FRI" isn't hypothetical, it's shipped tooling we could reuse. And Zcash's own quantum-readiness roadmap explicitly plans hash-based or STARK-style hardening of its Halo2 proofs, staged over time rather than rushed — largely for the reasons you'd expect: post-quantum proofs are bigger, and migrating prematurely risks breaking hardware-wallet integrations and locking in immature standards.
That staged posture is essentially the Phase 1 → Phase 2 reasoning, and it gives us a second real-world vote for the additive, swap-the-commitment-layer approach over re-keying.

I've added these as references in the CIP's backend-options section.

[rphair]

@paweljakubas, per your review request: I've been following the technical review with interest, though not qualified to participate beyond presentation issues & accumulating points of others' expert review to assess when this might be complete + soliciting other reviews as may be needed.

Currently we just have to keep working on #1242 (comment) re: the formatting question of whether your references would look better as a footnoted list of references or direct external links from the document.

[paweljakubas]

@AndrewWestberg @rphair @perturbing I have fixed and double checked all references. Also did another round of my research and added prospective proof system as a candidate for Phase 1 - Lova — lattice-based IVC. FYI. I am about to start building it on top of my Nova impl and will soon experiment with it (purely prototype phase but still)

[rphair]

@paweljakubas thanks for your continued work, in appreciation for the technical discussion & with my apologies that the formatting issues have been a distraction.

Your latest changes to fix the problem I pointed out in #1242 (comment) are very different than what's used in other CIPs: either shortcut (embedded) reference links or Footnotes which would work best for your material. Instead you have created HTML links, e.g.:

• from: [ZKPoSP](#ZKPoSP)
• to: <a id="ZKPoSP"></a>[ZKPoSP] Botta, Pospieszalski, Ragnoli, Ranvier, "ZKPoSP: ...

... which:

• only go in 1 direction (unlike Footnotes which link back to their place in the original document);
• aren't highlighted when the reader arrives there (they can only see all the References at the end of the document);
• aren't portable Markdown: so we have no guarantee they will work when published on cips.cardano.org... which I'm guessing is important to you since all your other CIP references link there.

I don't want to take time away from your technical writing & review response, and so if you need me to edit the document to install the footnotes properly then please say the word and I'll do it.

Alternatively: if you have a particular reason not to use either of the GitHub Markdown standard linking styles I described in #1242 (comment), then please also confirm this: so the editors can acknowledge your author's prerogative in initial review and be prepared that the reference links won't work on cips.cardano.org (since it generally doesn't copy raw HTML).

[rphair]

These possible implementation options, even though considered during the time period of the surrounding activities, are generally not included in this section: which is always about the criteria for progress. The best CIPs can do when they rely on preliminary investigation to choose a path is put the choice itself into a timeline with other development activities.

Alternative implementation options are generally fully described in the Rationale section: or maybe Specification if they will be real things rather than just concepts or ideas. Once defined there, they can be added as items to the Acceptance Criteria or Implementation Plan as appropriate. Once this subsection is moved, this section will be in the same format as all other CIPs.

[paweljakubas]

hi @rphair I tried to apply all your suggestions in the newest version - I hope I succeeded!
hi @perturbing I added TWO PATHS in https://github.com/paweljakubas/CIPs/blob/paweljakubas/post-quantum-hierarchical-deterministic-wallets/CIP-POST-QUANTUM-WALLETS/README.md#motivation-why-is-this-cip-necessary
for people to understand what is this "game" all about. That this CIP is an "intermediary" solution, a bridge. And at some point there will need to be a "proper" PQ solution. I added that as I was pinged by several people asking me why not falcon/...etc.

[rphair]

@paweljakubas it looks like all the issues above are resolved except the technical subjects under consideration — as it should be :) — except the one (#1242 (comment)) of the Proving Backend Options still planted in the middle of your Path to Active.

We will have a great Triage of this at the next CIP meeting (https://hackmd.io/@cip-editors/141) regardless: and if the document ordering issue is not fixed by then, we can confirm my recommendation or get alternate suggestions from other editors.

In any case I think the community at large will be very happy to see this under way. As soon as we assign a CIP number on Tuesday (which I will recommend) we can push this out a little further across Cardano work areas to get a broad-spectrum review.

[rphair]

@paweljakubas this was well received at the CIP meeting: confirmed a candidate as expected, with great appreciation for the proposal even with the disclaimer that this is an "intermediate" rather than general solution of the post-quantum problem for asset security.

We expect that technical review will go on for a while and so please comment when you feel it has stabilised (before a editorial review to merge) or whenever you might need a higher bandwidth discussion for unresolved technical issues — e.g. via a Discord channel or a spot on the CIP meeting agenda.

As soon as possible in the review process please follow the advisement in #1242 (comment) to disperse the Proving Backend Options from where it hangs in the middle of your Path to Active.

• Specialist reviewers will be interested in all these topics and should review the document as a whole after this material is properly factored into your Rationale and/or Specification.

In the meantime please rename the containing directory to CIP-0197 and update the "latest rendered version" link in your OP 🎉

[paweljakubas]

Hi @perturbing @rphair !

Pls checkout the recent edit that tightens the CIP-197 README to reflect the actual state of the companion implementation in nova-slim (https://github.com/paweljakubas/nova-slim), specifically the end-to-end PoC at cardano/cip197/ (https://github.com/paweljakubas/nova-slim/tree/main/cardano/cip197) (documented in README.md, E2E.md, and tested via scripts/e2e_equivalence.sh).

NovaSlim is a Nova-family folding scheme that produces sub-kilobyte transparent proofs for on-chain verification, with a runtime-selectable commitment layer — Pedersen for speed today, and SIS or Hash commitments that can be swapped in as quantum-hard alternatives mature without changing the proof format or the Aiken verifier.

The goal here is simply to keep the specification accurate and honest about what exists today versus what is still in progress. Four small adjustments:

• Maturity framing — "Production-ready" was too strong for an unaudited experimental project; the table now reads "Implemented (experimental, unaudited)".
• Performance claim — Removed the "~5× faster" SIS-vs-Pedersen figure, which isn't supported by the benchmark data, and replaced it with a qualitative note about matrix–vector products replacing MSMs.
• Circuit status — Clarified that the runnable validation pipeline today uses the VRF stand-in circuit; the full BIP32-Ed25519 circuit is still being built, as documented in the cardano/cip197 README.
• Deployment language — Softened "deployable today" to "technically feasible today" and "prototyping", which better matches the experimental nature of the code.

The cardano/cip197 PoC remains the concrete, tentative path for Phase 2 infrastructure: it proves the fold → compress → slim-proof → verify pipeline works end-to-end on Cardano's BLS12-381 scalar field with Plutus V3. I believe this edit makes the CIP more credible and easier for reviewers to evaluate. Happy to adjust wording if anyone prefers a different tone.

FYI. I have also changed description of the PR

PS. I was working on NovaSlim since Dec 2025 and only during weekend decided to show it to the world;-)

[rphair]

@paweljakubas it's great news for Cardano that you think NovaSlim will work here & that you've documented this so comprehensively. 🎉

Now more than ever, especially since more items are going into the Proving Backend Options which we've asked you to move out of its inappropriate place in the middle of Path to Active, before this material gets widespread technical review we need you to move it (as I've asked a couple times before above, with reasons) to:

• Specification if you think each of these options will serve different parts of the spec
• Rationale if this comparison will ultimately serve a smaller number of design choices... and the fact that you're leaning on NovaSlim now makes this the logical choice.
• (perhaps both: if you can break it up accordingly)

Although you have graciously given the CIP editors write permission to your branch, I'm hoping not to do this myself: just moving the section bodily would be clumsy compared to the care you've taken with the flow of the rest of the document. But the editors cannot merge it the way it is now, and we need reviewers to review these options in place rather than changing the structure & maybe the content at the last minute before merge.

[paweljakubas]

@rphair Thanks!

I have made proper adjustments. Also added link to nova-slim whitepaper which is my humble attempt to substantiate my claims in more formal fashion. I am both enthusiastic and cautious here. Pls treat it as tentative solution. Although I tried to nail it to the best of my knowledge and abilities, and spent a lot of time on this (also by adding numerous tests and covering use cases)!

I repeat paper/specialization link https://github.com/paweljakubas/nova-slim/blob/master/whitepaper.pdf

I do think we have two backend options here I underlined.

Pls also take notice that I demonstrated e2e of what is the subject of this proposal here : https://github.com/paweljakubas/nova-slim/tree/master/cardano/cip197
Of course, this is experimental and fresh system (IMHO conjectured PQ but I need to state that tentatively) but is transparent (no trust setup needed), performant, produces small proofs (sub-kB or so) and has committment modularity (so except classical pedersen, we can use PQ SIS and Hash).

[rphair]

@paweljakubas the latest change looks great: the Path to Active is now easy to follow (though as you suggest, we will be cautious about announcing this as a "solution") and the moved material looks natural where you have moved it to.

Since it's been nearly a month since we tagged our limited set of prior PQ-informed reviewers (#1242 (review)) the editors may rely on you to tag others working in this space & to announce when you believe all interested parties have had an opportunity to comment on this.

• Once you do that (or if we notice that "enough" time has gone by) we would mark this for final review & possible merge at an upcoming CIP meeting.

[paweljakubas]

on my side, from this position, I might only kindly ask @perturbing or @iquerejeta and his team or IO Research team (@dkaidalov, @kitounliu, ...) to take a look. What is important here is that components of the system are well-established (no new cryptography here), the composition of them is my humble contribution. Of course, I am constantly polishing the system and might try to send the paper to peer-reviewed journal at some point. Also PQ is conjuctured not proven (yet) which I honestly underline.

[kitounliu]

@paweljakubas Thanks for your work. While NovaSlim looks promising, it is still under development and there seems to be several major gaps:

1. The headline proof size is not comparable to sound systems. The 0.4–2.5 KiB slim proof omits exactly the components (PCS openings, fold verification, norm proofs) that cost bytes. Closing these gaps is estimated to have (with transparent setup): ~5-12 KiB classical proof, ~30-100+ KiB PQ proof.
2. The verifier does not yet establish soundness. verify_slim checks sumcheck round consistency, Fiat–Shamir re-derivation, and a zero final claim, but never evaluates the circuit's A/B/C MLEs at the random point or opens the committed Z/E there, and never re-verifies the fold (the bundle carries only the final instance). Since relaxed R1CS with a free E is trivially satisfiable, acceptance currently attests honest pipeline execution, not knowledge of a valid witness. An all-zero-polynomial transcript passes against any bundle.
3. "Hash" and "SIS" are the same assumption. The Hash commitment is c = A·v with Blake2b as a PRF for the matrix entries: Ajtai/SIS in disguise, not hash-based binding. The README's "post-quantum" label for
   Hash inherits the same missing-norm-enforcement caveat currently flagged only for SIS.

Overall, in our PQ migration plan I still lean toward positioning the ZK-proof path as a fund-recovery mechanism (preferably verified by a Plutus contract) for use once classical signatures are disabled on Cardano, rather than as a day-to-day signing scheme.

[paweljakubas]

hi @kitounliu

Thank you for the precise and kind critique. I have revised the paper (and the implementation roadmap) to address all three points head-on.

1. Headline proof size is not comparable to sound systems
   You are right. The 0.4–2.5 KiB figure is a batch-proving size that omits the components any sound system must carry (PCS openings, fold verification, norm proofs).
   What changed now: The abstract now leads with a caveat, and a new §5 ("Honest sizing and remaining gaps") gives closed-gap estimates: ~5–12 KiB classical, ~30–100+ KiB post-quantum. These are competitive with Spartan and LatticeFold+, but they are no longer buried in fine print.

2. The verifier does not yet establish soundness
   You are right. verify_slim checks sumcheck consistency, Fiat–Shamir re-derivation, and a zero final claim, but it never evaluates the circuit MLEs at the random point, never opens the committed witness/error, and never re-verifies the fold. Because relaxed R1CS has a free error vector $E$, an all-zero transcript passes against any bundle.
   What changed now: §5.2 documents this gap explicitly. The paper now states that the guarantee is batch-proving knowledge soundness only: the prover is trusted during folding, and acceptance attests honest pipeline execution, not knowledge of a valid witness under an untrusted prover.

How I am going to fix it: The roadmap targets a two-step hardening:

• 0.3.0 — Add az_r, bz_r, cz_r, er_r to the Rust slim proof and verify algebraic consistency (az_r·bz_r − u·cz_r − er_r == final_claim). This prevents the trivial all-zero attack and already exists in the Aiken verifier.
• 0.3.0 — Three extra sumchecks proving az_r, bz_r, cz_r are the correct matrix-vector product evaluations at the random point. This restores knowledge soundness under an untrusted prover. Estimated honest size: ~3–5 KiB for Ed25519 (still under Cardano's 16 KiB limit).

3. "Hash" and "SIS" are the same assumption
   You are right. The Hash commitment computes $c = A \cdot v$ where the matrix entries are derived via Blake2b. This is exactly Ajtai/SIS; the "Hash" label refers to the PRF derivation method, not to a separate hash-based binding mechanism.
   What changed now: The paper now states explicitly that Hash is "operationally SIS/Ajtai in disguise." The missing-norm-enforcement caveat that applies to SIS applies equally to Hash: neither gives a post-quantum guarantee under adversarial witnesses without additional range proofs.

On the QROM work
Today's proofs are deliberately layered on top of a classically sound protocol. They harden Fiat–Shamir and extraction against quantum adversaries, but they do not close the classical verifier gap. The sequence is: first close the gap (0.3.0), then the QROM theorems lift the completed protocol to the post-quantum setting.

I appreciate the rigor of this feedback — it made the paper materially more honest. The revised version will be in the repo soon.

[paweljakubas]

@rphair I will need several weeks to revise the code, paper, etc. I will return here when I am ready. So please be patient, we might have something useful in the end.

@kitounliu thank you once again for taking a look and your meritocratic remarks 💎
I plan to adopt all suggestions and, when ready, ask kindly to have a look again! 🙇

[rphair]

thanks @paweljakubas & I'm only applying the Waiting for Author tag to reinforce that review would be best to continue after you've made your planned revisions... it won't create any prejudice to close this PR especially with your explicit comment above & please take all the time you need. 🙏