Constant DEFAULT_PIX_POLYS_PER_SSA 

pub const DEFAULT_PIX_POLYS_PER_SSA: u16 = hopr_protocol_pix::DEFAULT_POLYS_PER_SSA; // 8_192u16

Default number of polynomials (“SSA parts”) a single SSA is split into.

This is the single source of truth for the Entry-side generator dimension (PixGlobalConfig::num_ssa_parts) and for the Exit-side acceptance policy (IncomingSessionPixConfig::quota_range). Both must be derived from it so the two cannot drift apart: the Exit computes the offered quota as polys × (shares + surplus) × PAYLOAD_SIZE and rejects the Session if it falls outside its configured range, so a hard-coded range that no longer matches the dimension defaults makes every PIX Session fail to establish.

Choosing the split

For a fixed useful-share count U = polys × threshold the product is pinned, so the split between the two is free — but the costs scale differently, and dropping the non-constant coefficient commitments (see hopr_protocol_pix::SsaPartCommitment) changed which way they pull:

• Commitment wire volume and Exit ingest are one commitment per polynomial — linear in polys, and formerly polys × threshold. Ingest is dominated by point decompression plus the cofactor-8 subgroup check.
• Reconstructor commitment memory is likewise polys, no longer U.
• Share verification is one scalar multiplication per polynomial, not O(threshold) per share. It used to be U × threshold and is now simply polys.
• Interpolating a polynomial is O(threshold²) field operations, and there are polys of them — U × threshold, linear in threshold, and it is field arithmetic rather than curve arithmetic.
• Detection of a dishonest Entry takes threshold return packets, since a share set is only checked once it interpolates.
• On the Entry, SsaShareGenerator::next_share evaluates a threshold-wide polynomial by Horner for every share it emits — U × threshold again. This is much the smaller of the two per-share terms, but it is not zero, and describing the Entry as threshold-free (as this list once did) is wrong.

So raising threshold (and lowering polys) buys a proportionally smaller commitment phase at the cost of more interpolation, later fault detection and more Entry evaluation.

Both sides have since been measured, and 8192 × 64 stands — see hopr_protocol_pix::DEFAULT_POLY_THRESHOLD for the tables. The objective is Exit reconstruction capacity, because the Exit serves 10–30 clients while an Entry serves only itself: on that measure the deployed threshold is within 0.4 % of the optimum, and the fixed per-polynomial cost the Exit amortises over threshold shares means a lower threshold is worse, not better. Summing Entry and Exit per-share cost instead would favour 48 by about 3 %; that reading is recorded there and deliberately not acted on.

The quota is fixed by polys × (threshold + surplus), so the split can be re-tuned without touching session negotiation as long as that product holds.

Why this is an alias

The generator that produces the shares lives in hopr-protocol-pix and carries its own defaults, so the split existed as two independent literals — and they drifted: this side was re-tuned to 8192 × 64 while the pix crate stayed at a threshold of 128, which made hopr_protocol_pix::SsaGeneratorConfig::default imply a 1.01 GiB quota, outside the very range derived below. Four benchmarks had grown comments explaining which of the two to believe. Aliasing removes the choice.