How to Architect a Delegated Voting System for Your DAO

Delegated voting is a governance model where token holders can delegate their voting power to representatives, or delegates, who vote on proposals on their behalf. This system, used by protocols like Compound and Uniswap, addresses voter apathy by allowing engaged participants to manage voting for less active members. The core architecture involves a smart contract that tracks delegation mappings, vote weights, and proposal states. Key decisions include whether delegation is transitive (can delegates re-delegate power), revocable at any time, or locked for proposal durations.

The foundational smart contract structure requires several critical data structures. You'll need a mapping from voter address to delegate address (mapping(address => address) public delegates), a mapping to track vote weights per proposal (mapping(address => mapping(uint256 => uint256)) public votes), and a struct for proposals containing details like description, voting deadline, and vote tally. Events like DelegateChanged and VoteCast are essential for off-chain indexing. Consider using the ERC-20Votes or ERC-5805 standards (EIP-6372) which provide built-in interfaces for token-weighted voting and delegation, reducing custom code and improving interoperability.

Here is a simplified Solidity snippet for a core delegation function:

solidityCopy
function delegate(address delegatee) external {
    address currentDelegate = delegates[msg.sender];
    uint256 senderBalance = balanceOf(msg.sender);
    delegates[msg.sender] = delegatee;
    emit DelegateChanged(msg.sender, currentDelegate, delegatee);
    _moveVotingPower(currentDelegate, delegatee, senderBalance);
}

The internal _moveVotingPower function must adjust historical vote checkpoints. This checkpoint pattern, as used in OpenZeppelin's Votes.sol, is gas-efficient for querying voting power at a past block number, which is crucial for executing on-chain votes based on a snapshot.

Security and gas optimization are paramount. Use snapshots (block numbers) to lock voting power at the start of a proposal, preventing manipulation via token transfers or delegation changes during the voting period. Guard against double voting and ensure delegation updates correctly propagate voting power. For gas savings, implement batch operations for delegation and use indexed events. Off-chain components are also critical: you'll need an indexer (like The Graph) to query delegate profiles and voting history, and a front-end interface for users to easily delegate and view delegate platforms.

When launching, start with a simple, audited contract and clear delegate guidelines. Promote a delegate discovery process, potentially using on-chain reputation systems or platforms like Tally or Boardroom. Continuously iterate based on governance participation metrics. The goal is a system that balances broad token holder influence with the efficiency of informed delegate voting, moving beyond simple token-weighted referenda to more sustainable DAO governance.

A delegated voting system allows token holders to delegate their voting power to representatives, or delegates, who vote on proposals on their behalf. This model, popularized by protocols like Compound and Uniswap, addresses voter apathy by consolidating decision-making power with engaged participants. The core smart contract architecture typically involves three key components: a token contract with snapshot capabilities, a delegate registry, and a governor contract that manages proposals and tallies votes based on delegated balances.

Before designing your system, you must define the vote weight calculation. The most common method uses a snapshot of token balances at a specific block number, often the proposal creation block, to prevent manipulation. Your Governor contract will query the delegateOf(address) function from your token or a separate registry to determine each voter's representative. The vote tally then uses the delegate's address and the snapshot balance of their delegators. Ensure your token implements EIP-712 for secure off-chain delegation signing or provides an on-chain delegate(address to) function.

Security and incentive design are critical. Consider implementing a timelock contract, like OpenZeppelin's TimelockController, to queue executed proposals, giving the community a window to react to malicious governance actions. For delegate accountability, you can add features like delegate profiles, delegation expiry periods, or track delegate voting history. The system should also handle edge cases, such as transfers of delegated tokens during an active voting period, which typically does not change the already-cast vote weight.

