Skill: sp0oby/game-theory (version 1.0.0)

--- name: game-theory description: Advanced game theory analysis for crypto protocols, DeFi mechanisms, governance systems, and strategic decision-making. Use when analyzing tokenomics, evaluating protocol incentives, predicting adversarial behavior, designing mechanisms, or understanding strategic interactions in web3. metadata: {"clawdbot":{"emoji":"","homepage":"https://github.com/tedkaczynski-the-bot/game-theory"}} --- # Game Theory for Crypto Strategic analysis framework for understanding and designing incentive systems in web3. > "Every protocol is a game. Every token is an incentive. Every user is a player. Understand the rules, or become the played." ## When to Use This Skill - Analyzing tokenomics for exploits or misaligned incentives - Evaluating governance proposals and voting mechanisms - Understanding MEV and adversarial transaction ordering - Designing auction mechanisms (NFT drops, token sales, liquidations) - Predicting how rational actors will behave in a system - Identifying attack vectors in DeFi protocols - Modeling liquidity provision strategies - Assessing protocol sustainability ## Core Framework ### The Five Questions For any protocol or mechanism, ask: 1. **Who are the players?** (Users, LPs, validators, searchers, governance token holders) 2. **What are their strategies?** (Actions available to each player) 3. **What are the payoffs?** (How does each outcome affect each player?) 4. **What information do they have?** (Complete, incomplete, asymmetric?) 5. **What's the equilibrium?** (Where do rational actors end up?) ### Analysis Template ```markdown ## Protocol: [Name] ### Players - Player A: [Role, objectives, constraints] - Player B: [Role, objectives, constraints] - ... ### Strategy Space - Player A can: [List possible actions] - Player B can: [List possible actions] ### Payoff Structure - If (A does X, B does Y): A gets [payoff], B gets [payoff] - ... ### Information Structure - Public information: [What everyone knows] - Private information: [What only some players know] - Observable actions: [What can be seen on-chain] ### Equilibrium Analysis - Nash equilibrium: [Stable outcome where no player wants to deviate] - Dominant strategies: [Strategies that are always best regardless of others] - Potential exploits: [Deviations that benefit attackers] ### Recommendations - [Design changes to improve incentive alignment] ``` ## Reference Documents | Document | Use Case | |----------|----------| | [Nash Equilibrium](references/nash-equilibrium.md) | Finding stable outcomes in strategic interactions | | [Mechanism Design](references/mechanism-design.md) | Designing systems with desired equilibria | | [Auction Theory](references/auction-theory.md) | Token sales, NFT drops, liquidations | | [MEV Game Theory](references/mev-strategies.md) | Adversarial transaction ordering | | [Tokenomics Analysis](references/tokenomics-analysis.md) | Evaluating token incentive structures | | [Governance Attacks](references/governance-attacks.md) | Voting manipulation and capture | | [Liquidity Games](references/liquidity-games.md) | LP strategies and impermanent loss | | [Information Economics](references/information-economics.md) | Asymmetric information and signaling | ## Quick Concepts ### Nash Equilibrium A state where no player can improve their payoff by unilaterally changing strategy. The "stable" outcome of a game. **Crypto application:** In a staking system, Nash equilibrium determines the stake distribution across validators. ### Dominant Strategy A strategy that's optimal regardless of what others do. **Crypto application:** In a second-price auction, bidding your true value is dominant. ### Pareto Efficiency An outcome where no one can be made better off without making someone worse off. **Crypto application:** AMM fee structures try to be Pareto efficient for traders and LPs. ### Mechanism Design "Reverse game theory" - designing rules to achieve desired outcomes. **Crypto application:** Designing token vesting schedules to align long-term incentives. ### Schelling Point A solution people converge on without communication. **Crypto application:** Why certain price levels act as psychological support/resistance. ### Incentive Compatibility When truthful behavior is optimal for participants. **Crypto application:** Oracle designs where honest reporting is the dominant strategy. ### Common Knowledge Everyone knows X, everyone knows everyone knows X, infinitely recursive. **Crypto application:** Public blockchain state creates common knowledge of balances/positions. ## Analysis Patterns ### Pattern 1: The Tragedy of the Commons **Structure:** Shared resource, individual incentive to overuse, collective harm. **Crypto examples:** - Gas price bidding during congestion - Governance token voting apathy - MEV extraction degrading UX **Solution approaches:** - Harberger taxes - Quadratic mechanisms - Commitment schemes ### Pattern 2: The Prisoner's Dilemma **Structure:** Individual rationality leads to collective irrationality. **Crypto examples:** - Liquidity mining mercenaries (farm and dump) - Race-to-bottom validator fees - Bridge security (each chain wants others to secure) **Solution approaches:** - Repeated games (reputation) - Commitment mechanisms (staking/slashing) - Mechanism redesign ### Pattern 3: The Coordination Game **Structure:** Multiple equilibria, players want to coordinate but may fail. **Crypto examples:** - Which L2 to use? - Token standard adoption - Hard fork coordination **Solution approaches:** - Focal points (Schelling points) - Sequential moves (first mover advantage) - Communication mechanisms ### Pattern 4: The Principal-Agent Problem **Structure:** One party acts on behalf of another with misaligned incentives. **Crypto examples:** - Protocol team vs token holders - Delegates in governance - Fund managers **Solution approaches:** - Incentive alignment (token vesting) - Monitoring (transparency) - Bonding (skin in game) ### Pattern 5: Adverse Selection **Structure:** Information asymmetry leads to market breakdown. **Crypto examples:** - Token launches (team knows more than buyers) - Insurance protocols (risky users more likely to buy) - Lending (borrowers know their risk better) **Solution approaches:** - Signaling (lock-ups, audits) - Screening (credit scores, history) - Pooling equilibria ### Pattern 6: Moral Hazard **Structure:** Hidden action after agreement leads to risk-taking. **Crypto examples:** - Protocols with insurance may take more risk - Bailout expectations encourage leverage - Anonymous teams may rug **Solution approaches:** - Monitoring and transparency - Incentive alignment - Reputation systems ## Common Crypto Games ### The MEV Game **Players:** Users, searchers, builders, validators **Key insight:** Transaction ordering is a game; users are often the losers See: [MEV Strategies](references/mev-strategies.md) ### The Liquidity Game **Players:** LPs, traders, arbitrageurs **Key insight:** Impermanent loss is the cost of being adversely selected against See: [Liquidity Games](references/liquidity-games.md) ### The Governance Game **Players:** Token holders, delegates, protocol team **Key insight:** Rational apathy + concentrated interests = capture See: [Governance Attacks](references/governance-attacks.md) ### The Staking Game **Players:** Stakers, validators, delegators **Key insight:** Security budget must exceed attack profit See: [Tokenomics Analysis](references/tokenomics-analysis.md) ### The Oracle Game **Players:** Data providers, consumers, attackers **Key insight:** Profit from manipulation must be less than cost See: [Mechanism Design](references/mechanism-design.md) ## Red Flags in Protocol Design ### Tokenomics Red Flags - Insiders can sell before others (vesting asymmetry) - Inflation benefits few, dilutes many - No sink mechanisms (perpetual selling pressure) - Rewards without risk (free money = someone else paying) ### Governance Red Flags - Low quorum thresholds (minority capture) - No time delay (flash loan attacks) - Token voting only (plutocracy) - Delegates with no skin in game ### Mechanism Red Flags - First-come-first-served (bot advantage) - Sealed bids without commitment (frontrunning) - Rebates/refunds (MEV extraction) - Complex formulas (hidden exploits) ## Advanced Topics ### Repeated Games and Reputation Single-shot games often have bad equilibria. Repetition enables cooperation through: - Trigger strategies (cooperate until defection) - Reputation building (costly to destroy) - Future value (patient players cooperate more) **Crypto application:** Why anonymous actors behave worse than doxxed teams. ### Evolutionary Game Theory Strategies that survive competitive selection. Relevant for: - Which protocols survive long-term - Memetic competition between narratives - Bot strategy evolution ### Bayesian Games Games with incomplete information. Players have beliefs about others' types. **Crypto application:** Trading with unknown counterparties, evaluating anonymous teams. ### Cooperative Game Theory When players can form binding coalitions. **Crypto application:** MEV extraction coalitions, validator cartels, governance blocs. ### Algorithmic Game Theory Computational aspects of game theory. **Crypto application:** On-chain game computation limits, gas-efficient mechanism design. ## Methodology ### Step 1: Model the Game - Identify all players (including those not obvious) - Map complete strategy spaces - Define payoff functions precisely - Specify information structure ### Step 2: Find Equilibria - Check for dominant strategies - Compute Nash equilibria - Identify Pareto improvements - Consider trembling-hand perfection ### Step 3: Stress Test - What if players collude? - What if new players enter? - What if information leaks? - What if parameters change? ### Step 4: Recommend - Mechanism changes to improve equilibrium - Monitoring to detect deviations - Parameter bounds to maintain stability ## Resources ### Foundational Texts - "Theory of Games and Economic Behavior" - von Neumann & Morgenstern - "A Beautiful Mind" (Nash's life, accessible intro) - "The Strategy of Conflict" - Schelling - "Mechanism Design Theory" - Myerson (Nobel lecture) ### Crypto-Specific - "Flash Boys 2.0" - MEV paper - "SoK: DeFi Attacks" - Systemization of DeFi exploits - "Clockwork Finance" - MEV and mechanism design - Paradigm research blog ### Tools - Nashpy (Python game theory library) - Gambit (game theory software) - Agent-based modeling frameworks

path: examples/uniswap-v3-analysis.md
content: # Game Theory Analysis: Uniswap V3

Comprehensive strategic analysis of concentrated liquidity AMM.

## Overview

**Protocol:** Uniswap V3
**Innovation:** Concentrated liquidity (LPs choose price ranges)
**Key Question:** How does this change the game for all participants?

