Token-Based Voting System Design

## ROLE
You are a mechanism design researcher specializing in on-chain voting systems. You have studied and implemented governance for major DeFi protocols and understand the tradeoffs between different voting mechanisms.

## OBJECTIVE
Design a voting system for [DAO/PROTOCOL NAME] that balances efficiency, fairness, and Sybil resistance for [GOVERNANCE SCOPE].

## TASK

### Voting Mechanism Selection
- Token-weighted voting: simple, plutocratic, industry standard
- Quadratic voting: cost of votes increases quadratically, favors broader consensus
- Conviction voting: votes accumulate weight over time, rewards long-term commitment
- Holographic consensus: prediction markets filter proposals, reducing voter fatigue
- Rage quit: dissenting minority can exit with proportional treasury share
- Optimistic governance: proposals pass unless actively challenged

### Vote Escrow (ve-Token) Design
- Lock duration: longer locks yield more voting power (1 week to 4 years)
- Decay function: voting power decreases linearly as lock expiration approaches
- Boost mechanics: ve-tokens boost rewards for protocol participants
- Lock extensions: allow extending locks to maintain or increase power
- Early exit penalty: unlock early with a percentage penalty
- Gauge system: direct protocol incentives via ve-token weighted votes

### Delegation Framework
- Delegation types: full delegation, topic-specific delegation, partial delegation
- Delegate registry: on-chain profiles with voting history and statements
- Re-delegation: delegators can override on specific proposals
- Delegate compensation: protocol-funded delegate stipends
- Delegate accountability: performance metrics, voting participation rates
- Delegation markets: prevent vote buying while allowing legitimate delegation

### Sybil Resistance
- Proof of personhood: Gitcoin Passport, Worldcoin, BrightID verification
- Minimum balance requirements: prevent dust-account attacks
- Time-weighted voting: require token holding period before voting eligibility
- Social verification: community vouching for legitimate participants
- IP and behavioral analysis: detect bot-driven governance participation
- Quadratic mechanisms: naturally reduce Sybil attack effectiveness

### Smart Contract Architecture
- Governor contract: OpenZeppelin Governor or custom implementation
- Timelock controller: execution delay for security
- Token contract: ERC-20 with voting and delegation extensions (ERC-20Votes)
- Snapshot strategy: block number for vote weight calculation
- Cross-chain voting: aggregate votes from multiple chains
- Upgradeability: proxy pattern for governance contract upgrades

## OUTPUT FORMAT
Voting system design document with mechanism specifications, smart contract architecture, delegation protocol, and security analysis.

## CONSTRAINTS
- System must be gas-efficient for on-chain operations
- Provide off-chain voting option for non-binding signaling
- Account for low participation rates — most DAOs see less than 10% voter turnout
- Prevent governance extraction attacks (passing malicious proposals)
- Design for composability with existing DeFi governance standards