Skip to content
Financial Context Wiki

Governance attack

A governance attack acquires enough voting or execution power to pass harmful protocol changes through the authorized governance path.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A governance attack acquires enough voting, proposal, cancellation, or execution power to make a protocol perform a harmful action through its authorized governance path. The calls may satisfy every smart-contract check. The failure is that the governance system made control cheaper, faster, or less accountable than the value placed under that control.

Voting power can come from owned tokens, delegated votes, borrowed tokens, bribed voters, compromised keys, or privileged governor and timelock roles. Historical vote checkpoints can stop one balance from voting repeatedly after transfers and can defeat borrowing that occurs after the snapshot. They do not prevent votes acquired before the snapshot, concentrated delegation, weak quorum rules, or a compromised executor.

Not every unpopular proposal is an attack. Governance exists to change rules. The security question is whether an actor obtained disproportionate or temporary control, concealed or misrepresented the executable effect, or crossed a publicly stated authority boundary. Review the actual calls, the cheapest path to decisive power, the time available to respond, and the maximum value or control reachable after execution.

How it works

  1. Map authority from the voting asset through delegation and checkpoints to the governor, timelock, proxy administrator, treasury, emergency roles, and final target contracts. A governance interface is not the permission graph.
  2. Pin the chain, contract addresses, implementation versions, clock mode, snapshot, proposal threshold, quorum calculation, vote-counting rule, voting delay, voting period, queue delay, expiry, cancellation rights, and execution roles.
  3. Reconstruct voting power at the exact snapshot with historical reads such as getPastVotes. Group addresses controlled or coordinated by one actor, and separate token balance from delegated voting weight.
  4. Decode every proposal action: targets, values, calldatas, and descriptionHash. Resolve proxies and selectors, inspect batched calls, and compare the executable payload with the human-readable description.
  5. Reproduce proposal creation, voting, queuing, and execution on a fork. Diff balances, ownership, roles, allowances, implementations, oracle settings, collateral parameters, and any newly reachable function before and after execution.
  6. Price the cheapest control path across spot purchases, lending markets, flash liquidity, over-the-counter loans, delegation, vote incentives, derivatives hedges, key compromise, and privileged-role capture. Include fees, slippage, collateral, unwind losses, and the time capital must remain committed.
  7. Test the response path. Confirm who can cancel or pause, what evidence they need, whether the action fits inside the delay, where users obtain canonical notices, and how governance resumes without leaving an unbounded emergency key.

A typical token governor moves through proposal, delay, snapshot, voting, succeeded or defeated, queue, timelock, and execution states. The exact rules are implementation-specific. Under ERC-5805-style checkpoints, delegated voting weight can be queried at a past timepoint; the clock may use block numbers or timestamps. Reviewers must use the deployed clock and configuration rather than assuming that a displayed duration or token balance is authoritative.

A timelock creates a minimum notice window; it does not judge intent or make a payload safe. Its proposer, executor, canceller, and administrator roles are themselves critical. If an external administrator can bypass the delay, the timelock is not the final authority. If nobody can cancel a queued malicious action, detection alone does not stop execution.

Worked examples

  • Low-turnout capture. A protocol has 100 million tokens in total and 40 million circulating. A proposal needs 2 million participating votes, more for than against, and a 6-hour timelock. An actor buys 1.2 million votes and receives 1 million delegated votes. Against votes total 0.8 million, so the actor’s 2.2 million for votes pass a call that can transfer 15 million USDC from the treasury. The actor controls 2.2 / 100 = 2.2% of total supply and 2.2 / 40 = 5.5% of circulating supply, but 2.2 / 3.0 = 73.3% of votes cast. The binding security parameters are turnout, delegation, quorum, payload authority, and delay, not a 51% slogan.
  • Snapshot boundary. If voting weight is read from a current balance and execution is immediate, one transaction can borrow tokens, vote, execute, and repay. Reading immutable historical voting weight from a timepoint before voting prevents that same-transaction route. It still permits capital borrowed or delegated before the snapshot, so the proposal delay and observable vote-acquisition window remain part of the defense.
  • Beanstalk on April 17, 2022. Beanstalk Farms reported that an attacker used a flash loan to exploit the protocol’s governance mechanism and stole approximately $77 million in non-Beanstalk user assets. The incident demonstrates that flash liquidity is financing, while the decisive weakness is governance allowing temporary economic power to reach valuable execution permissions.

Risks and controls

  • Concentrated effective power. Measure delegates and coordinated entities, not just holder addresses. Publish the top-delegate share, participation distribution, and dependencies on foundations, custodians, market makers, and delegates.
  • Weak proposal and quorum rules. Compare thresholds with active voting power, borrowable supply, and treasury exposure. Use separate requirements for routine parameters and high-impact upgrades or transfers.
  • Unsafe snapshots. Use immutable historical checkpoints and a clock shared by the voting token and governor. Leave enough delay before the snapshot for abnormal accumulation or delegation to become observable.
  • Late or surprise voting. Consider a minimum voting extension when quorum arrives near the deadline, and monitor large delegation changes throughout the proposal lifecycle.
  • Opaque payloads. Publish decoded calls and independent simulations. Split unrelated high-risk actions so one benign item cannot disguise an administrator change or treasury transfer.
  • Insufficient execution delay. Scale timelocks to impact and make queued operations public. A useful delay must accommodate review, alerts, cancellation or pause, and a credible user exit path.
  • Overpowered emergency roles. Scope guardians by function, value, duration, and review standard. Disclose members, thresholds, rotation, evidence requirements, and the process for removal and resumption.
  • Unreviewed upgrade paths. Follow proxy administrators, beacons, implementation initializers, metamorphic deployment paths, and contracts that can be upgraded after receiving authority.
  • Cross-chain execution risk. Authenticate the source governor and message, prevent replay, constrain target functions, add a local delay for high-impact calls, and define behavior during bridge failure or suspension.
  • Inadequate monitoring. Alert on proposal creation, vote concentration, quorum changes, queue and cancellation events, decoded state changes, implementation upgrades, role grants, allowances, and treasury outflows.
  • Broken incident response. Rehearse malicious proposals, signer loss, front-end compromise, bridge outage, and false-positive pauses. Record who decides, communicates, signs, verifies, and safely restores operation.
  • Unbounded value at risk. Limit per-action and rolling treasury transfers, upgrade scope, minting, collateral changes, and approvals. Governance should not automatically receive unlimited authority merely because a vote passed.

The review output should be a reproducible control ledger: each privileged action, its controller, the votes or keys required, earliest execution time, cancellation path, monitoring source, and maximum reachable value. Recalculate it after upgrades, token distributions, delegation changes, bridge migrations, or major shifts in liquidity and participation.

Common misconceptions

  • “An attacker needs 51% of total token supply.” Most systems depend on delegated or participating votes, quorum, and a passing rule. Decisive control may cost far less than half of total supply.
  • “Snapshots eliminate governance attacks.” They stop particular forms of vote reuse or last-moment borrowing. They do not stop earlier borrowing, purchases, delegation concentration, bribery, or privileged-key compromise.
  • “A passed on-chain vote proves legitimacy.” It proves that deployed code conditions were met. It does not prove that the description matched the payload or that the outcome was safe, fair, or within public commitments.
  • “A longer timelock is always safer.” A delay is useful only when monitoring, analysis, cancellation or pause, communication, and exit can occur within it. Excessive delay can also impair urgent maintenance.
  • “Adding a security council solves governance risk.” A council can reduce response time but creates another control path. Its authority, accountability, removal, and failure modes must be included in the same threat model.

Sources

Navigation

Search the wiki...