Exactly what is and is not proven here. First: the proofs verify a φDSA transcript variant (φDSA-algfs): the Fiat–Shamir challenge is derived with the suite's field-native algebraic sponge instead of SHAKE-256, because SHAKE is not arithmetizable at any size. Production φDSA keeps SHAKE-256 end to end; the variant changes the challenge derivation only, and its Fiat–Shamir soundness rests on the algebraic hash, which is experimental. The demo variant is also hint-free (the commitment w travels uncompressed), placing its forgery bound in the norm-below-q SIS regime the parameter derivation certifies. Second: the lattice relation and the norm bound are proof-carried; the challenge equality and the NTT consistency of the public signature are recomputed natively by the verifier from public data, which is sound precisely because that data is public. Third: this statement attests a public signature's verification; it does not hide the signature. We have measured exactly what a hidden version would take: the relation and norm proofs run in zero-knowledge today, and the check tying the two together survives hiding, but the fingerprint step that binds the signature to the message would then have to run inside the proof at roughly 264 times the zero-knowledge size budget — a different proof structure we have not built. So the hidden-authorization statement that ships today is the hash-leg one-time-signature proof, verified beside it below. Fourth: the proofs were generated natively (the prover is multi-threaded; this host cannot serve the COOP/COEP headers browser threads require). Verification runs live here in the thread-free verifier module.

Independence, precisely. "Independent legs" is true of the hardness assumptions (hash vs. Module-LWE) and false of the implementation. φSign's security is entirely φHash. φCipher's key, above, no longer traces to a bare φHash call — but the memory-hard KDF's own last step is still one φHash call. φKEM here is instantiated with φHash as its extendable-output function (the suite's own choice — the KEM core is hash-agnostic behind an injected XOF, and an in-suite SHAKE-256/FIPS-202 instantiation, validated against the NIST test vectors, works identically against the same Module-LWE assumption), so its key-establishment path also depends on φHash behaving as a random oracle, not only on Module-LWE — a stronger ask than "produces good avalanche," and the gap between those two turned out to matter (see below). The one primitive on this page with zero φHash dependency, assumption or implementation, is φDSA — it uses SHAKE-256 throughout. Read plainly: φHash is a shared component with suite-wide blast radius, not a firewall between the two legs.

The φHash-XOF finding, and the fix. The φDSA callout below admits that φHash pegs ~6% of ExpandMask's coefficients at the boundary vs. ~0.02% expected. Our hardening review asked the question that admission raises: is that a routing decision, or a fact about φHash? It's the latter, and it doesn't touch φHash's core diffusion. Past ~196 bytes, φHash falls back to a "chain extension" step that applies only the linear Triveni lift/unlift — no S-box, no phyllotaxis mixing, no round constants — repeatedly, self-referentially. In this suite's own eigenvalue-classification framework (phi_types/identity_classification.hpp): a Fibonacci-weighted lifting predictor is built to be near-identity — its natural home is the marginal Floor gate (γ, λ≈+1), not the contracting Entropy gate (e, |λ|<1) a mixing function needs. Iterating a Floor-class map where an Entropy-class one belongs doesn't erase structure; it preserves it. Measured directly: at chandas=8 (φKEM's XOF request size, chosen to amortize φHash's per-call cost), the first 196 bytes are statistically clean — mean 127.59, variance 5459.8 against an ideal 127.5 / 5461.25 — and the remaining bytes show a byte position frozen constant across 4,000 independent seeds. Fix: capped the XOF's request size at chandas=3 (123 bytes) — the largest chandas that provably never reaches the extension path for any input, since one block's full pipeline always yields exactly 196 detail bytes regardless of message length. Costs ~11× more φHash calls per XOF request; correctness over a microbenchmark. Re-measured clean at the new tier (mean 127.60, variance 5458.6, saturation back to the expected 6.23%), and verified across phi-lattice-cpp's full test suite (KAT anchors re-pinned, decode-failure bound unchanged at δ=2⁻²⁸⁴·⁷) and phi-crypt-cpp's φPQC/adversarial/AKE suites — all green. φHash's core algorithm is unmodified; every chandas 0-2 consumer (φSign, φCipher, φDSA's internals, addresses/commitments) and phi-currency's independent mining-difficulty use of chandas were both out of scope and are both untouched.

Reading the hash-based rows, and why they are not birthday-limited. φHash's output width sets the classical search space; the post-Grover (quantum) figure is half the classical bit count, the standard quadratic Grover speedup, computed live from the actual digest length above. These are (second-)preimage numbers: classical n, quantum n/2. The obvious objection is the birthday bound — plain collision resistance is only n/2 classical, so shouldn't that be the real limit? For φSign it is not, and this is by construction. φSign is SLH-DSA / SPHINCS+ (FIPS 205): every hash call is tweaked by its position (layer, chain index, step) and the message digest is randomized by a per-signature R, so an attacker never gets to run an offline, un-targeted birthday search. The relevant property is target-collision resistance (equivalently second-preimage): find a collision for a target fixed after the tweak, which costs n classical and n/2 quantum, not n/2 and n/3. Avoiding the birthday penalty is the entire reason SPHINCS+ hashes this way. So the table's figures are the operative ones for φSign: tier 0 is 232 classical / 116 quantum, tier 2 is 608 / 304. (Plain, un-tweaked collision resistance would matter to a bare hash used as a raw digest — there tier 0's 232-bit output is a 116-bit birthday target — but φSign is not used that way.) One caution on NIST categories: they are defined by the full gate-level cost of key search on AES or collision search on SHA, not by search exponents alone, so placing tier 0 at Category 3 and tier 2 past Category 5's 232-bit quantum floor is an exponent comparison, not a certified category claim.

