“i assumed” so you haven’t checked the code, nor the math, haven't verified the paths, and are a recreational what, assumer llm user public yapper? which puts us on roughly the same level of technical ability. you only need the paper and the node to put it in the same slop machine chat, not to actually read it. so i will also respond with my slop machine to you for the last time, and if @lambda0xE wants to correct anything, he will, otherwise check back later He is not right that the PoC “doesn’t use hypergraphs.” The code literally constructs H as a sparse incidence/parity structure: m_bits as vertices, n_bits as hyperedges/columns, each column choosing h_col_wt rows. See gen_H in include/pvac/crypto/matrix.hpp:190-216, and tests/test_hg.cpp:97-106, which prints m (vertices), n (hyperedges), and k (col weight). “Reduction to hypergraphs” is the wrong phrase. The ciphertext structure is hypergraph-based; the reduction/security direction is toward LPN / syndrome / check-residual hardness, not “reduction to hypergraphs.” In code, sigma_from_H builds each edge syndrome as XOR of selected H columns plus noise: include/pvac/crypto/matrix.hpp:266-302. The critic’s “addition is concat” is technically true but rhetorically misleading. ct_add appends layers/edges and offsets layer IDs, yes: include/pvac/ops/arithmetic.hpp:165-187. But in an additive masked-carrier / abelian-group representation, concatenating signed carriers is a normal way to represent a sum. “Concat” does not imply fake encryption or plaintext math. The “multiplication is plaintext multiplication” claim is wrong in the important sense. ct_mul does multiply field elements, but they are public masked layer aggregates, not plaintext messages. It takes PubKey, Cipher A, Cipher B; no SecKey. The unmasking happens only in dec_values, where secret-derived Rinv is used: include/pvac/ops/decrypt.hpp:46-74. So the accurate description is: public masked aggregate multiplication repacking into new product-layer edges, not plaintext multiplication. The growth criticism is fair for this PoC. ct_mul creates LA * LB product layers, and test_compactness.cpp:62-68 explicitly asserts that. So yes, the PoC is naive for multiplicative depth and does not expose production relinearization/bootstrapping/reduction. So the correct answer is not “he is right.” It is: He found that the public PoC is intentionally naive and does not include the production optimizer. He did not prove there are no hypergraphs, no HFHE structure, or plaintext multiplication. Those claims are wrong based on the code. The arithmetic accumulator can be read separately from the syndrome layer, but the ciphertext object and security/check-residual structure are built around the hypergraph incidence matrix.