DAO governance attacks: how flash loans and vote manipulation drain treasuries

In this article: How governance attacks weaponize legitimate protocol mechanics — flash loan atomicity, EVM opcode injection, quorum exhaustion — and the defensive architectures (timelocks, N-1 checkpointing, optimistic dual governance) required to secure DAO treasuries.

Flash loan atomicity and EIP-3156 manipulation

1// EIP-3156 flash loan lifecycle
2interface IERC3156FlashBorrower {
3    function onFlashLoan(
4        address initiator,
5        address token,
6        uint256 amount,
7        uint256 fee,
8        bytes calldata data
9    ) external returns (bytes32);
10    // Must return keccak256("ERC3156FlashBorrower.onFlashLoan")
11}
12
13interface IERC3156FlashLender {
14    function maxFlashLoan(address token) external view returns (uint256);
15    function flashFee(address token, uint256 amount) external view returns (uint256);
16    function flashLoan(
17        IERC3156FlashBorrower receiver,
18        address token,
19        uint256 amount,
20        bytes calldata data
21    ) external returns (bool);
22}

Forensic anatomy of governance exploits

Atomic hostile takeovers: Beanstalk Farms

1. Borrowed $1 billion in stablecoins (DAI, USDC, USDT) via an Aave flash loan.
2. Routed the capital through Curve Finance's 3pool to acquire 3Crv liquidity tokens.
3. Injected 3Crv into the BEAN3CRV-f pool, depositing the resulting tokens directly into Beanstalk.
4. Triggered the internal LibSilo.incrementBipRoots function, instantly recalculating vote weight and granting the attacker >78% of the total governance power.
5. Invoked emergencyCommit() in the same execution frame, bypassing community voting to execute BIP-18.

EVM opcode injection and bytecode deception: Tornado Cash and Build Finance

1// Simplified exploit sequence
2
3// Step 1: Attacker deploys "benign" contract at deterministic address
4contract Decoy {
5    function emergencyStop() external {
6        selfdestruct(payable(0));
7        // Erases all bytecode at this address
8    }
9}
10
11// Step 2: Community votes to approve the contract address
12// Step 3: Attacker triggers selfdestruct, erasing the contract
13
14// Step 4: Using CREATE2 deterministic deployment,
15// attacker deploys HOSTILE contract at the SAME address
16contract Hostile {
17    function execute() external {
18        // Mints 1.2M fake governance votes to attacker
19        token.mint(attacker, 1_200_000e18);
20    }
21}
22
23// Step 5: When timelock executes delegatecall to the "approved" address,
24// it now runs the hostile payload

Quorum exhaustion and oracle manipulation: Compound and Mango Markets

Game theory, Sybil vulnerabilities, and the financialization of voting

1Standard voting:  100 tokens → 100 votes  (cost: 100)
2Quadratic voting: 100 tokens → 10 votes   (cost: 100)
3
4Sybil attack on QV:
5  Split 100 tokens across 100 addresses
6  Each address: 1 token → 1 vote (cost: 1)
7  Total: 100 votes for cost of 100
8  → Quadratic penalty fully bypassed

Technical defense architectures and preventive modeling

Timelocks and temporal separation

1// OpenZeppelin GovernorTimelockControl pattern
2contract SecureGovernor is Governor, GovernorTimelockControl {
3    function _execute(
4        uint256 proposalId,
5        address[] memory targets,
6        uint256[] memory values,
7        bytes[] memory calldatas,
8        bytes32 descriptionHash
9    ) internal override(Governor, GovernorTimelockControl) {
10        // Execution is routed through TimelockController
11        // Enforcing mandatory delay (e.g., 48 hours)
12        super._execute(proposalId, targets, values, calldatas, descriptionHash);
13    }
14}

Block-level checkpointing (N-1 indexing)

1// ERC20Votes checkpoint mechanism
2function getVotes(address account, uint256 blockNumber)
3    public view returns (uint256)
4{
5    // Returns vote weight at historical block, NOT current balance
6    require(blockNumber < block.number, "Block not yet mined");
7    return _checkpoints[account].getAtBlock(blockNumber);
8}
9
10// Governor uses this for vote weight calculation
11function _getVotes(
12    address account,
13    uint256 blockNumber,
14    bytes memory /*params*/
15) internal view override returns (uint256) {
16    return token.getPastVotes(account, blockNumber);
17    // Flash loan tokens acquired at block N+10
18    // return vote weight of ZERO
19}

Real-time algorithmic verification

Governance security checklist

• Enforce timelocks (minimum 48 hours) on all executable proposals
• Implement N-1 block checkpointing via ERC20Votes for vote weight calculation
• Set quorum thresholds relative to total supply, not circulating supply
• Cap maximum governance power any single address can accumulate
• Require multi-sig execution for treasury operations above threshold
• Monitor for flash loan-sized token movements in governance contracts
• Validate proposal bytecode against deployed contract bytecode before execution
• Separate proposal creation rights from execution rights

Next-generation governance: optimistic dual structures

Bicameral separation of powers

Lido's escapement mechanism and "rage quit"

• 1% threshold (Veto signalling): If the Escrow balance reaches 1% of total stETH supply, it triggers an algorithmic suspension, pausing the execution of the LDO proposal via an elastic delay ranging from 5 to 45 days.
• 10% threshold (Rage quit): If the malicious action persists and the Escrow contract accumulates 10% of the stETH supply, the system triggers a permanent "Rage Quit" state. All protocol state updates are frozen, and the system opens an unalterable, cryptographically guaranteed exit route, allowing minority stETH holders to physically extract their authentic ETH backing before the malicious LDO proposal can execute.

1Lido Optimistic Dual Governance state machine:
2
3 ┌──────────┐   LDO proposal    ┌─────────────┐
4 │  Normal  │ ────────────────► │  Proposal   │
5 │  State   │                   │  Pending    │
6 └──────────┘                   └──────┬──────┘
7                                       │
8                           stETH deposit to Escrow
9                                       │
10                                       ▼
11                              ┌─────────────────┐
12                    < 1%      │  Escrow balance  │    ≥ 1%
13                  ┌───────────│   vs stETH       │──────────┐
14                  │           │   total supply   │          │
15                  ▼           └─────────────────┘          ▼
16          ┌──────────┐                            ┌──────────────┐
17          │ Execute  │                            │    Veto      │
18          │ Proposal │                            │  Signalling  │
19          └──────────┘                            │  (5-45 day   │
20                                                  │   delay)     │
21                                                  └──────┬───────┘
22                                                         │
23                                              Escrow reaches 10%
24                                                         │
25                                                         ▼
26                                                  ┌──────────────┐
27                                                  │  RAGE QUIT   │
28                                                  │  State frozen │
29                                                  │  Exit route   │
30                                                  │  guaranteed   │
31                                                  └──────────────┘

Conclusion

Get in touch

FAQ: DAO governance security

Glossary