Setting Up a Delegated Voting System for Content Appeals

A delegated voting system for content appeals shifts moderation power from a central authority to the community. Users stake governance tokens to propose or vote on appeals for content flagged by automated systems or initial moderators. The core mechanism is vote delegation, where token holders can delegate their voting power to trusted community members or experts, ensuring informed decisions without requiring constant participation from all users. This model, inspired by systems like Compound's Governor Bravo, creates a scalable and transparent layer for final arbitration.

The system architecture typically involves three main smart contracts: a Voting Token (ERC-20 or ERC-1155 for non-transferable reputation), a Governor contract that manages proposal lifecycle and voting logic, and a Content Registry that holds the state of appealed items. When a user appeals a moderation decision, they lock a small stake to create a proposal. The Governor contract then opens a voting period where delegated voters cast votes using their voting power, which is calculated from their token balance plus any delegated power.

Here is a simplified code snippet for a Governor contract's core voting function using OpenZeppelin's Governor library:

solidityCopy
function castVote(uint256 proposalId, uint8 support) public virtual override returns (uint256) {
    address voter = _msgSender();
    uint256 votingPower = getVotes(voter, proposalSnapshot(proposalId));
    require(votingPower > 0, "GovernorVotingSimple: vote without voting power");
    _countVote(proposalId, voter, support, votingPower);
    return votingPower;
}

The getVotes function fetches the voter's power at the time the proposal was created (proposalSnapshot), which includes tokens self-delegated or delegated to them. This snapshot prevents manipulation by acquiring tokens after a proposal is live.

Key parameters must be carefully configured for security and efficiency. The voting delay (time between proposal creation and start of voting) should allow for review. The voting period (typically 3-7 days) must balance urgency with sufficient deliberation. A quorum requirement (e.g., 4% of total token supply) ensures decisions have minimum community engagement. Finally, a proposal threshold (e.g., 1,000 tokens) prevents spam. These values should be set via governance and can be adjusted as the community matures.

Integrating this system requires a front-end that interacts with the contracts. Users need interfaces to: delegate votes, view active appeals, read proposal details, and cast votes. The backend must index on-chain events to track proposal state and voter participation. For transparency, all votes should be permanently recorded on-chain. Successful implementation, as seen in protocols like Uniswap, hinges on clear documentation and user-friendly tooling to encourage broad participation in the appeals process.

Building a delegated voting system requires proficiency in smart contract development and a solid understanding of decentralized governance patterns. You should be comfortable with Solidity or Vyper for writing the core voting logic, and familiar with common standards like ERC-20 for token-based voting rights or ERC-1155 for representing non-fungible delegation credentials. Experience with development frameworks such as Hardhat or Foundry is essential for testing and deployment. A foundational grasp of cryptographic primitives—particularly digital signatures for vote delegation and Merkle proofs for verifying off-chain data—is also necessary.

The system's architecture typically involves several key contracts: a Voting Token contract to manage voting power, a Delegation Registry to track delegate relationships, and a Voting Contract itself to execute proposals and tally votes. You must understand how to design gas-efficient vote tallying, implement secure timelocks for proposal execution, and prevent common vulnerabilities like double-voting or delegation loops. Familiarity with OpenZeppelin's governance libraries can accelerate development but requires understanding their modular components, such as Governor, TimelockController, and Votes.

Off-chain, you'll need to set up an indexing and querying layer to serve proposal data and voting history to users. This often involves using The Graph to create a subgraph that indexes events from your voting contracts, or running a custom indexer. For the frontend, knowledge of a Web3 library like ethers.js or viem is required to interact with the contracts. You should also plan for a relayer service or meta-transaction system to allow users to vote without paying gas, which is crucial for accessibility in a delegated model where many participants may hold small token balances.

A delegated voting system for content appeals shifts the final arbitration of contested moderation decisions from a central authority to a decentralized network of token holders. The core architecture consists of three primary smart contracts: a Voting Escrow contract for managing voter stake and delegation, an Appeals Registry for creating and tracking appeal proposals, and a Voting Engine that executes the voting logic and enforces outcomes. This modular design separates concerns, allowing for independent upgrades and clear audit trails. The system is typically deployed on an EVM-compatible L1 or L2 like Ethereum, Arbitrum, or Optimism to leverage its security and composability.

