INSTRUCTOR ONLY - DO NOT DISTRIBUTE TO STUDENTS BEFORE ACTIVITY

How to Use This Answer Key

Token design has no single correct answer — the workshop intentionally allows multiple valid designs. This key provides:

  • Model designs for three sample project briefs to guide evaluation
  • Evaluation criteria with examples of strong vs. weak answers per rubric category
  • Common pitfalls and how to address them in debrief

Grade the reasoning quality, not whether the student picked the same percentages as the model answer.

Model Design A: Decentralized Ride-Share Platform

RIDE Token — Model Answer

Token Utility: RIDE tokens serve three functions: (1) payment medium between riders and drivers on-platform, (2) governance votes on fee structures and protocol upgrades, (3) staking requirement for drivers to activate on-platform (skin in the game to prevent fraud). This three-function design creates genuine demand without pure speculation.

Supply Model: Deflationary with burn
Total supply: 1,000,000,000 RIDE (fixed cap). 1% of every ride payment is burned, creating deflation as adoption grows. This directly links token value to platform usage — more rides = more burns = fewer tokens = higher price per token. Rationale: deflationary models align driver and rider incentives with the token's long-term value.

Distribution (sums to 100%):

Team 15%
Investors 15%
Drivers 30%
Treasury 20%
Ecosystem 10%
Public Sale 10%
Team: 15%
Investors: 15%
Driver Rewards: 30%
Treasury: 20%
Ecosystem/Grants: 10%
Public Sale: 10%

Vesting Schedule:

AllocationCliffVestingRationale
Team (15%)12 months36 months linear after cliffAligns team incentives with long-term success; prevents early exit
Investors (15%)6 months24 months linear after cliffShorter than team (investor rights) but prevents immediate dump
Driver Rewards (30%)NoneEarned over 5 years based on rides completedImmediate access needed for driver participation; earned not dumped
Treasury (20%)NoneGoverned by DAO voteFlexibility for protocol needs; DAO prevents unilateral use
Ecosystem (10%)NoneMilestone-gated grantsReleased only upon delivery of integrations/partnerships
Public Sale (10%)NoneImmediately liquid (sold at launch)Creates initial liquidity and price discovery

Value Capture Mechanism: Burn + staking. Drivers must stake 1,000 RIDE to operate (locks ~9% of supply at full adoption). Fee burns remove tokens from circulation. Governance utility prevents complete sell-off by active community members. Three mechanisms collectively create holding demand.

Model Design B: Decentralized Content Platform

CREATE Token — Model Answer

Token Utility: CREATE enables: (1) tipping creators directly (micropayment utility), (2) unlocking premium content (access utility), (3) curation staking — stake tokens on content to earn a share of its revenue (curation utility). Curation staking solves the "quality signal" problem by aligning curators' financial incentives with surfacing good content.

Supply Model: Inflationary with cap
Total supply: 500,000,000 CREATE initially, 5% annual inflation for 4 years (max ~600M), then fixed. Inflation funds creator rewards without depleting treasury. After cap reached, burns from platform fees create deflationary pressure. Rationale: early inflationary supply bootstraps creator ecosystem; deflation kicks in once network is mature.

Distribution (sums to 100%):

Team 12%
Inv 12%
Creator Rewards 35%
Treasury 21%
Eco 10%
Public 10%

Key Design Choices:

  • 35% to creators — The most important stakeholder group. Without creators, no users. High allocation signals mission alignment.
  • Curation staking prevents free-rider problem on quality signals — curators only earn if content they back succeeds.
  • No "foundation" category — treasury serves this purpose; reduces centralization risk by making funds governance-controlled.

Vesting: Team: 12-month cliff, 36-month linear. Investors: 6-month cliff, 18-month linear. Creator rewards: no cliff (earned through activity). Treasury: DAO-governed with time-lock on large disbursements.

Model Design C: Decentralized Lending Protocol

LEND Token — Model Answer

Token Utility: LEND provides: (1) governance — vote on supported collateral types, interest rate models, risk parameters; (2) fee discount — protocol borrowing fee reduced by 25% when paying in LEND (demand sink); (3) safety module — stake LEND as last-resort insurance against shortfall events, earning 8% APY. Aave's AAVE token is the real-world reference for this design.

Supply Model: Fixed supply with buyback
Total supply: 100,000,000 LEND (hard cap). Protocol earns fees from interest rate spreads. 20% of protocol revenue used to buy back and burn LEND quarterly. No inflation — scarcity is maintained by buybacks. Rationale: connects token value directly to protocol revenue; the more lending activity, the more buybacks, the higher token value.

Distribution (sums to 100%):