To implement a basic structure, you can extend OpenZeppelin's Governor contracts. Start with a token that uses the ERC20Votes or ERC721Votes extension, which automatically handles snapshotting and delegation logic. Then, deploy a governor contract (e.g., GovernorCountingSimple) that is configured to use your token's getVotes function. The flow is: 1) User delegates votes via the token contract, 2) A proposal is submitted, 3) Delegates vote during the voting period, 4) Votes are tallied using the snapshot from step 2, and 5) The proposal is queued and executed.

Finally, consider the user experience for delegation. While power users may delegate directly on-chain, providing a frontend interface that displays delegate platforms, historical performance, and easy one-click delegation is essential for adoption. Tools like Tally and Boardroom aggregate this data. Your architecture should emit clear events (e.g., DelegateChanged, DelegateVotesChanged) so these indexers can track delegation changes accurately and update interfaces in real time.

Delegated voting is a core governance mechanism for large-scale DAOs, allowing token holders to delegate their voting power to representatives. This pattern addresses voter apathy and reduces on-chain transaction costs by consolidating votes. The core contract architecture typically involves three key components: a vote-escrowed token contract (like veToken models), a delegation registry mapping delegates to delegators, and a governor contract that tallies voting power from the registry. This separation of concerns enhances security and upgradeability, as seen in protocols like Curve Finance and Uniswap.

The most critical contract is the delegation registry. A standard implementation uses a mapping such as mapping(address => address) public delegateOf, where the key is the delegator and the value is their chosen delegate. To vote, the governor contract calls a function like getVotes(address account, uint256 blockNumber), which must traverse this mapping to calculate the delegate's aggregated voting power. For gas efficiency, avoid storing complex historical data on-chain; instead, use snapshot mechanisms like OpenZeppelin's ERC20Votes extension, which captures balances at the time of delegation.

A major security consideration is preventing delegation loops or conflicts. Your delegate(address to) function should include checks to ensure a user cannot delegate to themselves or create circular delegation chains. Implement a pull-over-push model for delegation updates to prevent griefing; delegates should not be able to force themselves upon users. Furthermore, incorporate a timelock or cool-down period for changing delegates to mitigate the impact of sudden, malicious delegation shifts during a live proposal, a tactic known as a 'governance attack'.

For advanced implementations, consider weighted delegation or vote expiration. Instead of a simple 1:1 mapping, you can store delegation amounts, allowing partial delegation of a holder's tokens. To automate delegation for inactive users, implement a 'default delegate' field set by the DAO or the user themselves. All state changes should emit clear events like DelegateChanged(address indexed delegator, address indexed fromDelegate, address indexed toDelegate) to allow off-chain indexers and frontends to track delegation graphs in real-time.

Testing your delegation system is paramount. Write comprehensive unit tests for edge cases: delegation transfers during an active vote, delegation to a zero address, and multiple delegations to the same delegate. Use forked mainnet tests with tools like Foundry to simulate governance actions within a real token distribution environment. Always audit the integration points between your token, delegation registry, and governor contracts, as miscalculated voting power is a common vulnerability. Reference established codebases like Compound's Governor Bravo for proven patterns.

Delegated voting allows token holders to assign their voting power to trusted representatives, improving governance participation without requiring constant member engagement. Snapshot, the leading off-chain voting platform, supports this through its delegation registry—a public smart contract that maps delegators to their chosen delegates. To architect a system, you must first understand the core components: the voting strategy (which reads delegation data), the delegation contract (which stores delegation mappings), and the proposal creation interface (where delegated power is applied). This separation enables flexible, gas-efficient governance where votes are calculated based on the sum of a delegate's own tokens and all tokens delegated to them.