The Voting Escrow contract is foundational. Users lock the platform's native governance token (e.g., $SCORE) to receive non-transferable, time-weighted voting power represented as veTokens. This mechanism, popularized by protocols like Curve Finance, aligns long-term incentives. Users can delegate their veTokens to trusted experts or 'delegates' who will vote on their behalf. The contract maintains a registry of delegations and calculates the voting power of each delegate address, which is then used in the appeals process. This setup ensures that voting weight correlates with long-term stake in the platform's health.

When a user appeals a content moderation decision, an Appeal Proposal is created via the AppealsRegistry contract. This proposal is an on-chain struct containing the content's unique identifier (like a contentHash or tokenId), the original moderation ruling, the appellant's address, and metadata. The registry emits an event, signaling the start of a voting period—commonly 5-7 days. Only delegates with sufficient veToken voting power (meeting a minimum threshold) are eligible to cast votes, which are recorded directly on-chain as FOR (uphold appeal) or AGAINST (uphold moderation).

The Voting Engine contract manages the voting lifecycle. It queries the Voting Escrow for delegate power, accepts votes from eligible addresses, and tallies results when the period ends. A typical implementation uses a simple majority or a supermajority (e.g., 66%) to pass. Crucially, the contract must handle edge cases: preventing double-voting, managing delegation changes mid-vote, and implementing a quorum requirement to ensure legitimacy. Upon resolution, the contract executes the outcome automatically—for instance, by calling a function on a separate Content Moderation contract to reinstate or permanently remove the contested item.

Security and gas optimization are critical considerations. The contracts should utilize access control patterns like OpenZeppelin's Ownable or AccessControl to restrict sensitive functions (e.g., finalizing votes) to the contract itself. Voting can be made gas-efficient by using snapshot mechanisms (like ERC20Votes) to record voting power at the start of the proposal, rather than calculating it on each vote. Furthermore, integrating with an oracle or a secure off-chain data availability layer might be necessary if appeal proposals require referencing large amounts of content data that is impractical to store directly on-chain.

In practice, a front-end dApp interacts with these contracts, allowing users to lock tokens, delegate, submit appeals, and view active proposals. The complete flow ensures a transparent, auditable, and community-driven appeals process. For a production-ready reference, developers can study the governance modules of Compound Governor Bravo or OpenZeppelin Governance, adapting their patterns for a specialized content arbitration use case. The final system creates a robust checks-and-balances layer for platform governance, decentralizing a traditionally centralized point of failure.

The core of a delegated voting system is a smart contract that manages the delegation of voting rights. We'll build a DelegationRegistry contract using Solidity. This contract must track which addresses (delegates) are authorized to vote on behalf of other addresses (principals). The primary data structure is a mapping: mapping(address => address) public delegateOf;. When a user calls delegateTo(address delegate), the contract sets delegateOf[msg.sender] = delegate, granting voting power. It's crucial to include an undelegate() function to revoke this permission, ensuring users retain ultimate control.

Security is paramount in delegation logic. The contract must prevent common vulnerabilities like reentrancy and ensure authorization checks are strict. For example, the delegateTo function should check that the delegate is not the zero address and is not the caller themselves to prevent self-delegation loops. Furthermore, implementing an event like DelegationSet(address indexed principal, address indexed delegate) is essential for off-chain indexers and user interfaces to track delegation changes transparently. Always use the Checks-Effects-Interactions pattern to mitigate reentrancy risks, even if this contract holds no funds.

To make the system functional for an appeals process, an external appeals contract must query the registry. We implement a view function, getDelegate(address principal) public view returns (address), that returns the current delegate for a given user, or the principal's own address if none is set. This allows the voting contract to check delegationRegistry.getDelegate(voter) to determine whose voting power to use. By separating the registry logic from the voting logic, we adhere to the principle of separation of concerns, making the system more modular and easier to audit and upgrade independently.

