Why Delegated Voting is the Next Major Attack Vector

Lido's ~30% of all staked ETH creates a centralization vector where a single DAO's decisions can sway the entire Ethereum network.\n- Attack Surface: A governance exploit or malicious proposal within Lido DAO could force its validators to act against the network.\n- Systemic Risk: This isn't just about Lido; it's a template for any dominant liquid staking token (LST) like Rocket Pool's rETH or Binance's BNB staking.

Voter turnout is often below 10%, allowing well-funded entities to capture governance cheaply. This enables on-chain vote-buying and bribery markets.\n- Real-World Example: The Curve Wars demonstrated how protocols like Convex and Stake DAO amass voting power to direct CRV emissions.\n- Escalation: This model is migrating to general governance, where delegators rent their voting power to the highest bidder via platforms like Paladin and Hidden Hand.

Even with decentralized validators, governance depends on centralized infrastructure for proposal data and voting interfaces. An attack on Infura, Alchemy, or a major frontend like Tally can censor or manipulate voter perception.\n- Single Point of Failure: Most delegators interact via a handful of interfaces.\n- Data Integrity: Malicious RPCs could serve incorrect proposal data, leading to unintended votes.

The endgame is moving delegation logic into the protocol layer (e.g., Ethereum's EIP-7002 for exit queue control) and adopting intent-based architectures.\n- Enshrined Security: Delegation rules are enforced by consensus, not a mutable smart contract.\n- Intent Paradigm: Users express voting preferences (e.g., "vote with Lido") and a solver network executes optimally, similar to UniswapX or CowSwap for trades.

Replace blind delegation with cryptographically verified attestations about delegate behavior. Think EigenLayer for governance, where delegates build a reputation score based on historical vote correctness and alignment.\n- Accountability: Delegates are slashed for malicious voting or inactivity.\n- Data Source: Attestations can pull from on-chain voting records and oracle networks like Chainlink or Pyth for off-chain context.

Break the "one-token, one-delegate" model. Allow token holders to delegate voting power on different topics to different experts (e.g., security to one delegate, treasury management to another). This is being explored by Compound Grants and Optimism's Citizen House.\n- Reduced Concentration: Dilutes power of monolithic delegates.\n- Specialized Governance: Increases decision quality by matching expertise to problem domains.

Delegation centralizes voting power into a few hands, creating a single point of failure. Attackers don't need to compromise thousands of wallets—just a few key delegates.\n- Attack Vector: Bribery, coercion, or exploitation of a delegate's private key.\n- Impact: A single compromised delegate can pass malicious proposals controlling $10B+ in protocol treasuries.\n- Real-World Precedent: The ConstitutionDAO incident showed how social engineering can redirect funds, a risk magnified in delegated systems.

Delegated voting power is a financial instrument. MEV searchers can profit by manipulating governance outcomes that affect token prices or protocol parameters.\n- Mechanism: Borrow or acquire tokens briefly, delegate to a controlled address, vote, then exit.\n- Target: Proposals affecting fee switches, oracle selections, or liquidity incentives create immediate arbitrage.\n- Theoretical Exploit: A flash loan of governance tokens could pass a proposal favoring a specific Uniswap pool, enabling front-running on the resulting volume.

Users delegate and forget. Revoking delegation requires an on-chain transaction, creating inertia. An attacker who compromises a trusted delegate has a long window to operate.\n- Vulnerability: The time delay between a delegate turning malicious and users reacting.\n- Amplified by: Low-information voters and gas costs for re-delegation.\n- Case Study: If a major Compound or Aave delegate were compromised, it could take days for the community to respond, allowing catastrophic proposals to pass.

Move from blind delegation to programmable voting intents. Users delegate not just power, but constraints and preferences.\n- Mechanism: Delegate votes only for specific proposal types or within defined parameter bounds.\n- Analogy: Like UniswapX for governance—specify the desired outcome, not the execution path.\n- Precedent: Safe{Wallet}'s module system shows how programmable authority can limit scope and create recovery paths.

Treat delegated voting power as a live stream, not a static transfer. Implement mechanisms for instant, costless revocation upon suspicious activity.\n- Implementation: EIP-1271-style signature verification for delegation, allowing revocation via signed message.\n- Detection: Integrate with security services like Forta to auto-trigger revocation alerts.\n- Outcome: Neutralizes the delegation lock-in problem, forcing attackers to operate within a single voting window.

Decouple vote aggregation from execution. Use light client bridges (like Succinct, Herodotus) to prove voting outcomes on-chain without relying on a centralized tally.\n- Architecture: Delegates submit votes with ZK-proofs or validity proofs to a smart contract.\n- Benefit: Eliminates the risk of a corrupted off-chain aggregator (e.g., Snapshot) submitting false results.\n- Vision: Creates a layerzero-like trust-minimized layer for cross-chain governance, where the voting process itself is verifiable.