Governance capture

Every other class has a moment where something is defeated: a check skipped, a state read mid-update, a signature accepted that should not have been. This one has no such moment.

A proposal is submitted. Votes are cast according to the rules. The threshold is met, the delay elapses, the proposal executes. Every step is the system working, and at the end of it the treasury has a new owner or the fee recipient is an address nobody recognises.

In plain terms: the attacker did not break the governance. They used it. Which means a review cannot find this by looking for a defect, and has to ask a different question — what the rules permit, and what it would cost someone to satisfy them.

The acute version, and the one with a clean fix.

If voting weight is read at the moment a vote is cast, that weight can be acquired for the length of one transaction. An attacker borrows the governance token, votes with it, and returns it before the transaction ends. The proposal passes with capital that was never theirs and is gone before the vote is counted twice.

Flash loans made this cheap, but lending markets with deep governance-token liquidity achieve the same thing over a longer window and without the single-transaction constraint.

The fix is a snapshot: fix voting weight at a block before the proposal existed, so that acquiring tokens after a proposal is visible buys nothing. In plain terms: the vote should be decided by who held the token when nobody knew the question, not by who holds it once the answer is worth money.

A snapshot removes the borrowing attack and leaves the economic one standing.

Voting power remains purchasable, simply earlier and more slowly. An attacker who accumulates before proposing pays market price for influence and then uses it legitimately. Nothing in the mechanism distinguishes that from a large holder with a genuine view.

Delegation concentrates the same problem without a purchase. Where most holders delegate and few delegates hold most of the voting weight, the practical quorum is a handful of parties, and compromising or persuading them is cheaper than buying the float.

And vote markets make influence rentable without transferring the asset: a holder is paid to vote a particular way, which is legal, visible, and not something a contract can detect.

In plain terms: a snapshot fixes a timing bug. It does not make voting power expensive, and expense is what the design is relying on.

These two parameters are usually set once at launch and rarely revisited, and both fail in either direction.

A quorum set too low means a proposal passes with a holding that a motivated party can assemble. A quorum set too high means nothing passes at all, which sounds safe until an emergency requires action and the protocol discovers it cannot act.

A delay too short means a hostile proposal executes before anyone can respond. A delay too long means legitimate responses arrive after the thing they were responding to.

The pairing is what matters. A low quorum with a long delay is survivable, because the delay is the defence. A low quorum with a short delay is a protocol that can be taken in an afternoon by anyone willing to buy the float.

This is the question that actually determines the exposure, and it is asked least often.

Governance is a role, and like any role it has a capability surface. If a passed proposal can upgrade the implementation, it can do anything the protocol could ever do. If it can change the fee recipient, move treasury funds, or alter a collateral parameter, each of those is a route to extraction that does not require touching the code at all.

A well-bounded design separates them: parameter changes within pre-set limits execute on a short delay, anything that touches funds or code requires a longer one, and some things are not reachable by governance at all.

In plain terms: the defence is not only making a hostile proposal hard to pass. It is making sure that a passed proposal cannot reach the funds in one step.

A proposal has a human-readable description and a payload of calls. Voters read the first and the protocol executes the second, and nothing enforces that they correspond.

A payload that upgrades a contract to an implementation nobody has reviewed is indistinguishable, in the voting interface, from any other parameter change. The address is a hex string, and verifying what it contains requires effort that most voters will not spend.

In plain terms: a governance process is only as sound as the proportion of voters who read the calldata, which is typically very small. Where a delegate or a committee performs that check, it is a real control and worth naming as one.

Six questions. The first two are parameters, the rest are about what those parameters are protecting.

Is voting weight read at vote time or at a snapshot taken before the proposal existed?

What holding is needed to reach quorum, what would it cost to acquire at current liquidity, and what would a successful proposal be worth?

What can a passed proposal reach — parameters only, treasury, or the implementation itself?

How long is the delay between passing and executing, and who is alerted when something is queued?

How concentrated is delegated voting power, and how many parties would need to agree in practice rather than in theory?

Who verifies that the payload matches the description, and is that a named responsibility or an assumption?