Consider adding advanced features to increase robustness. A delegateWithExpiry(address delegate, uint256 expiryTimestamp) function allows for time-bound delegations, which automatically revert after a set period. You can also implement a delegateForContract(address delegate, address contractAddress) function for scoped delegation, where a user delegates power only for a specific smart contract's voting mechanism. These patterns are used in protocols like Compound's Governor Bravo and provide users with granular control over their assets and governance rights.

Finally, thorough testing is non-negotiable. Write comprehensive unit tests using Foundry or Hardhat that cover all scenarios: successful delegation and undelegation, attempts to delegate to invalid addresses, and the correct behavior of the getDelegate function for both delegated and non-delegated users. Test time-bound delegations to ensure they expire correctly. After testing, verify the contract on a block explorer like Etherscan for mainnet deployment. This completes the implementation of a secure, reusable delegation primitive for your on-chain appeals system.

The core of the appeals system is a ContentAppealsVoting contract. This contract manages the lifecycle of an appeal, from its creation by a user challenging a moderation decision to the final tally of votes. Key state variables include a mapping of appealId to an Appeal struct, which stores the disputed content ID, the appellant's address, the current vote counts for uphold and overturn, and the voting deadline. The contract must also track which addresses have already voted on each appeal to prevent double-voting.

Delegation is implemented using a separate VotingPower contract or an internal system that tracks delegated voting power, similar to Compound's Governor. When a user votes, the contract checks their voting power at the time the appeal was created (using a snapshot mechanism) rather than their current balance. This prevents manipulation by acquiring tokens after an appeal begins. The vote function signature is typically voteOnAppeal(uint256 appealId, bool support), where support = true votes to overturn the moderation decision.

The contract must include critical access controls and validation. Only the appellant can create an appeal for their own moderated content, and voting is only allowed during the active period before the deadline. A resolveAppeal function, callable by anyone after the deadline, tallies the votes. The outcome is determined by which side has more voting power; a tie could be designed to default to upholding the original decision. The result should emit an event and may call an external Moderation contract to execute the final decision.

Security considerations are paramount. Use OpenZeppelin's libraries for safe math and reentrancy guards. The snapshot mechanism for voting power must be gas-efficient and secure against flash loan attacks. Consider implementing a timelock on the resolveAppeal function to allow for a challenge period. The contract should be thoroughly tested with scenarios including delegation changes mid-vote and malicious contract interactions.

For developers, the complete contract interface includes key functions: createAppeal(uint256 contentId), delegateVote(address delegatee), castVote(uint256 appealId, bool support), and resolveAppeal(uint256 appealId). Events like AppealCreated, VoteCast, and AppealResolved are essential for off-chain indexing. Reference implementations can be found in governance systems like OpenZeppelin Governor.

After deployment, the contract address must be whitelisted in the main moderation system. Front-end applications will listen for the AppealCreated event to display active appeals and call the castVote function via a connected wallet like MetaMask. The final, audited code should be verified on a block explorer such as Etherscan to ensure transparency and allow community verification of the contract logic.

A static delegation model, where a user's voting power is permanently assigned to a delegate, creates governance risk. Delegates may become inactive, change their alignment, or have their keys compromised, yet their voting power remains unchanged. Delegation decay mitigates this by automatically reducing the voting power of a delegation over time. This creates a natural incentive for delegators to periodically review and renew their trust, or for delegates to remain active and accountable to their constituents. The decay rate is a crucial governance parameter, often expressed as a percentage loss per epoch or block.

Implementing decay requires tracking two timestamps per delegation: the time of the last delegation action (initial delegation or renewal) and the current time. The effective voting power is calculated by applying an exponential or linear decay function to the originally delegated amount based on the elapsed time. A common approach uses an exponential decay formula: effective_power = initial_power * e^(-decay_rate * time_elapsed). This ensures voting power smoothly approaches zero but never fully disappears unless explicitly revoked. The decay_rate determines how quickly influence wanes.

Here is a simplified Solidity example of a struct and view function to calculate decayed voting power. This assumes time is measured in blocks and a linear decay model for clarity.

solidityCopy
struct Delegation {
    address delegate;
    uint256 amount;
    uint256 lastUpdatedBlock;
}

