INSTRUCTOR ONLY - DO NOT DISTRIBUTE TO STUDENTS BEFORE ACTIVITY

DAO Profile Reference Data

The three DAO profiles provided to students contain the following key parameters (reproduced here for verification):

DAO Profile Treasury Total Token Supply Top 10 Holders Historical Participation Governance Model
DAO Alpha (DeFi protocol) $45M USDC 10M ALPHA 38% of supply 8-12% of tokens vote Direct token voting; 5% quorum
DAO Beta (NFT community) 800 ETH 8,888 NFTs (1 vote each) 15% of NFTs held by 10 wallets 25-35% of NFTs vote NFT-based voting; 50% quorum on large proposals
DAO Gamma (L2 protocol) 2,000 ETH + 5M GAMMA tokens 100M GAMMA 52% of supply 3-6% of tokens vote Delegation allowed; 4% quorum

Model Proposal: DAO Alpha — Developer Grants Program

Proposal: Launch Alpha Developer Grants Program

Author: Community member | Forum discussion: 2 weeks prior | Status: On-chain vote

Summary: Allocate $500,000 USDC (1.1% of treasury) to fund 10 developer grants of $50,000 each over 12 months. Grants target open-source integrations, new front-end interfaces, and smart contract tooling for the Alpha protocol.

Motivation: Alpha protocol currently relies on a single front-end and 3 integration partners. The protocol's long-term value scales with ecosystem breadth. Compound and Aave both launched grants programs at similar treasury sizes and documented 3-5x developer community growth within 18 months.

Budget: $500,000 USDC (1.1% of $45M treasury) — well within the 3% guideline for routine proposals.

Success Metrics:

  • 10 grants awarded within 6 months of approval
  • At least 5 completed integrations within 12 months
  • Protocol TVL growth of 20% attributable to new integrations (measured via referral tracking)
  • Quarterly public report to DAO on grant status

Implementation: 3-person grants committee (2 elected community members + 1 core team member). Milestone-based disbursement: 50% upfront, 50% on delivery. Unspent funds returned to treasury after 12 months.

Voting Simulation: DAO Alpha Grants Proposal

Mechanism 1: Token Voting (1 token = 1 vote)

Setup (assume 10% participation = 1,000,000 ALPHA voting): Total tokens: 10,000,000 ALPHA
Voting tokens: 1,000,000 (10% participation)
Top 10 holders' share of vote: ~38% of 1,000,000 = 380,000 tokens
Remaining community: 620,000 tokens

Quorum: 5% of total supply = 500,000 ALPHA → MET (1,000,000 > 500,000)

Assume top 10 holders: split 6 for / 4 against (they benefit from ecosystem growth)
→ Whale FOR votes: 228,000 | Whale AGAINST: 152,000
Community: assume 70% in favor (developer grants have broad support)
→ Community FOR: 434,000 | Community AGAINST: 186,000

Total FOR: 662,000 (66.2%) | Total AGAINST: 338,000 (33.8%)
Threshold: simple majority (50%+1) → PASSES

Result: PASSES — Whale influence: top 10 holders control 38% of vote; could determine outcome if split differently. If all 10 whale wallets voted AGAINST, the proposal would likely fail (38% against + enough community skeptics).

Mechanism 2: Quadratic Voting (cost = votes²)

Each voter given a budget of "voice credits" (say 1,000 credits each): Casting 1 vote costs 1 credit; 10 votes costs 100 credits; 31 votes costs 961 credits

Whale voter (1,000,000 tokens → maps to higher starting credit budget):
Even if a whale spends ALL 1,000 credits to maximally vote: sqrt(1,000) ≈ 31.6 effective votes

Small holder with 10 tokens (100 credits budget):
Spending all credits: sqrt(100) = 10 effective votes

Effect: ratio of influence shrinks from 100:1 (token voting) to ~3.2:1 (quadratic)
Whale dominance is dramatically reduced.
Practical result for DAO Alpha grants proposal: With quadratic voting, 10 whale wallets (38% of tokens) → ~22% of effective voting power
Community (62% of tokens, many small holders) → ~78% of effective voting power

If community supports grants: proposal PASSES more decisively
Margin: community preference dominates over whale preference

Result: PASSES (with higher margin than token voting if community is supportive). Quadratic voting here increases the proposal's passage margin by reducing whale veto power.

Mechanism 3: Conviction Voting (weight accumulates over time)

Conviction formula: C(t) = C(t-1) * alpha + tokens_staked * (1 - alpha) alpha = decay factor (e.g., 0.9 per time period)

After 10 days of staking 1,000 tokens with alpha=0.9:
Day 0: C = 0
Day 1: C = 0 * 0.9 + 1,000 * 0.1 = 100
Day 2: C = 100 * 0.9 + 1,000 * 0.1 = 190
Day 5: C ≈ 410
Day 10: C ≈ 651
Day 20: C ≈ 878 (approaches asymptote of 1,000)

Threshold: requires sustained conviction to pass — one-time flash voting fails
Result for DAO Alpha grants proposal: Community members who genuinely support the grant program → stake tokens early
Accumulate conviction over 2-3 weeks
Short-term opposition (e.g., whale who votes no to dump in interim) is discounted

Long-term supporters: high conviction score → PASSES if sustained support exists
Whale who joins late: low conviction → reduced influence