Team 18%
Investors 20%
Liquidity Mining 25%
Treasury 22%
Public Sale 15%

Key Design Choices:

  • 25% to liquidity mining — Lending protocols live or die by their initial liquidity. Bootstrapping lenders and borrowers with token rewards is standard practice (Compound, Aave both did this).
  • Safety module staking addresses agency problem between tokenholders and protocol users — tokenholders are at risk if they vote in dangerous collateral types.
  • Revenue buyback is more capital-efficient than dividends in a DAO context (avoids taxable events for holders).

Vesting: Team: 12-month cliff, 48-month linear (longer cliff = more trust signal). Investors: 6-month cliff, 24-month linear. Liquidity mining: 0 cliff but 4-year distribution schedule prevents front-running.

Evaluation Guidance by Rubric Category

Token Utility Design (15 points)

Strong answer (13-15 pts): Token has 2+ distinct utility functions. Each function is necessary for the platform to operate — you cannot easily replace the token with USD. The student can explain WHY the token is essential, not just WHAT it does. References to specific mechanisms (burn, staking, governance) with explanations of how they create demand.
Weak answer (0-7 pts): "The token is used to buy things on our platform." Single utility. Token could be replaced by credit card. No explanation of why a blockchain token is needed vs. a traditional payment system. No demand-side mechanism.

Distribution Fairness (10 points)

Strong answer (9-10 pts): Distribution adds to exactly 100%. Each allocation has a named purpose. Community/ecosystem share is >40% combined. Team share is 10-20% (not >25%). Investor share is 10-20%. Student can defend every percentage with a specific rationale — not "because other projects do it."
Weak answer (0-4 pts): Does not add to 100%. Team takes >30% with no justification. Community share <20%. No rationale provided for allocations. "Investors get 40% because they funded us." Concentration risk ignored.

Vesting Schedule Quality (10 points)

Strong answer (9-10 pts): Specific months/years stated for every allocation (e.g., "12-month cliff, 36-month linear"). Cliff-then-linear structure for team and investors. Community/reward distributions have release schedules tied to activity or governance milestones. Student can explain what "cliff" means and why it's used.
Weak answer (0-4 pts): "Tokens vest gradually." No specific timeframe. Missing cliff definition. Team tokens available immediately or within 3 months. No rationale for schedule choices.

Incentive Alignment (10 points)

Strong answer (9-10 pts): Student has thought adversarially — "what if the team dumps after 12 months?" and designed against it. References specific course concepts: agency problem (team vs. users), Sybil attack (fake users farming rewards), free-rider problem (using protocol without contributing). Shows how the design addresses each.
Weak answer (0-4 pts): Does not consider attack vectors. Cannot explain how any stakeholder group's incentives are aligned. Only describes the "happy path" — assumes all participants act honestly.

Presentation Clarity (5 points)

Strong answer (5 pts): All group members speak. Pie chart is clearly labeled. Presentation is within 5-minute limit. Questions from peers are answered with specific reasoning, not defensiveness. Team acknowledges at least one weakness in their design.
Weak answer (0-2 pts): One person presents while others are silent. Chart is unlabeled or missing. Over/under time significantly. Cannot respond to any critical questions.

Common Pitfalls to Address in Debrief

  • "Our token will be worth $X in year 3": No projection is legitimate without a demand model. The token's value depends entirely on adoption, not the team's wishful thinking. Ask: what happens to token price if adoption is 10% of projection?
  • Copying Ethereum's distribution: ETH did not have a team allocation cap — it was controversial. Later projects (Uniswap, Aave) learned from this and gave larger community shares. Context matters.
  • Team cliff = 1 month: A 1-month cliff provides essentially no protection. The VC-standard 1-year cliff exists for a reason. Challenge any cliff under 6 months.
  • "Governance token" with no actual governance rights: Many projects claim governance utility but governance decisions are already made by the core team. Ask: which specific parameters can token holders actually vote to change?
  • Inflation with no cap or burn mechanism: Pure inflation without a ceiling devalues the token indefinitely. Every inflationary token needs a counterbalancing deflation mechanism (burn, buyback, cap).
  • Treasury controlled by founders: A DAO treasury controlled by a multisig owned by founders is not decentralized. Students should specify governance requirements for large treasury disbursements.
Real-World Reference Designs Students Should Know: Uniswap (UNI) — 60% community, 40% insiders with 4-year vesting. Compound (COMP) — governance + liquidity mining. Aave (AAVE) — safety module + fee discounts. Curve (CRV) — vote-escrowed locking (longer lock = more governance power). These are canonical examples to reference during debrief.

© Joerg Osterrieder 2025-2026. All rights reserved.