mapping(address => Delegation) public delegations;
uint256 public constant DECAY_PERIOD = 1000; // Blocks until full decay

function getDecayedVotingPower(address user) public view returns (uint256) {
    Delegation memory d = delegations[user];
    if (d.amount == 0) return 0;
    
    uint256 blocksElapsed = block.number - d.lastUpdatedBlock;
    if (blocksElapsed >= DECAY_PERIOD) {
        return 0; // Fully decayed
    }
    // Linear decay: lose 1/DECAY_PERIOD per block
    uint256 decayedAmount = d.amount * (DECAY_PERIOD - blocksElapsed) / DECAY_PERIOD;
    return decayedAmount;
}

To renew a delegation and reset the decay timer, a delegator must call a renewDelegation function, which updates the lastUpdatedBlock to the current block.

The decay mechanism must be integrated into the core voting contract. When a delegate casts a vote, the contract should calculate their total voting power by summing the decayed power from all their delegators. This calculation can be gas-intensive if done on-chain for many delegators in a single transaction. For scalability, consider using a snapshot mechanism where voting power is calculated at a specific block (like in OpenZeppelin's Snapshot pattern) or an off-chain indexer that provides a merkle proof of the total. The key is ensuring the decay logic is applied consistently wherever voting power is queried.

Setting the correct decay_rate and DECAY_PERIOD is a governance decision that balances security with usability. A very fast decay (e.g., 50% per week) forces frequent re-engagement but may frustrate users. A very slow decay (e.g., 10% per year) offers little protection against stale delegations. Analyze historical delegate activity patterns in similar DAOs to inform this parameter. It can also be made upgradeable via governance to allow the community to adjust it based on observed outcomes. This creates a self-correcting system where the mechanism itself can evolve.

Finally, transparently exposing decay information is critical for user experience. The front-end should clearly show delegators the current decayed power of their delegate and the time remaining until it significantly diminishes. Delegates should be able to see the aggregate decay schedule of the power entrusted to them. This visibility turns decay from a hidden penalty into a positive feedback loop, encouraging proactive community engagement and maintaining a dynamic, healthy governance system where active participation is consistently rewarded.

Your deployed system demonstrates a key governance primitive: delegated voting power. Users can delegate their voting tokens to trusted representatives, who then cast votes on their behalf for content appeal proposals. This model, used by protocols like Compound and Uniswap, increases participation by lowering the technical barrier for casual token holders while concentrating expertise in active delegates.

To enhance this system, consider implementing several upgrades. Add a timelock contract to introduce a delay between a vote's conclusion and its execution, providing a safety window. Integrate Snapshot for gas-free off-chain voting signaling, using your token's on-chain holdings for vote weighting. For dispute resolution, you could incorporate a Kleros or UMA oracle to adjudicate edge-case appeals objectively.

The next step is to rigorously test your contracts. Write comprehensive unit tests in Hardhat or Foundry covering all edge cases: delegation transfers mid-vote, malicious proposal creation, and quorum failures. Perform a security audit or use tools like Slither or MythX for static analysis. Finally, consider the user experience; simplify the delegation process and provide clear voting history and delegate performance metrics in your frontend.

For production deployment, you must decide on key governance parameters. Set appropriate values for: the voting delay (time between proposal creation and voting start), voting period (typical range is 3-7 days), proposal threshold (minimum tokens required to submit), and quorum (minimum voting power required for validity). These settings define the system's agility and security.

Explore existing frameworks to accelerate development. The OpenZeppelin Governor contract provides a standardized, audited base for voting systems with extensions for timelocks and vote counting. Tally and Boardroom are platforms for hosting frontends and analyzing governance data. Using these tools can save development time and align your system with industry standards.

The ultimate goal is a transparent, secure, and participatory appeals process. Continue iterating by gathering feedback from potential users, monitoring gas costs for key transactions, and staying updated on Ethereum Improvement Proposals (EIPs) related to governance, such as EIP-5805 (Delegation by Signature) and EIP-6372 (Contract Clock). Your system is a live prototype for decentralized content moderation.