PQ spending for Stealth Address Protocol

What it carries beyond the summary

The summary names the two spending constructions and the ML-DSA-44 precompile cost, but omits the numbers and constraints that decide whether either is deployable today. Those are the substance.

HSAP cost and the aggregation path

HSAP replaces signing with a ZK proof of P = H_pay(H_key(k), r) ∧ T = H_auth(k, r, m). The page states this costs ~7M gas per spend at ~300,000 R1CS constraints, extrapolated from a WHIR-EVM-Verifier benchmark — a full PQ zk-SNARK/STARK verification on every spend. That is the reason to treat HSAP as not-yet-practical.

The page also points at what changes that: EIP-8288 (Frame Type for PQ Sig and STARK Aggregation) proposes recursive STARK-based aggregation via an EIP-8141 frame mode. If leanStark is used, aggregation amortizes verification down to an additional ~30K gas validation fee. So the roadmap is 7M-gas-per-spend now → ~30K amortized if the aggregation EIPs land.

The author flags that the zk construction resembles zkWormhole (insecure if P/K is an Ethereum address), but argues it doesn't apply here: funds go to a smart-account the sender legitimately funds, not a disconnected commitment.

SPIRIT's structural constraints

SPIRIT (from Post Quantum Fuzzy Stealth Signatures and Applications) is the ML-DSA/Dilithium variant. The page lists concrete deployment costs the summary skips:

• requires a globally shared matrix A (a fixed seed baked into the ERC) for unlinkability
• the master t must stay uncompressed
• the coefficient bound doubles from η to 2η, giving β' = 2τη; original SPIRIT also doubles γ₁ and γ₂ to control signing retries
• keeping standard mask widths therefore demands tighter signer rejection and a separate security analysis

HSAP construction specifics

Hashes are SHA-256 with distinct one-byte domain tags (H_key, H_pay, H_auth); KDF is HKDF-SHA256, 32-byte output, bound to a deployment domain D (scheme, chain, factory). Payment deploys a funded smart account at P = CREATE2Addr(F, C, I(C)) where C = H_pay(K, r); the account stores the full 256-bit C, a spend nonce, and a fixed verifier, and deployment failure reverts the payment.

Caveats

The author explicitly warns the gas figures "are likely to change" and asks readers to weigh the mechanism over the cost. Two acknowledged limits persist across all schemeId=6 variants: the sender and scanner both know r, so the construction must prevent spending from that knowledge alone; and sender-to-account plus subsequent spending links remain public — quantum-safe discovery does not buy sender anonymity.