Skip to free scan
critical

Governance Attacks in Smart Contracts

April 1, 2026Updated September 15, 2026
Chainsethereumarbitrumbaseoptimismpolygon
Review toolsechidnahound-ai

Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.

A governance attack uses the rules or privileges of a governance system to produce an unauthorized or economically unsafe outcome. The defect may be technical—a broken snapshot, replayable vote, or executable proposal bypass—or economic, such as voting power that can be borrowed cheaply enough to control a decision.

Beanstalk documents that its April 2022 attacker used a flash loan to compromise on-chain governance and steal roughly $77 million in non-Bean assets; governance was then moved to a community multisig. The protocol's own disclosure is a useful case study without relying on inflated headline valuations.

ATTACK CONDITIONS

Review how voting power is acquired, fixed, counted, and released. Reading an account's current token balance during voting can make power transferable or borrowable after a proposal is known. Historical checkpoints reduce that risk only if the snapshot time, delegation rules, and proposal lifecycle are coherent.

Then trace proposal execution. A passed proposal often may be executed by anyone; public execution is not itself a vulnerability. The important checks are that the proposal succeeded, met quorum, waited through any required delay, has not executed before, and invokes exactly the committed targets, values, and calldata.

OpenZeppelin's Governor documentation exposes proposal snapshots, historical vote queries, timepoint-based quorum, and timelock-controlled execution. Those primitives still require protocol-specific thresholds and authority design.

REVIEW AND TEST

Model the complete state machine: propose, vote, cancel, queue, execute, expire, and upgrade. Test the same voter transferring or delegating around the snapshot; flash-borrowed voting units; late quorum; duplicate voting; signature replay; canceled or expired proposals; and direct calls to functions intended to be governance-only.

For every executable proposal, enumerate reachable privileges: treasury transfers, upgrades, oracle changes, token minting, pausing, role administration, and timelock reconfiguration. Check whether emergency actors can bypass governance and whether governance can unexpectedly revoke its own recovery path.

MITIGATIONS AND LIMITS

  • Use historical voting checkpoints and a voting delay that fixes power before votes begin.
  • Set quorum and proposal thresholds from the protocol's concentration and participation data, not copied defaults.
  • Queue successful proposals through a timelock long enough for users to inspect and react.
  • Bind execution to the exact proposal hash and make execution single-use.
  • Protect signed ballots with domain separation and nonces.
  • Separate emergency powers, document their limits, and test their revocation and recovery paths.

Snapshots and timelocks do not eliminate governance capture. Concentrated delegation, bribery, compromised signers, or a malicious majority can still act within valid rules.

Firepan can review submitted contracts for checkpoint use, lifecycle checks, privileged call paths, and replay protection. It cannot infer community intent, token-holder coordination, off-chain voting integrity, or whether economic thresholds are adequate without governance and market context.

FREQUENTLY ASKED QUESTIONS

Does a timelock prevent malicious governance?

No. It creates an observation and response window; it does not make a malicious proposal invalid.

Is permissionless proposal execution unsafe?

Not when the contract independently enforces proposal success, queueing, delay, payload integrity, and one-time execution.

Firepan

Scan Your Contracts Now

Run a free scan — results in minutes, no credit card required.

Run Free Scan →