Proposal Front-Running

An attacker can front-run the voting process itself by:

• Bribing voters using platforms like Hidden Hand or Votium to concentrate votes on their proposal.
• Timing the vote to end during low-activity periods.
• Submitting the execution transaction with a high gas fee the moment the voting period closes, beating any defensive actions from token holders who voted 'No'.

Many DAOs have inherent timing gaps that create attack surfaces:

• Voting Delay: The period between a proposal's submission and the start of voting. Attackers can monitor the mempool for proposals and front-run with a competing or malicious one.
• Timelock vs. Execution: If a passed proposal does not have a timelock (a mandatory waiting period before execution), it can be executed immediately, leaving no time for a community fork or other defensive measures.

Front-running is fundamentally a form of Maximal Extractable Value (MEV). Searchers and bots constantly monitor the public mempool for pending transactions. When a governance proposal submission is detected, they can:

• Bundle their own transaction to execute first.
• Sandwich the proposal with other actions to profit from anticipated token price movements.
• Use private transaction relays to submit their attack without public warning.

Protocols mitigate front-running through several key designs:

• Timelocks: A mandatory delay (e.g., 48 hours) between a proposal passing and its execution.
• Governance Gauges: Systems like veTokenomics that require long-term token locking for voting power, making hostile takeovers expensive.
• Multisig Guardians: A trusted committee with the power to veto or pause malicious proposals before execution.
• Snapshot Voting: Off-chain, gas-free voting to gauge sentiment before an on-chain transaction is ever submitted.

• MEV (Maximal Extractable Value): The broader category of profit from reordering, inserting, or censoring transactions.
• Flash Loans: A tool often used to temporarily acquire voting power for an attack.
• Governance Attacks: The umbrella term for exploits targeting decision-making processes.
• Forking: A last-resort community defense where users migrate to a new chain version that nullifies the malicious proposal's effects.

This attack exploits the proposal lifecycle. An attacker monitors the mempool for a pending governance transaction, decodes its intent, and submits their own transaction with a higher gas fee to execute first. This is possible because most DAO proposals are public on-chain actions, not private votes.

• Target Phase: The window between proposal submission and execution.
• Method: Uses gas price auctions to ensure transaction priority.
• Prerequisite: Requires the proposal's execution logic to be predictable and its outcome to have a monetizable impact on the market.

Front-running targets specific, high-value governance actions.

• Parameter Changes: Sniping transactions that adjust fees, rewards, or interest rates on a protocol.
• Treasury Management: Front-running a large token purchase or sale from the DAO treasury to profit from the resulting price movement.
• Contract Upgrades: If an upgrade includes a token mint or change to tokenomics, an attacker can position themselves before the change takes effect.
• Grant Approvals: Anticipating and trading around the announcement of a large grant to a project or individual.

A classic example occurred with Compound's Proposal 62. This proposal aimed to distribute COMP tokens to users of certain markets. An attacker identified the proposal before execution and:

1. Borrowed large amounts of the affected assets to become eligible for the COMP distribution.
2. Front-ran the execution to ensure their borrows were registered on-chain at the precise block.
3. Profited from the allocated COMP tokens, which exceeded their borrowing costs.

This incident cost the protocol millions in unintended token distributions and highlighted the risks of transparent, on-chain execution.

DAOs employ several techniques to reduce front-running risk.

• Timelocks: A mandatory delay between a proposal's approval and its execution. This removes the element of surprise, allowing the market to price in the change.
• Execution Privacy: Using Flashbots or similar MEV-protected relays to submit the execution transaction privately, preventing it from being seen in the public mempool.
• Schedulevuls: Breaking high-impact proposals into multiple, smaller steps to minimize arbitrage opportunities.
• Governance Minimization: Designing systems where critical parameters are less frequent targets, such as using algorithmic rate setters instead of governance votes.

Proposal front-running is a specific subset of Maximal Extractable Value (MEV). It falls under governance MEV, where value is extracted from the democratic processes of a DAO rather than from DeFi arbitrage or liquidation opportunities.

• Shared Infrastructure: Both use bots, mempool monitoring, and high-gas bidding.
• Different Target: Standard MEV often targets DEX arbitrage or lending liquidations. Governance MEV specifically targets the protocol's own control mechanisms.
• Broader Impact: While financially damaging, governance MEV can also undermine trust in the DAO's decision-making process itself.

It's crucial to distinguish between two similar attacks:

• Proposal Front-Running: Acting before a governance action executes to profit from the action itself (e.g., buying an asset before a treasury buy).
• Vote Sniping: A related attack where an actor acquires voting power (e.g., tokens) after a proposal is submitted but before the voting period ends to swing the outcome, often at the last minute. While both are governance attacks, front-running targets execution, while sniping targets the vote.

A broad category of exploits targeting the decision-making processes of a Decentralized Autonomous Organization (DAO) or protocol. This includes:

• Vote buying/selling: Trading voting power for financial gain.
• Vote delegation manipulation: Exploiting flaws in delegation mechanisms.
• Proposal spam: Flooding the governance system to obscure malicious proposals.
• Treasury drains: Proposals designed to illegitimately transfer protocol funds. Proposal front-running is a tactical subset, specifically manipulating the timing and content of proposals.

The maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, or reordering transactions within a block. Proposal front-running is a form of governance MEV, where the value is extracted by being the first to submit a profitable governance action. It shares the core mechanic of transaction ordering dependency with other MEV strategies like arbitrage and liquidations.

A critical security mechanism where executed governance decisions are subject to a mandatory waiting period before taking effect. This is a primary defense against front-running and other governance attacks. For example, a successful proposal to upgrade a contract or transfer funds is queued for 48-72 hours, allowing token holders to:

• Review the final, executable code.
• Organize a defensive response (e.g., a counter-proposal).
• Exit the system if the action is malicious.

An off-chain, gas-free voting platform that records voter sentiment by signing messages with their wallets. It is often used for temperature checks and signaling. However, its off-chain nature makes it vulnerable to front-running, as a malicious actor can see a popular Snapshot proposal and front-run its on-chain execution with a slightly modified, self-serving version. This highlights the risk of decoupling signaling from execution.

A design philosophy that seeks to reduce the attack surface and need for active human governance by embedding rules directly into immutable code or smart contract logic. By minimizing the scope and frequency of upgradeable proposals, protocols inherently reduce opportunities for front-running and other governance attacks. This often involves using trustless, automated mechanisms (like bonding curves or algorithmic parameters) instead of discretionary votes.

Uncollateralized loans that are borrowed and repaid within a single blockchain transaction. While not directly part of governance, they are a powerful enabler for sophisticated governance attacks, including front-running. An attacker can use a flash loan to:

• Borrow a massive amount of governance tokens to pass a malicious proposal.
• Front-run a legitimate proposal by instantly acquiring voting power.
• Repay the loan before the transaction ends, requiring zero upfront capital.