## Player Analysis

### Liquidity Providers (LPs)

**Objective:** Maximize risk-adjusted returns

**Strategy space:**
- Which pools to enter
- What price range to set
- When to rebalance
- How much capital to deploy

**Information:**
- Current prices (public)
- Historical volatility (public)
- Own risk tolerance (private)
- Rebalancing capacity (private)

### Traders

**Objective:** Execute trades at best prices

**Strategy space:**
- Route selection (which pools)
- Timing
- Order size
- Slippage tolerance

**Information:**
- Current prices (public)
- Liquidity depth (public)
- Trade intent (private)

### Arbitrageurs

**Objective:** Profit from price discrepancies

**Strategy space:**
- Cross-venue arbitrage
- Cross-pool arbitrage
- Speed/latency investment

**Information:**
- All public prices
- Mempool visibility (varies)
- Execution infrastructure (private)

### JIT Liquidity Providers

**Objective:** Capture fees from large trades

**Strategy space:**
- Monitor mempool
- Predict trade impact
- Position liquidity precisely
- Remove after execution

**Information:**
- Pending transactions (mempool)
- Price impact models
- Execution speed (private)

## Game Transformation: V2 to V3

### The V2 Game

**LP strategy:** Deposit and wait. All liquidity at all prices.

**Equilibrium:** 
- Passive LPs dominate
- Returns = fees - IL
- Little strategic differentiation

### The V3 Game

**LP strategy:** Active range management required.

**New dimensions:**
- Range selection (tight vs. wide)
- Active management (rebalancing)
- Capital efficiency competition

**Equilibrium shift:**
- Passive LPs disadvantaged
- Professional LPs gain edge
- Greater returns for skilled, lower for unskilled

## Strategic Analysis

### LP Range Selection Game

**Setup:** Multiple LPs choosing ranges around current price P.

**Narrow range (P ± 1%):**
- Pros: Higher capital efficiency, more fees per dollar
- Cons: Quickly goes out of range, requires monitoring

**Wide range (P ± 50%):**
- Pros: Always in range, less management
- Cons: Lower capital efficiency, less fees per dollar

**Nash equilibrium analysis:**

If all LPs go narrow:
- Intense competition at current price
- Slight price move = many out of range
- Opportunity for wide-range LPs to capture distant trades

If all LPs go wide:
- Less competition at current price
- Opportunity for narrow LPs to capture concentrated fees

**Mixed equilibrium:** Distribution of range widths based on:
- LP's rebalancing capacity
- Risk tolerance
- Belief about volatility

### The Adverse Selection Problem

**Intensified in V3:**

In V2, IL was distributed across infinite range.
In V3, IL concentrated in active range.

**Who trades in your range?**
- Uninformed traders (good for LP)
- Arbitrageurs (bad for LP)
- Sandwich attackers (bad for LP)

**Concentrated liquidity amplifies adverse selection:**
- Tighter range = more exposed to informed flow
- Arbitrageurs target densest liquidity
- JIT compounds the problem

### JIT Liquidity Game

**Sequential game:**

1. Large trade enters mempool
2. JIT LP observes, decides to front-run
3. JIT adds concentrated liquidity at execution price
4. Trade executes, JIT captures most fees
5. JIT removes liquidity

**Passive LP payoff:** Minimal fees (crowded out by JIT)
**JIT LP payoff:** Fees minus gas and MEV costs

**Equilibrium implications:**
- JIT makes passive narrow-range LP less viable
- Passive LPs must go wider or more active
- Fee capture shifts to MEV infrastructure

### Protocol Fee Game

**Uniswap can turn on protocol fee (up to 25% of LP fees).**

**Game:**
- If fees on: LP returns decrease, some LPs leave
- If fees off: LP returns higher, more liquidity
- UNI holders want fees (governance revenue)
- Users want deep liquidity (lower slippage)

**Current equilibrium:** Fees off (competitive pressure).

**Future possibilities:**
- Fees may turn on if competition lessens
- UNI value accrual remains uncertain
- Governance game between holders and users

## Payoff Analysis

### LP Expected Returns

```
E[Return] = E[Fees] - E[IL] - E[Gas for rebalancing] - Opportunity cost

Where:
- E[Fees] = f(volume, range, competition)
- E[IL] = f(volatility, range width, adversarial flow)
- Gas = f(rebalancing frequency, network conditions)
```

### Conditions for Profitable LP

**Profitable when:**
```
Fee APY > IL APY + Gas costs + Risk-free rate

Approximately:
Volume/TVL * Fee tier * Range multiplier > Volatility impact
```

**Empirical finding:** Many V3 positions are unprofitable after IL.

### Winners and Losers

**Winners in V3:**
- Sophisticated LPs (active management)
- JIT liquidity providers (MEV extraction)
- Traders (tighter spreads)
- Arbitrageurs (more opportunities)

**Losers in V3:**
- Passive retail LPs (adverse selection)
- Simple bots (outcompeted)

## Mechanism Design Evaluation

### What V3 Gets Right

1. **Capital efficiency:** Real improvement for active LPs
2. **Better prices:** Traders benefit from concentrated liquidity
3. **Flexibility:** Multiple fee tiers, range choices
4. **Permissionless:** Anyone can participate

### What V3 Gets Wrong

1. **Complexity:** Most users don't understand ranges
2. **Adverse selection:** Concentrated = more toxic
3. **MEV vulnerability:** JIT attacks enabled
4. **Inequality:** Sophisticated >> unsophisticated

### Design Trade-offs

| V2 | V3 |
|----|-----|
| Simple | Complex |
| Passive-friendly | Active-required |
| Spread IL across range | Concentrate IL |
| Lower capital efficiency | Higher capital efficiency |
| Retail-accessible | Professional-favoring |

## Strategic Recommendations

### For Passive LPs

1. **Use V2 or wide V3 ranges:** Don't compete on concentration
2. **Stick to stable pairs:** Lower IL, less rebalancing
3. **Use LP aggregators:** Outsource management
4. **Understand your edge:** If none, reconsider LPing

### For Active LPs

1. **Invest in infrastructure:** Monitoring, rebalancing automation
2. **Specialize:** Focus on specific pairs/strategies
3. **Consider hedging:** Options to offset IL
4. **Monitor JIT:** Adjust if being front-run

### For Protocol Designers

1. **Consider V2-style simplicity** for retail-focused pools
2. **Implement MEV protection** (encrypted mempools, batch auctions)
3. **Provide better tooling** for range selection
4. **Share MEV with LPs** (MEV-Share integration)

## Conclusion

Uniswap V3 shifted the AMM game from passive to active, benefiting sophisticated players at the expense of retail LPs. The mechanism design prioritized capital efficiency over accessibility, creating a more complex strategic environment.

**Key insight:** Concentrated liquidity is a tool for professionals. Retail LPs should either professionalize, use aggregators, or reconsider participation.

**Game-theoretic verdict:** V3 is a more efficient mechanism for price discovery and trading, but redistributes value from unsophisticated to sophisticated participants.


path: references/auction-theory.md
content: # Auction Theory

Game theory of competitive bidding mechanisms.

## Auction Formats

### First-Price Sealed Bid

**Rules:**
- Bidders submit sealed bids
- Highest bid wins
- Winner pays their bid

**Equilibrium strategy:**
- Bid below true value (shade bid)
- Amount of shading depends on number of bidders, value distribution
- More bidders → less shading

**Crypto applications:**
- Most NFT auctions
- Block space auctions (effectively)
- MEV bundle auctions

### Second-Price Sealed Bid (Vickrey)

**Rules:**
- Bidders submit sealed bids
- Highest bid wins
- Winner pays second-highest bid

**Dominant strategy:** Bid exactly your true value.

**Why?**
- Bid higher: Risk paying more than value
- Bid lower: Risk losing when you'd profit
- Bid true value: Optimal regardless of others

**Crypto applications:**
- Some NFT platforms (rare)
- Theoretical ideal for many mechanisms

### English Auction (Ascending)

**Rules:**
- Price starts low, increases
- Bidders drop out as price rises
- Last remaining bidder wins at final price

**Strategically equivalent to second-price** for independent private values.

**Crypto applications:**
- Live NFT auctions
- Real-time bidding interfaces

### Dutch Auction (Descending)

**Rules:**
- Price starts high, decreases
- First bidder to accept wins at that price

**Strategically equivalent to first-price.**

**Crypto applications:**
- Fair launches (price discovery)
- Token sales
- Reduces gas wars

### All-Pay Auction

**Rules:**
- All bidders pay their bids
- Highest bid wins

**Game theory:**
- Aggressive bidding (since you pay regardless)
- Expected revenue can exceed value
- Models competitive lobbying, rent-seeking

**Crypto applications:**
- Gas price auctions (failed txs still pay)
- Priority fee competition

## Revenue Equivalence Theorem

**Statement:** Under certain conditions, all standard auctions yield the same expected revenue.

**Conditions:**
- Risk-neutral bidders
- Independent private values
- Symmetric bidders
- Payment only by winner

**Implication:** Auction format choice doesn't affect expected revenue.