φKEM (φ-KEM-304). Module-LWE, ring degree n=512, module rank k=3, q=3329, η=3 (CBD noise). On n=512 vs. q=3329: q−1=3328=2⁸·13 gives only a primitive-256th root of unity, so a full NTT (as Kyber runs at its own n=256) isn't available at double that degree. The actual transform is a hybrid/incomplete NTT — 128 residue rings of degree 4, one split-level less than Kyber's own 128-degree-2 leaves, for the same structural reason Kyber's NTT is itself incomplete at n=256. Not a discrepancy; one documented consequence of doubling the ring degree at a fixed q. On the estimate: classical core-SVP β≈1462 against a lattice dimension of ≈1536 — β this close to the full dimension is a regime where the core-SVP heuristic is known to be less reliable, so treat ≈427-bit classical as the headline figure and ≈387-bit quantum (the 0.265β constant) as a secondary, deliberately conservative data point — even the Kyber team treats that constant as a pessimistic lower bound assuming implausible quantum RAM, not an operative security level. One more caution on the measuring sticks: core-SVP is a deliberately conservative lower-bound model, not a gate-level cost model, while NIST categories are defined by the full cost of attacking AES — so the precise claim is that both figures clear the suite's own 304-bit floor and Category 5's 232-bit quantum bar under the core-SVP model, not that a certified gate-count comparison has been made. On the Reed–Muller reconciliation: RM(1,3) is the one φ-native load-bearing element inside encode/decode, and changing it changes more than hardness — it changes the decryption failure rate (DFR) that the FO transform's CCA2 argument depends on directly. The spec's own bound is δ ≤ 2⁻¹²⁸; RM(1,3) computes to δ = 2⁻²⁸⁵ against a no-reconciliation baseline of δ = 2⁻⁶⁹ that fails the bound outright — "computes to" and not "measures to": this is a closed-form convolution of per-coefficient error distributions, exact under that model, not sampled. The team's own review notes list the open question plainly: "is δ ≤ 2⁻¹²⁸ correct under a worst-case, not average-case, noise model?" — unresolved, not glossed over. The CCA2-relevant cost is also finding one failing ciphertext by directed search, not the bulk failure probability (failure boosting); with a 157-bit margin over the 2⁻¹²⁸ bound that's very likely still fine, but it hasn't been separately analyzed here. The code is load-bearing for CCA2 soundness, not merely a rate optimization, and this is exactly where a Kyber-derived scheme stops being Kyber.

φDSA. Fiat–Shamir with aborts (the ML-DSA algorithm) over the suite's shared proof-system field (N=256, Q=1342832641, k=l=9, η=7, τ=60) — one field across the proof system and the signature, so signatures can be verified inside recursive proofs natively. This uses SHAKE-256 throughout, not φHash — φHash's output isn't uniform enough for the rejection-sampling step (measured: ~6% of mask coefficients pegged at the bound vs. ~0.02% expected under a uniform XOF; see "The φHash-XOF finding, and the fix" above — the same defect, now fixed for φKEM's own use of φHash, but φDSA's rejection sampling has zero tolerance for any bias, so SHAKE-256 remains the correct choice regardless), so φDSA's hardness has zero φHash dependency, unlike every other primitive on this page. The parameter set is derived from first principles and modeled, under the same conservative estimator, to dominate ML-DSA-87 — NIST FIPS-204's own Category 5 set — on every axis (an estimated ≈255-bit quantum forgery floor, clearing Category 5's 232-bit bar), with that estimate in the regime where the conservative bound is provably valid rather than merely asserted. Not byte-conformant FIPS-204 (own encodings, self-consistent against its own KATs — this proves the implementation matches this team's own spec, not that the spec itself has been independently reviewed; it is not ACVP validation) — the estimated margin is above the standards one; the wire format is the suite's own.

Verify-in-proof. The shared field lets signature verification run inside recursive proofs — that is this page's first tab, where the proofs are verified live. The design detail worth keeping in the security picture: the naïve "run the verifier in a circuit" approach was measured and rejected (SHAKE-based Fiat–Shamir is not arithmetizable at any size), so the in-circuit path derives its challenge with the field-native algebraic hash while ordinary signing keeps SHAKE-256.

The WOTS width, measured against itself and revised. φSign's chain width formerly stood at 13 while its digit extractor produces 3-bit digits, which meant an 8-value digit space at a 13-value chain cost. The width sweep (w ∈ {8, 13, 16}, real hash, self-checked against the production parameter and size formulas) measured at the top tier that w=8 matches that configuration's security and signature size exactly with 38% fewer hash calls (1,665 vs 2,705 per WOTS keygen). The parameter has been revised to w=8 accordingly, and every timing and size on this page reflects the revised width; the refuted configuration stays in the published table for the record. This is the suite's standing discipline: structural choices are measured, and when a measurement refutes one, the parameter moves and the refutation is kept public.

Mobile. Five React Native packages bridge these into the mobile wallet over JSI: react-native-phi-crypt (φCrypt itself), react-native-phi-sqlite (phi-sqlvfs), react-native-phi-tcp (the TLS-over-TCP fallback), react-native-phi-rpc-client (phi-rpc-cpp), and react-native-phi-zk (the ZK statement library). None are published to npm yet — install from the monorepo directly.