Result: PASSES — assuming proposal is genuinely supported over time. Conviction voting is most resistant to last-minute whale influence. Governance attacks require sustained commitment, not just a large one-time vote.

Key Analytical Insights Students Should Identify

Insight 1: Token Voting Amplifies Whale Power Disproportionately

In DAO Alpha, top 10 holders with 38% of supply control 38% of every vote — but at 10% participation, their 380,000 votes represent 38% of the actual decision. If the community participates at only 5%, whale dominance grows to 68%. Low participation dramatically increases whale influence. Students should note that encouraging broad participation is itself a governance improvement strategy.

Insight 2: Quadratic Voting Helps Community Voice, But Invites Sybil Attacks

Quadratic voting reduces whale dominance — but a whale can trivially split their tokens across 100 wallets to restore near-linear voting power. Effective quadratic voting requires identity verification (e.g., Gitcoin Passport, proof-of-personhood). Without it, quadratic voting is vulnerable to wallet-splitting attacks. Students who identify this vulnerability without prompting demonstrate excellent critical thinking.

Insight 3: Conviction Voting Favors the Patient Majority

Conviction voting solves the "flash governance attack" problem — a whale cannot simply acquire tokens, vote, and sell. But it creates a new problem: proposals can stall indefinitely if conviction thresholds are set too high. Real implementations (Giveth, Gardens) use dynamic thresholds that lower as treasury is not being spent. Students should note this isn't just about passes/fails but about the speed of governance.

Insight 4: DAO Gamma Has a Dangerous Concentration Problem

DAO Gamma's top 10 holders control 52% of tokens with only 3-6% participation. This means ~4% of total token supply can pass or block any proposal. This is governance theater — it appears decentralized but 2-3 large holders effectively control all outcomes. Students working with DAO Gamma should flag this as a critical governance vulnerability requiring quadratic or conviction voting reforms.

Insight 5: Quorum Requirements Are a Two-Edged Sword

Low quorum (5% in DAO Alpha) means proposals can pass with minimal participation — enabling governance attacks. High quorum (50% in DAO Beta's NFT model) makes the DAO hard to govern — important proposals fail because holders are apathetic. The optimal quorum depends on typical participation rates. A quorum set above the median participation rate means most proposals will fail to pass regardless of content.

Governance Vulnerabilities to Discuss

  • Governance attack / hostile takeover: An attacker borrows tokens (via flash loan or short-term loan) on vote day, votes, then returns tokens. Solution: snapshot voting at block height before proposal announcement, not at vote time.
  • Voter apathy creating de facto oligarchy: When 90-97% of tokens don't vote (DAO Gamma), the effective quorum is controlled by active holders who may not represent the community. Delegation features partially address this.
  • Proposal spamming: If proposal creation is free, bad actors spam governance with noise. Solution: require a small token deposit (returned if quorum met, lost if spam) as a spam filter.
  • Capture via vesting: If the team or investors hold large unvested allocations, they can dominate governance before community tokens are distributed. Time-locks on team governance rights during vesting period are a best practice.
  • Treasury drain attacks: Multiple small proposals that individually pass quorum but collectively drain the treasury. Solution: total budget caps per period (e.g., max 5% of treasury per quarter can be disbursed without supermajority).

Evaluation Guidance

Proposal Quality (20 pts):

Strong (18-20 pts): Budget is 0.5-3% of treasury. Clear, measurable success metrics (specific numbers, timelines). Implementation includes accountability mechanism (milestone payments, reporting requirement, unused funds return). Proposal addresses a genuine DAO need, not just "marketing" or vague "growth."
Weak (0-8 pts): Budget exceeds 5% of treasury without extraordinary justification. Metrics are vague ("increase community engagement"). No accountability structure. Proposal reads as self-serving rather than DAO-serving.

Voting Analysis (15 pts):

Strong (13-15 pts): Student actually calculates numbers for all three mechanisms using the DAO profile data. Shows work (formula, intermediate steps). Correctly identifies which mechanism is most/least favorable to their proposal and WHY (not just "it passed" but "whale influence was reduced from 38% to 22%").
Weak (0-5 pts): No calculation shown. Only says "it would probably pass" without numbers. Does not use DAO profile data. Cannot explain difference between mechanisms beyond restating the definitions.

Critical Thinking (10 pts):

Strong (9-10 pts): Identifies at least 2 specific governance vulnerabilities in the chosen DAO. Proposes concrete improvements (not just "increase participation" but "require delegation to prevent voter apathy" or "add snapshot voting to prevent flash loan attacks"). Connects to course concepts (Sybil resistance, principal-agent problems, mechanism design).
Weak (0-3 pts): No vulnerabilities identified. Improvements are generic ("make it more fair"). No connection to course theory. Student assumes the DAO works as described and doesn't question the design.
Real-World DAO Examples for Debrief: MakerDAO (token voting + whale concentration problems, led to MetaDAO restructuring). Uniswap DAO (very low participation despite large token float). Compound (famous governance attack with Humpy the Whale). ENS DAO (delegation success story — high delegation rate increased participation). Nouns DAO (fork governance — dissatisfied members can exit with treasury share). These provide rich discussion material.

© Joerg Osterrieder 2025-2026. All rights reserved.