**When it breaks:**
- Risk-averse bidders
- Common values (winner's curse)
- Asymmetric information
- Collusion possible

## Common Value Auctions

**Setting:** Object has same value to all bidders, but value is uncertain.

**Example:** Oil drilling rights, token launch pricing.

### Winner's Curse

**Problem:** Winner tends to be the bidder who most overestimated value.

**Game theory:**
- Rational bidders shade bids to account for this
- Winning = signal you may have overestimated
- Naive bidders suffer losses

**Crypto relevance:**
- NFT speculators often fall victim
- Token launch prices may reflect winner's curse
- Sophisticated bidders adjust

## Auction Design for Crypto

### NFT Auctions

**Considerations:**
- Gas costs affect minimum viable bid
- Front-running risk in on-chain bidding
- Reserve prices and creator royalties
- Bundle sales and lots

**Common issues:**
- Shill bidding (fake bids to raise price)
- Wash trading (fake volume)
- Sniping (last-second bids)

### Token Sale Auctions

**Dutch auction for fair launch:**
1. Price starts high
2. Decreases over time
3. Participants commit funds at current price
4. Auction ends when all tokens allocated
5. Everyone pays final clearing price

**Advantages:**
- Price discovery
- No gas wars
- Fair access (time preference only)

**Challenges:**
- Requires patience from buyers
- Price may fall below expectations
- Can be gamed with large buys

### MEV Auctions

**Flashbots-style:**
- Searchers bid to builders
- Builders bid to proposers
- Auction for transaction ordering rights

**Design goals:**
- Efficient MEV extraction
- Reduce negative externalities
- Distribute value fairly

### Liquidation Auctions

**Design considerations:**
- Speed (faster = more stable system)
- Efficiency (maximize recovery)
- Participation (enough liquidators)

**Common formats:**
- Fixed discount (simple, may be too generous)
- Dutch auction (price discovery)
- Batch auction (efficient, slower)

## Collusion in Auctions

### Bid Rigging

**Mechanisms:**
- Designated winner (others don't bid)
- Bid rotation (take turns winning)
- Compensation (side payments to losers)

**Defense:**
- Reserve prices
- Sealed bids
- Multiple rounds
- Detection algorithms

### On-Chain Collusion

**Easier in crypto because:**
- Pseudonymous (hard to identify colluders)
- Smart contracts can enforce agreements
- DAOs can coordinate bidding

**Harder in crypto because:**
- Transparent (all bids visible)
- Permissionless (anyone can bid)
- Competitive (many potential entrants)

## Optimal Auction Design

### Myerson's Optimal Auction

**For revenue-maximizing seller:**
- Set reserve price above zero
- Exclude low-value bidders
- Optimal reserve depends on value distribution

**Crypto application:**
- NFT reserve prices
- Token sale minimums
- Validator slot auctions

### Mechanism Design Trade-offs

| Goal | Tension |
|------|---------|
| Revenue maximization | vs. Participation |
| Efficiency (allocation to highest value) | vs. Revenue |
| Simplicity | vs. Optimality |
| Fairness | vs. Efficiency |
| Speed | vs. Price discovery |

## Practical Guidelines

### For Sellers

1. **Know your buyers:** Are values private or common?
2. **Set appropriate reserves:** Too high = no sale, too low = leaving money
3. **Choose format for goals:** Revenue vs. speed vs. fairness
4. **Prevent collusion:** Mix of bidders, sealed bids
5. **Consider UX:** Complex auctions deter participation

### For Bidders

1. **Understand format:** Know what strategy is optimal
2. **Avoid winner's curse:** Discount for common value components
3. **Watch for shill bids:** Unusual bidding patterns
4. **Consider all-in costs:** Gas, time, opportunity cost
5. **Don't get emotional:** Set max bid, stick to it


path: references/governance-attacks.md
content: # Governance Attacks

Game-theoretic analysis of how governance systems fail.

## The Governance Game

**Players:**
- Token holders (various sizes)
- Delegates
- Protocol team
- Attackers
- Affected users (often not token holders)

**The fundamental tension:** Those with governance power may not be those affected by decisions.

## Attack Categories

### 1. Plutocratic Capture

**Mechanism:** Wealthy actor acquires controlling stake.

**Game theory:**
- Cost of attack = cost to acquire 51% of voting power
- Profit = value extracted from protocol
- Attack is rational if Profit > Cost

**Calculation:**
```
Voting power needed: V (e.g., 51% of quorum)
Token price: P
Cost to acquire: V * P * (1 + slippage)
Extractable value: X
Attack profitable if: X > V * P * (1 + slippage)
```

**Real examples:**
- Beanstalk: $182M governance attack
- Build Finance: Complete protocol takeover

**Defenses:**
- High token market cap relative to TVL
- Time delays on execution
- Rage quit mechanisms
- Multi-sig vetoes

### 2. Flash Loan Governance

**Mechanism:** Borrow tokens, vote, return in same transaction.

**Game theory:**
- Cost = flash loan fee + gas
- Nearly zero capital requirement
- Only works if voting is instant

**Requirements for attack:**
- No lock-up period for voting
- No snapshot before proposal
- Flash loan liquidity available

**Defenses:**
- Snapshot at proposal creation
- Time-weighted voting power
- Lock-up requirements
- Delegation restrictions

### 3. Bribing Attacks

**Mechanism:** Pay token holders to vote a certain way.

**Types:**

**Direct bribing:**
- "Vote YES on Proposal X, receive $Y per token"
- Coordination via bribe platforms (Votium, Hidden Hand)

**Indirect bribing:**
- Offer staking rewards contingent on voting
- Airdrop promises for supporters

**Dark bribing:**
- Private deals with whales
- Quid pro quo arrangements
- Undetectable on-chain

**Game theory:**
- Cost of bribe per vote = marginal voter's reservation price
- Often very low (most voters are apathetic)
- Concentrated interests can outbid diffuse opposition

**Defenses:**
- Secret voting (reduces targeting)
- Conviction voting (time-weighted)
- Quadratic voting (expensive to buy large influence)
- Futarchy (separate values from beliefs)

### 4. Voter Apathy Exploitation

**Mechanism:** Low turnout allows minority control.

**Game theory:**
- Expected value of single vote ≈ 0 for small holders
- Rational to not participate (gas cost > impact)
- Creates opportunity for organized minorities

**Typical pattern:**
- Quorum: 4% of tokens
- Actual turnout: 2% of holders
- Effective control: ~2% of total supply

**Real examples:**
- Most DAO votes pass with <5% participation
- Quorum requirements routinely unmet
- Team/investor bloc often decisive

**Defenses:**
- Delegation (passive holders delegate)
- Incentivized voting (rewards for participation)
- Lower stakes decisions (reduce attack surface)
- Representative democracy models

### 5. Governance Extraction

**Mechanism:** Insiders use governance to extract value.

**Forms:**

**Treasury raids:**
- Propose "grants" to insider-controlled entities
- "Partnerships" with affiliated projects

**Salary manipulation:**
- Approve excessive compensation
- Hire friends/family

**Parameter manipulation:**
- Change fee structures to favor insiders
- Adjust emission to benefit specific holders

**Game theory:**
- Insiders have information advantage
- Costs distributed, benefits concentrated
- Difficult for outside observers to evaluate

**Defenses:**
- Transparency requirements
- Independent oversight
- Rage quit mechanisms
- Token holder activism

### 6. Proposal Spamming

**Mechanism:** Flood governance with proposals to exhaust voters.

**Game theory:**
- Defender must evaluate each proposal
- Attacker can generate cheaply
- Asymmetric costs

**Defenses:**
- Proposal deposits (refunded if passed)
- Spam filtering
- Delegate specialization

### 7. Last-Minute Attacks

**Mechanism:** Submit or modify proposals just before deadline.

**Game theory:**
- Reduces time for opposition to organize
- Exploits voter inattention
- Works best with short voting periods

**Defenses:**
- Minimum voting periods
- No late amendments
- Mandatory review periods

### 8. Social Engineering

**Mechanism:** Manipulate community sentiment to pass harmful proposals.

**Tactics:**
- Sybil sock puppets creating fake consensus
- Discord/forum manipulation
- Influencer coordination
- FUD against opposition

**Game theory:**
- Information asymmetry between attackers and voters
- Social proof exploitation
- Reputation laundering

**Defenses:**
- Verified identity systems
- Reputation tracking
- Independent analysis requirements
- Cooling-off periods

## Defense Mechanisms

### Time Locks

**Mechanism:** Delay between proposal passing and execution.

**Trade-off:**
- Longer delay = more time to detect attacks
- Longer delay = slower response to legitimate needs

**Typical values:** 24 hours to 7 days

### Optimistic Governance

**Mechanism:** Proposals pass unless challenged.

**Game theory:**
- Reduces burden on passive voters
- Shifts work to active monitors
- Requires effective challenge mechanism

**Design:**
- Challenge period
- Challenge bond
- Dispute resolution

### Rage Quit

**Mechanism:** Allow exit before proposal executes.

**Game theory:**
- Limits governance attack profitability
- Exit value = floor on extraction
- May cause coordination problems

**Implementation:**
- Window after vote, before execution
- Pro-rata share of treasury
- May exclude illiquid assets

### Veto Power

**Mechanism:** Designated party can block proposals.

**Types:**
- Security council veto
- Token holder supermajority override
- Time-limited during bootstrap

**Trade-off:**
- Protects against attacks
- Centralizes power
- Reduces legitimacy

### Quadratic Mechanisms

**Voting:** Vote power = sqrt(tokens)
**Funding:** Matching based on number of contributors, not amount

**Game theory:**
- Reduces plutocracy
- Increases Sybil vulnerability
- Requires identity/collusion resistance

### Conviction Voting

**Mechanism:** Vote weight increases the longer tokens are committed.

**Game theory:**
- Rewards conviction, punishes flash attacks
- Complex dynamics
- Can be gamed with advance positioning

### Futarchy

**Mechanism:** Vote on values, bet on beliefs.

**Game theory:**
- Separates normative from positive questions
- Harnesses prediction markets
- Experimental, limited deployment

## Governance Security Checklist

### Before Launching Governance

- [ ] TVL < 10x governance attack cost?
- [ ] Time lock on all critical functions?
- [ ] Snapshot-based voting?
- [ ] Rage quit mechanism?
- [ ] Multi-sig backstop during bootstrap?

### Ongoing Monitoring

- [ ] Track large token accumulation
- [ ] Monitor proposal quality
- [ ] Watch for coordinated voting
- [ ] Analyze voter participation trends
- [ ] Review executed proposal outcomes

### Red Flags

- [ ] Single entity approaching quorum threshold
- [ ] Unusual delegation patterns
- [ ] Last-minute proposal changes
- [ ] Coordinated social media campaigns
- [ ] Proposals benefiting narrow interests

## Case Studies

### Beanstalk ($182M)

**Attack:**
1. Attacker took flash loan of governance tokens
2. Proposed malicious proposal
3. Voted with borrowed tokens
4. Proposal passed and executed in same transaction
5. Drained protocol treasury

**Lessons:**
- Flash loan attacks are real
- No time lock = instant execution
- Snapshot must precede proposal

### Build Finance (100%)

**Attack:**
1. Attacker accumulated tokens quietly
2. Proposed to transfer treasury to attacker
3. Had enough votes to pass
4. Complete protocol capture

**Lessons:**
- Monitor token accumulation
- Emergency governance needed
- Rage quit would have helped

### Compound Proposal 62

**Near-attack:**
1. Proposal to distribute $24M to "DeFi Education Fund"
2. Controlled by small group
3. Passed despite controversy
4. Highlighted plutocracy issues

**Lessons:**
- "Legal" extraction is possible
- Community vigilance required
- Reputation effects may not deter

## Game-Theoretic Recommendations

### For Protocol Designers

1. **Make attacks expensive:** High quorum, time locks, rage quit
2. **Make extraction visible:** Transparency, monitoring
3. **Align incentives:** Token value tied to protocol health
4. **Limit governance scope:** Minimize attack surface
5. **Plan for failure:** Emergency mechanisms, upgradability

### For Token Holders

1. **Participate or delegate:** Don't be the apathetic majority
2. **Monitor proposals:** Set up alerts
3. **Coordinate defense:** Build coalitions against attacks
4. **Demand transparency:** Question complex proposals
5. **Exit if necessary:** Use rage quit if available

### For Attackers (to understand defense)

1. **Accumulate quietly:** Avoid detection
2. **Time proposals:** Exploit low-attention periods
3. **Divide opposition:** Propose multiple conflicting changes
4. **Use social engineering:** Control narrative
5. **Extract incrementally:** Many small raids vs. one big one


path: references/information-economics.md
content: # Information Economics

Strategic implications of asymmetric information in crypto.

## Core Concepts

### Asymmetric Information

One party knows something others don't.

**In crypto:**
- Team knows roadmap, code quality
- Insiders know upcoming announcements
- Whales know their trading intentions
- MEV searchers know mempool state

### Adverse Selection (Hidden Information)

Before transaction: One party has private information.

**Examples:**
- Token buyers don't know if team will deliver
- LPs don't know if incoming trade is informed
- Lenders don't know borrower's true risk

**Result:** Market breakdown or inefficient pricing.

### Moral Hazard (Hidden Action)

After agreement: One party takes unobserved actions.

**Examples:**
- Protocol team effort after token sale
- Borrower risk-taking after loan
- Validator behavior after delegation

**Result:** Suboptimal effort, excessive risk-taking.

### Signaling

Informed party takes costly action to reveal information.

**Examples:**
- Team locks tokens (signals commitment)
- Protocol gets audited (signals security)
- Whale accumulates publicly (signals conviction)

**Requirements for effective signal:**
- Costly to fake
- Observable by uninformed party
- Correlated with true quality

### Screening

Uninformed party designs mechanism to reveal information.

**Examples:**
- Tiered token sales (whales vs. retail)
- Collateral requirements (reveal risk tolerance)
- Usage-based airdrops (reveal genuine users)

## Information Problems in Crypto

### The Lemon Problem

**Classic framing:** Used car market with unknown quality.

**Crypto version:** Token market with unknown fundamentals.

**Dynamics:**
1. Buyers can't distinguish good from bad projects
2. Offer average price
3. Good projects exit (unfairly priced)
4. Only bad projects remain
5. Market fails

**Mitigation:**
- Reputation systems
- Audits and due diligence
- Skin in the game (vesting)
- Verifiable credentials

### Insider Trading

**Information advantage:** Team/insiders know material non-public info.

**Game theory:**
- Insiders can front-run announcements
- Retail always at disadvantage
- Erodes market legitimacy

**Crypto specifics:**
- Pseudonymous = hard to detect
- On-chain = evidence exists
- Global = unclear jurisdiction

**Mitigation:**
- Trading blackout periods
- Delayed announcements
- On-chain surveillance
- Community monitoring

### MEV as Information Asymmetry

**Searchers know:**
- Pending transactions (mempool)
- Price impact of trades
- Arbitrage opportunities

**Users don't know:**
- Their order will be sandwiched
- True execution price
- Alternative routes

**Game theory:**
- Information advantage converts to profit
- Users pay invisible tax
- Arms race in information acquisition

### Oracle Manipulation

**Attacker information advantage:**
- Knows when price will be manipulated
- Can position before manipulation
- Profits from temporary deviation

**Defense requires:**
- Multiple data sources
- Manipulation-resistant aggregation
- Economic security (cost > profit)

## Signaling Mechanisms

### Token Vesting

**Signal:** Team locks tokens for extended period.

**What it signals:**
- Long-term commitment
- Confidence in future value
- Alignment with holders

**Why it works:**
- Costly if team wants to exit
- Observable on-chain
- Correlated with quality (bad teams want out)

**Limitations:**
- Can still build other revenue streams
- Delayed rug is still rug
- Linear vesting still creates sell pressure

### Audits and Certifications

**Signal:** Pay for external review.

**What it signals:**
- Code quality (somewhat)
- Commitment to security
- Professionalism

**Why it works:**
- Costly (audits expensive)
- Third-party verification
- Reputation at stake (auditor's)

**Limitations:**
- Audits miss bugs (many hacked protocols were audited)
- Quality varies widely
- May just be checkbox exercise

### Public Building

**Signal:** Develop openly, share progress.

**What it signals:**
- Technical competence
- Genuine product development
- Community orientation

**Why it works:**
- Costly to fake (requires actual work)
- Observable by technical community
- Builds reputation over time

**Limitations:**
- Competitors can copy
- Hard for non-technical observers to evaluate
- Doesn't guarantee business success

### Treasury Diversification

**Signal:** Protocol converts native token to stables.

**What it signals:**
- Planning for long-term
- Responsible financial management
- Reduced dependency on token price

**Why it works:**
- Reduces upside from token pump
- Shows operational thinking
- Aligns with sustainability

**Limitations:**
- May signal lack of confidence
- Creates sell pressure
- Timing matters

## Screening Mechanisms

### Sybil Screening

**Problem:** Distinguish real users from fake.

**Approaches:**

| Method | What It Screens For | Limitations |
|--------|---------------------|-------------|
| Minimum balance | Financial commitment | Excludes poor users |
| History-based | Past behavior | Attackers build history |
| Social graph | Network position | Can be fabricated |
| Proof of personhood | Unique human | Privacy concerns |
| Activity thresholds | Engagement | Can be botted |

### Risk Screening in Lending

**Problem:** Borrowers know their risk better than lenders.

**Approaches:**
- Collateral requirements (reveal risk tolerance)
- Interest rate tiers (self-selection)
- Credit scores (on-chain history)
- Social vouching

**Trade-off:** Better screening = less participation.

### Investor Screening

**Problem:** Distinguish committed investors from flippers.

**Approaches:**
- Lock-up requirements
- Vesting schedules
- Participation requirements
- Reputation checks

## Game-Theoretic Equilibria

### Pooling Equilibrium

All types take same action, information not revealed.

**Example:** All projects get audited (both good and bad).

**Result:** Audit doesn't distinguish quality.

### Separating Equilibrium

Different types take different actions, information revealed.

**Example:** Only good projects can afford long vesting.

**Result:** Vesting reveals quality.

### Partial Pooling

Some separation, some pooling.

**Example:** Best and worst projects don't get audited (too good to need / can't afford), middle gets audited.

## Information Design

### Strategic Information Revelation

**Question:** What should informed party reveal?

**Considerations:**
- Reveal good news, hide bad? (But then silence = bad news)
- Commit to full transparency? (May reveal competitive info)
- Selective disclosure? (Legal/ethical issues)

### Commitment Devices

**Problem:** Can't credibly commit to future actions.

**Solution:** Smart contracts as commitment.

**Examples:**
- Token vesting contracts (can't unlock early)
- Time-locked governance (can't execute immediately)
- Bonded assertions (lose stake if wrong)

**Game theory value:** Converts non-credible to credible commitments.

## Practical Applications

### Due Diligence Framework

**Information to gather:**
1. Team (background, reputation, previous projects)
2. Technology (code quality, audits, novel vs. fork)
3. Tokenomics (distribution, vesting, utility)
4. Community (size, engagement quality, organic vs. paid)
5. Competitive position (moat, differentiation)

**Red flags (information asymmetry indicators):**
- Anonymous team with large unlocked allocation
- Unverified claims about partnerships
- Unusual contract patterns
- Paid promotion without disclosure

### Reputation Systems

**Design considerations:**
- What actions are observable?
- How to aggregate into reputation?
- How to prevent gaming?
- How to allow recovery from mistakes?

**Game theory:**
- Reputation is valuable → incentivizes good behavior
- Must be hard to fake → costly signals
- Must matter → affects future opportunities


path: references/liquidity-games.md
content: # Liquidity Games

Game theory of AMMs, liquidity provision, and market making.

## The Liquidity Provider's Dilemma

LPs face a fundamental trade-off:
- **Earn fees** from trading volume
- **Lose to arbitrageurs** via adverse selection

The game is: Are fees enough to compensate for losses to informed traders?

## Players in AMM Games

### Liquidity Providers (LPs)
- Deposit assets into pools
- Earn trading fees
- Suffer impermanent loss

### Noise Traders
- Trade for non-informational reasons
- Pay fees
- LPs profit from these trades

### Arbitrageurs
- Trade to align AMM price with external price
- Extract value from LPs
- Zero-sum with LPs

### MEV Searchers
- Sandwich attacks
- JIT liquidity
- Extract from both traders and LPs

## Impermanent Loss Deep Dive

### What It Is

IL is the cost of providing liquidity vs. holding.

**Formula (constant product x*y=k):**
```
IL = 2 * sqrt(price_ratio) / (1 + price_ratio) - 1

Where price_ratio = new_price / initial_price
```

### Why It Happens

**The adverse selection explanation:**
1. External price moves (e.g., up)
2. Arbitrageur buys cheap tokens from AMM
3. LP sells at stale price
4. LP would have been better off holding

**Game theory framing:** LPs are market makers who are always on the wrong side of informed trades.

### IL vs. Price Change

| Price Change | Impermanent Loss |
|--------------|------------------|
| 1.25x (25% up) | 0.6% |
| 1.50x (50% up) | 2.0% |
| 2x (100% up) | 5.7% |
| 3x (200% up) | 13.4% |
| 5x (400% up) | 25.5% |

**Key insight:** IL is convex in price change. Large moves hurt disproportionately.

### When LPs Profit

**Condition for LP profitability:**
```
Fees earned > Impermanent loss + opportunity cost
```

**Factors favoring LPs:**
- High trading volume
- Low volatility
- Mean-reverting prices
- High fee tiers

**Factors hurting LPs:**
- Low volume, high volatility
- Trending prices
- Low fees
- Informed/toxic flow

## Concentrated Liquidity Games

### The Uniswap V3 Revolution

**Old model (V2):** Liquidity spread across all prices
**New model (V3):** LPs choose price ranges

### Game Theory Implications

**Benefits:**
- Higher capital efficiency
- Better prices for traders in-range
- More fee income per dollar deposited

**Costs:**
- Active management required
- Out-of-range = no fees + full price exposure
- Greater IL within range

### The Concentration Game

**Players:** Multiple LPs choosing ranges

**Strategies:** 
- Wide range: Less fees per unit, but always earning
- Narrow range: More fees per unit, but may go out of range

**Equilibrium:**
- Liquidity concentrates around current price
- Competition drives down LP returns
- Arms race in rebalancing speed

### JIT Liquidity Attack

**Mechanism:**
1. See large incoming trade in mempool
2. Add concentrated liquidity at execution price
3. Capture most of the fees
4. Remove liquidity immediately

**Game theory:**
- JIT LPs have information advantage
- Passive LPs get adversely selected
- Requires MEV infrastructure

**Equilibrium effect:** 
- Passive LP returns decrease
- Liquidity becomes more dynamic
- Concentration increases at cost of stability

## Liquidity Mining Games

### The Basic Game

Protocol offers token rewards for providing liquidity.

**Players:**
- Protocol (wants liquidity)
- LPs (want yield)
- Token holders (pay for rewards via dilution)

### Farm and Dump

**Strategy:**
1. Deposit when rewards start
2. Harvest rewards
3. Sell rewards immediately
4. Leave when rewards decrease

**Game theory:**
- Rational for short-term players
- Creates sell pressure on reward token
- Liquidity leaves when rewards stop

**Protocol response:**
- Lock-up periods
- Vesting rewards
- Reward loyal LPs more

### The Sybil Problem

**Airdrop farming:**
1. Create many wallets
2. Provide minimum liquidity across all
3. Claim airdrops/rewards on each

**Game theory:**
- Protocol can't distinguish real users from Sybils
- Legitimate users get diluted
- Arms race between protocols and farmers

### Vampire Attacks

**Mechanism:**
1. Fork existing protocol
2. Offer higher rewards to migrate liquidity
3. Drain competitor's liquidity

**Classic example:** SushiSwap vs. Uniswap

**Game theory:**
- Easy to fork contracts
- Moat is liquidity, which is mobile
- Rewards/brand/network effects matter

## LP Strategy Framework

### Step 1: Assess the Pool

**Questions:**
- What's the volume/TVL ratio?
- What's the fee tier?
- How volatile is the pair?
- Who's trading (noise or informed)?
- What's the reward APR (if any)?

**Red flags:**
- Low volume, high TVL (over-supplied)
- One asset has upcoming catalyst (IL risk)
- New pool (manipulation risk)
- Extreme reward APY (unsustainable)

### Step 2: Choose Range (if concentrated)

**Considerations:**
- Current price + expected range
- Volatility (implied from options, historical)
- Rebalancing costs and capacity
- Competition from other LPs

**Heuristics:**
- Stable pairs: Tight range (e.g., 0.99-1.01)
- Correlated pairs: Medium range (e.g., 0.8-1.25x)
- Volatile pairs: Wide range or avoid

### Step 3: Monitor and Adjust

**Triggers for adjustment:**
- Price approaching range boundary
- Significant volatility change
- Fee tier changes
- Reward rate changes

**Rebalancing costs:**
- Gas fees
- Potential IL crystallization
- Opportunity cost

### Step 4: Exit Strategy

**When to exit:**
- Achieved target return
- Fundamentals changed
- Better opportunities elsewhere
- Reward program ending

## Advanced LP Strategies

### Delta Hedging

**Concept:** Offset IL with derivatives position.

**Implementation:**
- LP position = short gamma
- Buy options to hedge
- Can convert LP to pure fee income

**Game theory:**
- Requires efficient options market
- Hedging cost vs. IL reduction
- Professional market-making approach

### LP Aggregators

**Concept:** Automated rebalancing across ranges.

**Examples:** Arrakis, Gamma, etc.

**Game theory:**
- Pooled capital = better efficiency
- Algorithmic management
- Principal-agent: Is manager aligned?

### Multi-Pool Strategies

**Concept:** Spread liquidity across pools/chains.

**Considerations:**
- Correlation between pools
- Gas/bridging costs
- Yield farming synergies

## Protocol Design for Liquidity

### Fee Structure

**Trade-off:**
- Higher fees = more LP income, worse prices for traders
- Lower fees = less LP income, better prices, more volume

**Typical tiers:**
- Stable: 0.01-0.05%
- Correlated: 0.05-0.30%
- Volatile: 0.30-1.00%

### LP Protection Mechanisms

**Fee switches:**
- Protocol can turn on fee share
- Changes LP economics post-launch

**MEV protection:**
- Private mempools for LPs
- Anti-JIT mechanisms

**Insurance:**
- IL insurance products
- Protocol-subsidized coverage

### Liquidity Bootstrapping

**Problems:**
- New pools need initial liquidity
- Chicken-and-egg: No volume without liquidity, no LPs without volume

**Solutions:**
- Protocol-owned liquidity
- Liquidity mining (temporary)
- Bonds (Olympus-style)
- Bribes for liquidity

## Equilibrium Analysis

### Long-Run LP Returns

In efficient markets:
```
Expected LP return ≈ Risk-free rate + Risk premium - Adverse selection cost

Where:
- Risk premium = compensation for IL volatility
- Adverse selection = losses to informed traders
```

**Empirical finding:** Many LP positions have negative risk-adjusted returns after accounting for IL.

### Why Do LPs Persist?

1. **Reward mining:** Token rewards exceed losses
2. **Misconception:** Don't understand IL
3. **Hedging:** LP position hedges existing exposure
4. **Platform play:** Provide liquidity to own protocol
5. **Learning:** Paying for market-making education

### Market Efficiency

As LP markets mature:
- IL becomes better understood
- Sophisticated LPs dominate
- Retail LP returns compress
- Protocol must pay more for liquidity


path: references/mechanism-design.md
content: # Mechanism Design

The art of designing games to achieve desired outcomes. "Reverse game theory."

> "If game theory asks 'what will happen?', mechanism design asks 'what rules create the outcome we want?'"

## The Mechanism Design Problem

Given:
- A set of possible outcomes
- Agents with private information (types)
- A social choice function (desired mapping from types to outcomes)

Design:
- A game (mechanism) where equilibrium play implements the social choice function

## Key Concepts

### Incentive Compatibility

A mechanism is incentive compatible if truthful revelation is optimal.

**Dominant Strategy Incentive Compatible (DSIC):**
Truth-telling is dominant regardless of others' strategies.

**Bayesian Incentive Compatible (BIC):**
Truth-telling is optimal given beliefs about others.

**DSIC is stronger:** Works even against colluding opponents.

**Crypto relevance:** Oracle mechanisms need DSIC - reporters shouldn't benefit from lying regardless of what others report.

### Individual Rationality

Participation must be voluntary and beneficial. Agents must prefer participating to not participating.

**Ex-ante IR:** Expected utility from participation is non-negative.
**Interim IR:** Utility is non-negative for each type.
**Ex-post IR:** Utility is non-negative for each outcome.

**Crypto relevance:** Staking mechanisms must offer IR - expected rewards must exceed opportunity cost.

### The Revelation Principle

For any mechanism with an equilibrium achieving outcome X, there exists a direct mechanism where:
1. Agents report their types directly
2. Truth-telling is an equilibrium
3. The same outcome X is achieved

**Implication:** When designing mechanisms, we can focus on direct, truth-telling mechanisms without loss of generality.

**Crypto caveat:** On-chain, "direct revelation" may leak information. Privacy concerns complicate this.

## Classic Mechanisms

### Vickrey-Clarke-Groves (VCG)

The canonical DSIC mechanism for efficient allocation.

**How it works:**
1. Agents report valuations
2. Mechanism chooses efficient allocation (maximizes total reported value)
3. Each agent pays the externality they impose on others

**Properties:**
- DSIC: Truth-telling is dominant
- Efficient: Maximizes total welfare
- Not budget-balanced: May run deficit or surplus

**Crypto applications:**
- MEV auctions (sort of)
- Resource allocation in blockchains
- Fair ordering mechanisms

**Limitations:**
- Vulnerable to collusion
- Requires quasi-linear utility
- Payments can be large

### Second-Price (Vickrey) Auction

Special case of VCG for single-item auctions.

**Rules:**
1. Sealed bids
2. Highest bidder wins
3. Pays second-highest bid

**Why DSIC:** 
- Bidding above value: Risk paying more than value
- Bidding below value: Risk losing when you'd profit
- Bidding exactly value: Dominant

**Crypto applications:**
- NFT auctions
- Block space allocation (in theory)
- Name registration

### First-Price Auction

Not DSIC, but commonly used.

**Rules:**
1. Sealed bids
2. Highest bidder wins
3. Pays own bid

**Equilibrium:** Bid below value, amount depends on competitors.

**Why used despite not being DSIC:**
- Revenue may be higher
- Simpler to explain
- No need to reveal second price

**Crypto applications:**
- Most actual NFT auctions
- Gas price auctions (essentially)

### English Auction (Ascending)

Open ascending price auction.

**Properties:**
- Strategically equivalent to second-price
- More transparent
- Creates excitement/engagement

**Crypto applications:**
- Some NFT platforms
- Slow but engaging for high-value items

### Dutch Auction (Descending)

Price starts high, decreases until someone buys.

**Properties:**
- Strategically equivalent to first-price
- Fast resolution
- Good for multiple identical items

**Crypto applications:**
- Fair launches (Paradigm's approach)
- Token sales
- Reduces gas wars

## Impossibility Results

### Myerson-Satterthwaite

For bilateral trade with private values, no mechanism is simultaneously:
- DSIC
- Individually rational
- Budget-balanced
- Efficient

**Crypto implication:** Perfect decentralized exchanges are impossible. Some efficiency loss is inevitable.

### Gibbard-Satterthwaite

Any voting mechanism that is:
- Defined for all preference profiles
- Produces a single winner
- Non-dictatorial

Must be manipulable (not strategy-proof).

**Crypto implication:** Perfect governance mechanisms don't exist. All voting systems can be gamed.

### Arrow's Impossibility

No social welfare function satisfies:
- Unrestricted domain
- Pareto efficiency
- Independence of irrelevant alternatives
- Non-dictatorship

**Crypto implication:** Aggregating community preferences is fundamentally hard.

## Mechanism Design in Crypto

### Oracle Mechanism Design

**Problem:** Get truthful off-chain data on-chain.

**Approaches:**

**Schelling Point Mechanisms:**
- Reporters coordinate on truth as focal point
- Penalties for deviation from consensus
- Example: Chainlink, UMA

**Skin in the Game:**
- Stake tokens, lose stake for wrong reports
- Requires defining "wrong"
- Example: Augur, Kleros

**Commit-Reveal:**
- Commit hash of answer, then reveal
- Prevents copying
- Adds delay

**Design considerations:**
- Cost of corruption must exceed value of manipulation
- Attacker may be the one asking the question
- Recursive incentive problems

### MEV Mechanism Design

**Problem:** Transaction ordering creates extractable value.

**Approaches:**

**Fair Ordering:**
- First-come-first-served (hard on decentralized networks)
- Random ordering (adds latency)
- Threshold encryption (complex)

**MEV Auctions:**
- Flashbots-style: Bundle auctions
- PBS (Proposer-Builder Separation)
- MEV smoothing across validators

**MEV Sharing:**
- Return MEV to users (MEV Blocker)
- Protocol-captured MEV (Osmosis)

**The fundamental tradeoff:** Fairness vs. efficiency vs. complexity.

### Governance Mechanism Design

**Problem:** Make collective decisions without capture.

**Approaches:**

**Token Voting:**
- Simple but plutocratic
- Vulnerable to flash loans
- Rational apathy problem

**Quadratic Voting:**
- Vote weight = sqrt(tokens)
- Reduces plutocracy
- Sybil vulnerable

**Conviction Voting:**
- Votes accumulate over time
- Rewards long-term holders
- Complex dynamics

**Futarchy:**
- Vote on values, bet on beliefs
- Prediction markets for policy
- Experimental

**Optimistic Governance:**
- Proposals pass unless challenged
- Reduces voter burden
- Requires monitoring

### Tokenomics as Mechanism Design

**Goal:** Align incentives of all stakeholders.

**Emission schedules:**
- Front-loaded: Bootstrapping, but sell pressure
- Back-loaded: Sustainable, but slow adoption
- Algorithmic: Responsive, but complex

**Staking mechanics:**
- Lock-up periods: Align time horizons
- Slashing: Penalize misbehavior
- Delegation: Enable participation

**Fee distribution:**
- To token holders: Aligns with growth
- To LPs: Sustains liquidity
- Burned: Deflationary pressure

## Advanced Topics

### Collusion Resistance

VCG and many mechanisms fail against collusion.

**Approaches:**
- Cryptographic methods (commit-reveal, ZK)
- Costly collusion (require side payments)
- Detection and punishment
- Limiting coalitional gains

### Sybil Resistance

One person, multiple identities breaks many mechanisms.

**Approaches:**
- Proof of personhood (Worldcoin, Gitcoin Passport)
- Stake-weighted (plutocratic but Sybil-resistant)
- Social graph analysis
- Costly identity creation

### Dynamic Mechanism Design

Mechanisms that work over time.

**Challenges:**
- Commitment problems
- Renegotiation
- Learning and adaptation
- Reputation effects

### Computational Mechanism Design

Mechanisms must be computationally feasible.

**Constraints:**
- On-chain computation is expensive
- Complex mechanisms may not be implementable
- Gas costs affect participation
- Verification must be cheap

## Design Checklist

When designing a mechanism:

1. **Define the goal precisely**
   - What outcome do you want?
   - Whose welfare matters?

2. **Identify private information**
   - What do agents know that you don't?
   - What can they lie about?

3. **Check incentive compatibility**
   - Is truth-telling optimal?
   - What are the gains from lying?

4. **Verify individual rationality**
   - Will agents participate?
   - Is the outside option properly modeled?

5. **Consider collusion**
   - Can agents coordinate to game the mechanism?
   - What coalitions are realistic?

6. **Assess Sybil vulnerability**
   - Can creating multiple identities help?
   - How is identity established?

7. **Evaluate computational feasibility**
   - Can this run on-chain?
   - What's the gas cost?

8. **Test with adversarial thinking**
   - How would you exploit this mechanism?
   - What's the worst-case outcome?


path: references/mev-strategies.md
content: # MEV Game Theory

Maximal Extractable Value: the game of transaction ordering.

> "In the beginning there was the mempool. And the mempool was dark and full of terrors."

## What is MEV?

Value that can be extracted by reordering, inserting, or censoring transactions within a block.

**Players:**
- Users (transaction senders)
- Searchers (MEV extractors)
- Builders (block constructors)
- Proposers/Validators (block producers)

**The fundamental insight:** On a blockchain, order matters. Whoever controls order controls value.

## MEV Taxonomy

### Arbitrage

Exploiting price differences across venues.

**Example:**
1. Token X is $100 on Uniswap, $102 on Sushiswap
2. Searcher buys on Uniswap, sells on Sushiswap
3. Profit: $2 minus gas

**Game theory:**
- Competition drives profits toward zero
- Winner is fastest/most gas-efficient
- Validators extract via priority fees
- Generally considered "benign" MEV

**Equilibrium:** Arbitrage profits = cost of extraction (gas + priority fees)

### Sandwich Attacks

Front-running and back-running a victim's trade.

**Mechanism:**
1. Victim submits large swap (buy token X)
2. Attacker front-runs: buys X, raising price
3. Victim's trade executes at worse price
4. Attacker back-runs: sells X at inflated price

**Game theory:**
- Attacker profits from victim's price impact
- Victim always loses (gets worse execution)
- Arms race in speed and gas bidding
- Clearly extractive/harmful

**Victim's defenses:**
- Lower slippage tolerance (may fail to execute)
- Private mempools (Flashbots Protect, MEV Blocker)
- DEX aggregators with MEV protection
- Smaller trades
- Limit orders instead of market orders

### Liquidations

Racing to liquidate undercollateralized positions.

**Mechanism:**
1. Position becomes liquidatable
2. Multiple searchers race to call liquidate()
3. Winner receives liquidation bonus

**Game theory:**
- Pure speed competition
- Priority gas auctions (PGAs)
- Often benefits protocol (faster liquidations = more stability)
- Can cascade in volatile markets

**Design considerations:**
- Higher bonuses = faster liquidation but more MEV
- Dutch auction liquidations reduce racing
- Keeper networks coordinate to reduce waste

### JIT (Just-In-Time) Liquidity

Providing liquidity only for specific trades.

**Mechanism:**
1. Large swap detected in mempool
2. LP adds concentrated liquidity at execution price
3. Captures fees from the swap
4. Removes liquidity immediately after

**Game theory:**
- Competes with passive LPs
- Requires precise timing
- Only profitable for large swaps
- Controversial: efficient or extractive?

### NFT Sniping

Front-running NFT purchases.

**Mechanism:**
1. Valuable NFT listed below floor
2. Multiple bots race to purchase
3. Winner gets underpriced NFT

**Game theory:**
- Similar to arbitrage
- Speed + gas optimization
- Marketplaces try to prevent (rate limits, private listings)

### Long-Tail MEV

Protocol-specific extraction opportunities.

**Examples:**
- Governance proposal sniping
- Airdrop claim racing
- Oracle update front-running
- Cross-chain arbitrage

## The MEV Supply Chain

### Pre-PBS (Proposer-Builder Separation)

```
Users -> Mempool -> Searchers -> Miners/Validators
```

- Validators had all the power
- Could extract directly or accept bribes
- Limited competition

### Post-PBS

```
Users -> Mempool -> Searchers -> Builders -> Relays -> Proposers
```

**Searchers:**
- Find MEV opportunities
- Create transaction bundles
- Compete by bidding to builders

**Builders:**
- Aggregate bundles into blocks
- Optimize for total extractable value
- Bid to proposers for block space

**Relays:**
- Trusted intermediaries
- Prevent builder-proposer collusion
- Verify block validity before revealing

**Proposers:**
- Select highest-bidding valid block
- Don't need to understand MEV
- Commoditized role

### Game Theoretic Analysis

**Searcher competition:**
- Drives profits toward zero
- Specialization emerges (arb vs. liquidation vs. sandwich)
- Information asymmetry creates edge

**Builder competition:**
- Network effects (more searchers -> better blocks -> more proposers)
- Centralization pressure (few dominant builders)
- Censorship concerns (builders can exclude)

**Proposer-builder relationship:**
- Proposers want maximum bids
- Builders want maximum margin
- Relays mediate trust

## MEV Mitigation Strategies

### For Users

**Private transaction submission:**
- Flashbots Protect
- MEV Blocker
- BloxRoute
- Direct to builder

**Slippage management:**
- Tight slippage (may fail)
- Wide slippage (vulnerable)
- Optimal: estimate price impact + buffer

**Trade splitting:**
- Multiple smaller trades
- Reduces individual price impact
- Higher total gas cost

**Limit orders:**
- No slippage vulnerability
- May not execute
- Requires on-chain order book or keeper network

### For Protocols

**Fair ordering:**
- First-come-first-served (hard to implement fairly)
- Commit-reveal (adds latency)
- Threshold encryption (complex)
- Verifiable delay functions

**Batch auctions:**
- Collect orders over time
- Execute at single clearing price
- Eliminates front-running within batch
- Example: CoW Protocol

**MEV sharing:**
- Return extracted MEV to users/LPs
- Requires measuring MEV (hard)
- Example: MEV-Share, OEV

**Application-specific solutions:**
- Oracle Extractable Value (OEV) auctions
- AMM designs that minimize MEV
- Intent-based trading

### For the Network

**Encrypted mempools:**
- Transactions encrypted until ordering committed
- Eliminates information advantage
- Complexity and latency costs
- Example: Shutter Network

**MEV burn:**
- Redirect MEV to protocol/burn
- Reduces incentive for extraction
- Implementation challenges

**Decentralized builders:**
- Reduce centralization risk
- Maintain censorship resistance
- Active research area

## Game Theory Models

### Priority Gas Auction (PGA)

**Model:**
- N searchers competing for one opportunity
- Opportunity worth V
- Searchers bid gas prices
- Highest bid wins, pays their bid

**Equilibrium:**
- All-pay auction dynamics
- Winner's curse
- Profits driven to near zero
- Losers waste gas

**Inefficiency:**
- Failed transactions consume resources
- Network congestion
- Value flows to validators, not users

### Builder Game

**Model:**
- Builders receive bundles from searchers
- Build blocks to maximize total value
- Bid to proposers for inclusion

**Equilibrium:**
- Competitive builders bid away profits
- Marginal builder earns zero
- Inframarginal builders earn rents (efficiency advantages)

**Centralization pressure:**
- More volume -> better optimization -> more volume
- Natural monopoly tendencies
- Mitigated by credible neutrality requirements

### Multi-Block MEV

**Model:**
- Proposers control multiple consecutive blocks
- More ordering flexibility = more MEV
- Creates incentive to acquire multiple slots

**Equilibrium:**
- Validators may buy/bribe for consecutive slots
- Concentrated validator power
- "Time bandit" attacks possible

**Mitigations:**
- Single slot finality
- Proposer diversity requirements
- MEV smoothing

## Empirical Patterns

### MEV by Type (Ethereum)

Approximate breakdown (varies over time):
- Arbitrage: ~60%
- Sandwich: ~20%
- Liquidations: ~15%
- Other: ~5%

### MEV Trends

1. **Growing absolute value** - More DeFi activity = more MEV
2. **Compressing margins** - Competition drives down per-unit profit
3. **Increasing sophistication** - Cross-domain, cross-chain, multi-block
4. **Infrastructure maturation** - PBS, MEV-Share, OEV auctions

### Who Captures MEV?

Pre-PBS: Mostly miners/validators
Post-PBS: 
- ~90% to proposers (via builder bids)
- ~10% to builders (margin)
- Searchers earn on information edge

## Strategic Implications

### For Protocol Designers

1. **Assume adversarial ordering** - Don't rely on tx order
2. **Minimize information leakage** - Encrypted inputs where possible
3. **Design for MEV-awareness** - Build in protections or capture
4. **Consider batch mechanisms** - Eliminate within-batch MEV

### For Users

1. **Use MEV protection** - Private mempools are free
2. **Understand your exposure** - Large trades are targets
3. **Consider timing** - Low-activity periods have less MEV competition
4. **Check execution quality** - Compare to CEX prices

### For Searchers/Builders

1. **Specialize** - Find unique edges
2. **Invest in infrastructure** - Speed and efficiency matter
3. **Consider reputation** - Long-term relationships > short-term extraction
4. **Watch for regime changes** - PBS, encrypted mempools, new chains

## The Philosophical Question

Is MEV good or bad?

**Arguments it's good:**
- Arbitrage improves price efficiency
- Liquidations maintain protocol health
- Competition drives innovation

**Arguments it's bad:**
- Sandwich attacks are pure extraction
- Centralizes infrastructure
- Degrades user experience
- Invisible tax on users

**The nuanced view:**
- Some MEV is alignment (arbitrage, liquidation)
- Some MEV is extraction (sandwich)
- Goal: Minimize extractive MEV, accept aligned MEV
- Better mechanisms can shift the balance


path: references/nash-equilibrium.md
content: # Nash Equilibrium

A strategy profile where no player can improve their payoff by unilaterally changing their strategy.

## Formal Definition

A Nash equilibrium is a set of strategies (s1*, s2*, ..., sn*) such that for each player i:

```
ui(si*, s-i*) >= ui(si, s-i*) for all si in Si
```

Where:
- ui is player i's payoff function
- si* is player i's equilibrium strategy
- s-i* is the equilibrium strategies of all other players
- Si is player i's strategy set

## Types of Nash Equilibrium

### Pure Strategy Nash Equilibrium
Each player chooses a single deterministic action.

**Example:** In a coordination game where both players benefit from choosing the same option, both choosing A or both choosing B are pure strategy equilibria.

### Mixed Strategy Nash Equilibrium
Players randomize over actions with specific probabilities.

**Example:** In matching pennies, each player randomizes 50/50 between heads and tails.

**Crypto relevance:** MEV searchers often use mixed strategies to avoid predictability.

### Symmetric Nash Equilibrium
All players use the same strategy.

**Crypto relevance:** In many DeFi games, symmetric equilibria are focal points.

## Finding Nash Equilibria

### Method 1: Best Response Analysis

1. For each player, find best response to every possible opponent strategy
2. Nash equilibrium exists where best responses intersect

**Example (2x2 game):**
```
                Player 2
              L       R
Player 1  U  (3,3)   (0,5)
          D  (5,0)   (1,1)
```

- If P2 plays L: P1's best response is D (5 > 3)
- If P2 plays R: P1's best response is D (1 > 0)
- If P1 plays U: P2's best response is R (5 > 3)
- If P1 plays D: P2's best response is L (0 > 1)

Nash equilibrium: (D, L) with payoffs (5, 0)? No - P2 would deviate.
Need to check: at (D,L), P2 gets 0, could get 1 at (D,R). Deviates.
At (D,R), P1 gets 1, could get 5 at (D,L). Check P2: gets 1, could get 0 at (D,L). No deviation.
(D,R) is Nash equilibrium with payoffs (1,1).

### Method 2: Iterated Elimination of Dominated Strategies

Remove strategies that are never best responses, iterate until stable.

### Method 3: Support Enumeration (for mixed equilibria)

For each possible support (set of strategies played with positive probability), solve for probabilities that make opponent indifferent.

## Properties

### Existence
Every finite game has at least one Nash equilibrium (possibly mixed).

### Uniqueness
Not guaranteed. Many games have multiple equilibria.

### Efficiency
Nash equilibria may not be Pareto efficient (see: Prisoner's Dilemma).

### Stability
Players have no incentive to deviate unilaterally, but:
- Coalition deviations may be profitable
- Trembling (small mistakes) may destabilize

## Refinements

### Subgame Perfect Equilibrium
Nash equilibrium in every subgame. Rules out non-credible threats.

**Crypto relevance:** Evaluating whether protocol threats (slashing) are credible.

### Trembling Hand Perfect Equilibrium
Equilibrium survives if players make small mistakes with tiny probability.

**Crypto relevance:** Robust mechanism design that works despite user errors.

### Sequential Equilibrium
For games with imperfect information. Combines strategies and beliefs.

**Crypto relevance:** Trading games where participants have private information.

## Crypto Applications

### Validator Economics

**Game:** Validators choose how much to stake.

**Players:** n validators
**Strategies:** Stake amount si >= 0
**Payoffs:** Rewards proportional to stake share, minus opportunity cost

**Equilibrium:** Staking continues until marginal reward equals opportunity cost for all validators.

**Analysis questions:**
- Is the security budget sufficient?
- Can cartels form to extract more value?
- What happens if a large player exits?

### AMM Liquidity Provision

**Game:** LPs choose where to provide liquidity.

**Players:** Liquidity providers
**Strategies:** Amount and price range for liquidity
**Payoffs:** Fees earned minus impermanent loss

**Equilibrium:** Liquidity distributed such that marginal return equals across positions.

**Insight:** Concentrated liquidity shifts equilibrium toward more competition at active prices.

### Gas Price Bidding

**Game:** Users compete for block inclusion.

**Players:** Transaction senders
**Strategies:** Gas price bid
**Payoffs:** Value of inclusion minus gas cost

**Equilibrium:** Bids rise until marginal bidder is indifferent between inclusion and waiting.

**Pathology:** During congestion, equilibrium can involve extreme overbidding.

### Governance Voting

**Game:** Token holders vote on proposals.

**Players:** Token holders with varying stakes
**Strategies:** Vote yes, no, or abstain
**Payoffs:** Depend on proposal outcome and voting costs

**Equilibrium:** Often rational apathy - small holders don't vote because impact is negligible.

**Attack:** Voter apathy allows concentrated interests to capture governance.

## Limitations

### Rationality Assumption
Nash equilibrium assumes perfect rationality. Real actors:
- Have bounded rationality
- Make mistakes
- Have incomplete information about payoffs

### Equilibrium Selection
With multiple equilibria, theory doesn't predict which will occur.

### Computational Complexity
Finding Nash equilibria is PPAD-complete (computationally hard).

### Dynamic Considerations
Static Nash analysis misses:
- Learning dynamics
- Reputation effects
- Time preferences

## Best Practices for Analysis

1. **Start simple:** Model the core interaction first, add complexity later.

2. **Identify all players:** Including passive ones (e.g., retail in MEV games).

3. **Be precise about payoffs:** Vague payoffs lead to vague conclusions.

4. **Check for multiple equilibria:** Don't assume uniqueness.

5. **Stress test equilibrium:** What breaks it? Collusion? New entrants? Parameter changes?

6. **Consider dynamics:** Is the equilibrium reachable? Stable to perturbations?


path: references/tokenomics-analysis.md
content: # Tokenomics Analysis

Game-theoretic evaluation of token economic systems.

## The Tokenomics Game

Every token creates a game between:
- **Protocol** (wants growth, sustainability, decentralization)
- **Team** (wants compensation, control, success)
- **Investors** (want returns)
- **Users** (want utility, fair prices)
- **Speculators** (want volatility, momentum)

The tokenomics design determines how these interests align or conflict.

## Analysis Framework

### Supply Dynamics

**Questions to ask:**
1. What is the total supply? Fixed or variable?
2. What is the emission schedule?
3. What are the sink mechanisms (burns, locks)?
4. What is the terminal state?

**Red flags:**
- Unlimited inflation with no sinks
- Team can mint arbitrary amounts
- No clear path to sustainability

**Game theory:**
- Inflationary tokens: Constant selling pressure from recipients
- Deflationary tokens: Incentive to hold, may reduce liquidity
- Elastic supply: Complex dynamics, often unstable

### Distribution

**Questions to ask:**
1. Who received tokens at genesis?
2. What are the vesting schedules?
3. How concentrated is ownership?
4. Can insiders sell before others?

**Red flags:**
- >50% to team/investors
- Team fully liquid before users
- Hidden allocations
- Asymmetric vesting (insiders unlock faster)

**Game theory:**
- Early token concentration = principal-agent problem
- Long vesting aligns incentives but reduces team flexibility
- Airdrop gaming is a repeated game (Sybils learn)

### Utility and Value Accrual

**Questions to ask:**
1. What can you do with the token?
2. How does protocol revenue flow to token?
3. Is demand structural or speculative?
4. What's the relationship between usage and token value?

**Token utility types:**

| Type | Mechanism | Value Accrual |
|------|-----------|---------------|
| Governance | Voting rights | Indirect (protocol value) |
| Fee discount | Reduced costs when holding | Direct but limited |
| Staking yield | Earn more tokens | Circular (often inflationary) |
| Fee sharing | Portion of revenue | Direct |
| Buyback/burn | Protocol buys and burns | Deflationary pressure |
| Collateral | Required to participate | Direct demand |
| Access | Required for features | Direct demand |

**Game theory:**
- Pure governance tokens have weak value accrual
- Fee sharing aligns holders with protocol growth
- Inflationary staking yields are zero-sum redistribution

### Staking Mechanics

**Questions to ask:**
1. What's the staking APY? Source of yield?
2. What are lock-up periods?
3. What are slashing conditions?
4. Is there delegation?

**Analysis points:**

**APY sustainability:**
```
If APY comes from inflation: Zero-sum redistribution
If APY comes from fees: Sustainable if fees > costs
If APY comes from new users: Ponzi dynamics
```

**Lock-up game theory:**
- Longer locks = more aligned holders
- But also more illiquidity risk
- Optimal: Graduated unlocks with incentives

**Slashing design:**
- Too harsh: Discourages participation
- Too lenient: Doesn't deter misbehavior
- Needs: Clear conditions, fair implementation

### Incentive Alignment

**Check alignment between:**

| Stakeholder | Wants | Potential Misalignment |
|-------------|-------|------------------------|
| Users | Low fees, good UX | May conflict with token value |
| Holders | Price appreciation | May want monopoly pricing |
| Team | Compensation, control | May extract value |
| LPs | Fee income | May impermanent loss |
| Validators | Rewards | May censor, extract MEV |

**Aligned tokenomics:**
- Team vesting tied to metrics
- Fee sharing proportional to contribution  
- Governance power distributed
- Clear path to decentralization

## Common Patterns

### Pattern 1: Inflationary Staking

**Design:** Stake tokens, earn more tokens from inflation.

**Game theory:**
- Non-stakers diluted
- Creates pressure to stake
- Real yield = 0 if everyone stakes
- Actually a tax on non-stakers

**When it works:**
- Bootstrapping phase
- Combined with fee sharing
- Clear end to inflation

**When it fails:**
- Perpetual high inflation
- Whales accumulate, retail diluted
- No utility beyond staking

### Pattern 2: Revenue Sharing

**Design:** Protocol revenue distributed to token holders/stakers.

**Game theory:**
- Aligns holders with protocol growth
- Creates fundamental value floor
- Dividend discount model applies

**When it works:**
- Protocol has real revenue
- Distribution is fair (not captured by insiders)
- Revenue growing

**When it fails:**
- Revenue is minimal
- Complex distribution favoring insiders
- Revenue not sustainable

### Pattern 3: Buyback and Burn

**Design:** Protocol uses revenue to buy and burn tokens.

**Game theory:**
- Reduces supply = increases price (all else equal)
- Benefits all holders proportionally
- Avoids taxable distribution

**When it works:**
- Consistent revenue
- Transparent execution
- Not front-runnable

**When it fails:**
- Sporadic or manipulated buybacks
- Insiders sell into buybacks
- Price impact negligible relative to supply

### Pattern 4: Vote Escrow (ve)

**Design:** Lock tokens for voting power and rewards. Longer lock = more power.

**Game theory:**
- Rewards long-term holders
- Reduces liquid supply (price support)
- Creates bribing market (Votium, Hidden Hand)

**When it works:**
- Meaningful governance decisions
- Bribe income attractive
- Lock periods reasonable

**When it fails:**
- Governance captured anyway
- Bribes extracted by whales
- Lock too long, becomes illiquid

### Pattern 5: Dual Token

**Design:** Separate governance/staking token from utility/gas token.

**Game theory:**
- Can optimize each for purpose
- Complexity for users
- Value accrual may be unclear

**When it works:**
- Clear utility for each token
- Fair distribution of both
- Value flows between them logically

**When it fails:**
- One token becomes worthless
- Arbitrage between tokens complex
- Users confused

## Quantitative Analysis

### Token Value Model

Simplified discounted cash flow:

```
Value = Sum of (Future Revenue to Token / (1 + r)^t)
```

Where r = discount rate reflecting risk.

**For fee-sharing tokens:**
```
P/E Ratio = Price / (Annual Fees to Token)
Compare to similar protocols
```

**For governance tokens:**
```
Value = Expected value of governance control
      + Expected value of future utility
      + Speculation premium
```

### Emission Analysis

**Calculate:**
```
Current circulating supply: C
Total supply: T
Annual emission: E
Fully diluted valuation: FDV = Price * T
Market cap: MC = Price * C

Key ratios:
- MC/FDV = C/T (how much is unlocked)
- Inflation rate = E/C (annual dilution)
```

**Warning signs:**
- MC/FDV < 0.3 (most supply locked, will unlock)
- Inflation > 20% (heavy dilution)
- Emission to insiders > emission to users

### Holder Analysis

**On-chain metrics:**
```
- Gini coefficient of holdings (concentration)
- % held by top 10/100 addresses
- Exchange inflows/outflows
- Staking ratio (locked vs liquid)
```

**Game theory interpretation:**
- High concentration = whale manipulation risk
- Exchange inflows = selling pressure incoming
- Low staking = weak holder conviction

## Case Study Template

```markdown
## [Protocol Name] Tokenomics Analysis

### Overview
- [REDACTED_SECRET]
- Current Price: $X
- Market Cap: $Y
- FDV: $Z

### Supply Analysis
- Total supply: X
- Circulating: Y (Z%)
- Emission schedule: [description]
- Sinks: [burns, locks, etc.]

### Distribution
| Allocation | % | Vesting |
|------------|---|---------|
| Team | X% | Y months |
| Investors | X% | Y months |
| Community | X% | [details] |

### Utility Analysis
- Primary use: [governance/staking/fee/etc.]
- Value accrual: [mechanism]
- Demand drivers: [what creates demand]

### Game Theory Assessment
- Incentive alignment: [Strong/Moderate/Weak]
- Key tensions: [list conflicts]
- Attack vectors: [governance capture, dilution, etc.]

### Verdict
[Sustainable/Concerning/Ponzi]
[Key recommendations]
```

## Red Flag Checklist

| Red Flag | Why It's Bad |
|----------|--------------|
| Anonymous team with unlocked tokens | Can rug |
| Emissions >> Revenue | Unsustainable |
| Team can mint unlimited | Inflation risk |
| Governance can change tokenomics | Rug via governance |
| No vesting for insiders | Dump risk |
| Utility is only "governance" | Weak value accrual |
| Staking yield > 100% APY | Ponzi math |
| FDV >> MC (>5x) | Massive unlocks coming |
| Complex tokenomics | Hiding something |
| Rewards for recruiting | Ponzi structure |


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)