The foundation is the Snapshot Delegation Registry, deployed on multiple networks like Ethereum Mainnet and Polygon. The primary contract, 0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446, stores delegation data in a public mapping. A user delegates by calling the setDelegate function, specifying the spaceId (your DAO's unique Snapshot domain, e.g., yourdao.eth) and the delegate's Ethereum address. To revoke, they call clearDelegate. Your custom voting strategy must then query this contract. For example, a basic delegation-aware strategy sums the balance of the voter and the balances of all their delegators for the specified spaceId.

Implementing a custom strategy requires writing a script that fetches and calculates voting power. Snapshot strategies are JavaScript functions executed in a Node.js environment. Here is a simplified example that checks the delegation registry:

javascriptCopy
async function strategy(space, network, provider, addresses, options, snapshot) {
  const delegations = await fetchDelegations(space, addresses, snapshot);
  const scores = {};
  addresses.forEach((address) => {
    let power = getTokenBalance(address); // Base balance
    // Add power from all addresses that delegated to this address
    Object.keys(delegations).forEach((delegator) => {
      if (delegations[delegator] === address) {
        power += getTokenBalance(delegator);
      }
    });
    scores[address] = power;
  });
  return scores;
}

You must replace getTokenBalance with your actual token balance-fetching logic, often via a subgraph or ERC-20 contract calls.

When creating a proposal on Snapshot, you select your custom delegation strategy in the Voting Strategies section. The strategy's space parameter must match your DAO's spaceId to query the correct delegation set. It's critical to test your strategy thoroughly on a testnet or Snapshot's test space feature before mainnet use. Common pitfalls include not handling the snapshot block number correctly (for historical balance lookups) and failing to aggregate delegated balances across multiple delegators efficiently, which can lead to incorrect vote weighting and gas overruns.

For advanced architectures, consider implementing liquid delegation where voting power is fractionally delegated or using ERC-20 wrapper tokens like ERC-20Votes which have built-in delegation snapshots. You can also combine multiple strategies; for instance, one for direct token holdings and another for delegated balances. Always verify the delegation data on-chain before critical proposals by checking the registry contract directly via Etherscan. This ensures the off-chain strategy mirrors the true on-chain state, maintaining the integrity of your DAO's governance process.

Delegated voting is a critical scaling mechanism for DAOs, allowing token holders to delegate their voting power to experts or active participants. The core architectural challenge is designing a system that prevents voter apathy and ensures delegates act in the DAO's best interest. A well-designed system requires a clear delegation registry, a transparent voting power calculation, and robust incentive mechanisms. Smart contracts for delegation, like those used by Compound or Uniswap, manage these relationships on-chain, recording delegations and tallying votes based on the delegated token balance at a specific block.

The incentive structure is the most critical component. Common models include direct compensation (e.g., a share of protocol fees or a staking reward), reputation-based systems (where consistent, successful voting builds delegate credibility), and slashing mechanisms for malicious behavior. For example, a contract might reward delegates with a percentage of the treasury yield generated from proposals they successfully vote on. The code must define clear rules for reward distribution and eligibility, often requiring an oracle or off-chain indexer to track delegate performance and proposal outcomes accurately.

Implementing delegation requires careful smart contract design. A basic Solidity structure involves a mapping from delegator to delegate address and a function to update it. The voting contract must then read from this mapping during proposal execution. Security considerations are paramount: contracts should prevent double voting, handle token transfers that change voting power mid-proposal (often via snapshot mechanisms), and include timelocks or cool-down periods for changing delegation to prevent last-minute manipulation. Auditing these contracts is non-negotiable, as flaws can lead to governance attacks.

Beyond code, successful delegation relies on social infrastructure. DAOs need transparent delegate profiles, communication channels for delegates to share their platforms, and tools for voters to analyze delegate history. Platforms like Tally and Boardroom provide interfaces for this. The final system should be iterative; start with a simple delegation model, gather data on participation rates and delegate performance, and then refine the incentive parameters. The goal is a positive feedback loop where good governance is consistently rewarded, leading to a more engaged and effective DAO.

A delegated voting system, often called a vote-escrow model, allows token holders to delegate their voting power to representatives without transferring asset custody. The core contract architecture typically involves three main components: a Voting Escrow Token (veToken) that locks governance tokens for a user-defined period, a Gauge Controller that manages voting weight distribution across proposals or pools, and a Voter contract that handles the actual vote casting. This separation of concerns improves modularity and security. Popular implementations include Curve Finance's veCRV and Balancer's veBAL systems, which have become industry standards for aligning long-term incentives.

When testing your system, focus on edge cases specific to delegation logic. Write comprehensive unit tests for: the non-linear time decay of voting power, correct weight calculations when a user delegates after locking tokens, and the handling of expired locks. Use a forked mainnet test environment (e.g., with Foundry's cheatcodes or Hardhat's fork) to simulate complex interactions and front-running scenarios. Property-based testing with tools like Foundry's fuzzing can automatically discover edge cases in mathematical functions, such as ensuring total voting power never exceeds total locked supply.

Security auditing is non-negotiable. Key risks include: vote manipulation through flash loan attacks to temporarily gain voting weight, reentrancy in functions that handle lock creation/delegation, and governance capture via flawed weight math. Engage multiple specialized audit firms and supplement with a public bug bounty program on platforms like Immunefi. Critical findings often relate to the slope and bias calculations used for time-weighted voting power; these must be mathematically verified. Always review audit scope to ensure it covers the integrated system, not just individual contracts.

For deployment, use a structured upgradeability pattern like the Transparent Proxy (OpenZeppelin) or UUPS (EIP-1822) to allow for future fixes and parameter tuning. However, the core voting math and lock logic should be considered immutable after launch. Deploy in a single transaction using a deployer script to correctly initialize proxy contracts and set admin roles. Typical steps are: 1) Deploy implementation logic contracts, 2) Deploy and initialize proxy contracts pointing to implementations, 3) Transfer ownership of admin functions to a Timelock Controller (e.g., OpenZeppelin's) controlled by the DAO itself, never an EOA.

Post-deployment, establish monitoring for key on-chain metrics using tools like The Graph or Dune Analytics. Track: total value locked (TVL), average lock duration, delegation participation rate, and contract event logs for unusual patterns. Prepare and socialize an emergency response plan that details the steps for pausing the system via the Timelock if a critical vulnerability is discovered. A well-architected delegated voting system becomes the foundation for sustainable, long-term aligned governance, moving beyond simple token-weighted snapshot voting.

You have now explored the foundational architecture for a delegated voting system. The core components include a vote delegation registry smart contract that maps user addresses to their chosen delegate, a voting power snapshotter to calculate balances at a specific block, and a vote tallying mechanism that aggregates delegated power. Implementing these with security best practices—such as using OpenZeppelin's Ownable or AccessControl for administrative functions and preventing reentrancy—is non-negotiable for protecting your DAO's treasury and governance decisions.

The next step is to integrate this system with your existing governance framework. For DAOs using Snapshot, you would deploy your delegation registry on-chain and configure your Snapshot space to use a custom strategy that reads from it. For on-chain governors like OpenZeppelin's Governor contract, you would modify the getVotes function to check the delegation registry and return the delegate's voting power instead of the original holder's. Testing this integration thoroughly on a testnet like Sepolia or Goerli is critical before mainnet deployment.

Consider advanced features to enhance your system's utility and security. Implementing a delegation delay (e.g., a 1-epoch cooldown before new delegations become active) can prevent last-minute voting manipulation. Adding delegate metrics—such as proposal participation history and voting alignment—to your frontend empowers token holders to make informed delegation choices. For maximum flexibility, explore liquid delegation protocols like ERC-20Votes or ERC-5805, which standardize delegation and enable more complex governance structures.

Your implementation journey doesn't end at deployment. Establish clear off-chain processes for your community: create documentation explaining how to delegate, maintain a delegate directory, and run educational sessions. Monitor key metrics like delegation participation rates and delegate concentration. The most successful DAO governance systems are those that are not only technically sound but also foster an informed and active community of delegates and voters.