From 5ac3f943d931062cb1757834b07b5a2b14f1854d Mon Sep 17 00:00:00 2001 From: Ridwannurudeen Date: Mon, 2 Feb 2026 00:44:34 +0100 Subject: [PATCH] Add blockchain reasoning task categories: smart contracts, consensus, tokenomics --- tasks.md | 3 + tasks/consensus-mechanism-analysis.md | 234 ++++++++++++ tasks/smart-contract-logic-reasoning.md | 227 ++++++++++++ ...kenomics-and-incentive-design-reasoning.md | 344 ++++++++++++++++++ 4 files changed, 808 insertions(+) create mode 100644 tasks/consensus-mechanism-analysis.md create mode 100644 tasks/smart-contract-logic-reasoning.md create mode 100644 tasks/tokenomics-and-incentive-design-reasoning.md diff --git a/tasks.md b/tasks.md index 2e9b141..535edc9 100644 --- a/tasks.md +++ b/tasks.md @@ -14,6 +14,7 @@ | [Categorizing Information Into Hierarchies](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/categorizing-information-into-hierarchies.md) | Organizing information into hierarchical structures based on relationships or logical criteria. | | [Causal Chain Analysis](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/causal-chain-analysis.md) | Identifying and analyzing a sequence of events or factors that lead to a specific outcome. | | [Completing Analogies](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/completing-analogies.md) | Completing analogies to evaluate the ability to recognize relationships between pairs of words and apply them to new contexts. | +| [Consensus Mechanism Analysis](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/consensus-mechanism-analysis.md) | Comparing, evaluating, and reasoning about distributed consensus mechanisms, analyzing tradeoffs between security, decentralization, and scalability, and assessing game-theoretic incentive structures in blockchain systems. | | [Constructing Valid Arguments](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/constructing-valid-arguments.md) | Creating logically sound arguments to support a given conclusion or claim. | | [Counterfactual Analysis](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/counterfactual-analysis.md) | Examining hypothetical scenarios that are contrary to what actually happened. | | [Critical Factor Identification in Theory of Mind](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/critical-factor-identification-in-theory-of-mind.md) | Understanding that similar agents may act differently, or different agents may act similarly, based on a third factor. | @@ -82,11 +83,13 @@ | [Risk Assessment In Decision Making](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/risk-assessment-in-decision-making.md) | Evaluating potential risks and benefits associated with different courses of action in a given scenario. | | [Second Order False Belief](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/second-order-false-belief.md) | Understanding that an agent may hold a false belief about another agent's belief, leading to misinterpretations of actions or intentions. | | [Sequencing Events](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/sequencing-events.md) | Arranging a set of events in chronological order. | +| [Smart Contract Logic Reasoning](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/smart-contract-logic-reasoning.md) | Analyzing smart contract code, rules, or specifications to predict execution outcomes, identify potential vulnerabilities, and reason about state transitions in deterministic, blockchain-based systems. | | [Solving Riddles And Word Puzzles](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/solving-riddles-and-word-puzzles.md) | Deciphering and solving various types of riddles and word puzzles. | | [Solving Word Problems With Multiple Variables](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/solving-word-problems-with-multiple-variables.md) | Translating word problems into mathematical equations and solving them. | | [Spatial Problem Solving](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/spatial-problem-solving.md) | Using spatial reasoning to solve practical problems or puzzles. | | [Stack Based Reasoning] (https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/stack-based-reasoning) Using stacks and reverse thinking to convert chain of thought into stacks of instructions for others to follow| | [Syllogism Reasoning](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/syllogism-reasoning.md) | Providing a series of syllogisms to evaluate logical reasoning capabilities. | +| [Tokenomics and Incentive Design Reasoning](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/tokenomics-and-incentive-design-reasoning.md) | Analyzing economic models, reward mechanisms, and incentive structures in token-based systems, including supply/demand dynamics, attack vectors, and long-term sustainability of decentralized economic models. | | [Trait Attribution In Behavioral Scenarios](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/trait-attribution-in-behavioral-scenarios.md) | Analyzing described behaviors or actions and inferring personality traits or characteristics that might explain those behaviors. | | [Trend Analysis And Forecasting](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/trend-analysis-and-forecasting.md) | Examining historical data or patterns to identify trends and make predictions about future outcomes. | | [Truth Table Completion](https://github.com/NousResearch/Open-Reasoning-Tasks/blob/main/tasks/truth-table-completion.md) | Completing truth tables for given logical expressions to evaluate the understanding of Boolean logic and ability to determine the truth value of complex statements. | diff --git a/tasks/consensus-mechanism-analysis.md b/tasks/consensus-mechanism-analysis.md new file mode 100644 index 0000000..dd543d8 --- /dev/null +++ b/tasks/consensus-mechanism-analysis.md @@ -0,0 +1,234 @@ +# Consensus Mechanism Analysis + +## Description: +This task involves comparing, evaluating, and reasoning about distributed consensus mechanisms used in blockchain systems and other decentralized networks. It evaluates the model's ability to analyze tradeoffs between security, decentralization, and scalability, reason about Byzantine fault tolerance, identify attack vectors, and assess game-theoretic incentive structures that keep distributed systems honest. + +## Modality: +Text only + +## Examples: + +### Example 1: + +Input: + +``` +A new blockchain project claims their consensus mechanism achieves all three properties simultaneously: +1. Full decentralization (thousands of equal validators) +2. Instant finality (transactions confirmed in under 1 second) +3. Strong security (tolerates up to 49% malicious validators) + +Analyze whether this claim is feasible given known theoretical constraints. +``` + +Output: + +``` +This claim faces fundamental theoretical limitations: + +1. The CAP Theorem and blockchain trilemma: + - Decentralization + Security + Scalability cannot all be maximized simultaneously + - "Instant finality" with thousands of validators creates a communication bottleneck + +2. Communication overhead analysis: + - BFT-style consensus (needed for instant finality) requires O(n²) message complexity + - With thousands of validators, this means millions of messages per consensus round + - At 1,000 validators: ~1,000,000 messages per block + - Network latency alone makes sub-second finality impractical at this scale + +3. The 49% fault tolerance claim: + - Classical BFT protocols (PBFT) tolerate up to 33% Byzantine faults, not 49% + - Achieving 49% tolerance typically requires additional assumptions (like synchronous networks) + - Nakamoto consensus tolerates 49% but sacrifices instant finality (probabilistic instead) + +4. Known tradeoffs in real systems: + - Tendermint: Instant finality + 33% BFT, but limits validators (~150-200) + - Ethereum PoS: Large validator set + security, but finality takes ~15 minutes + - Solana: Fast finality + many validators, but requires high-performance hardware (reduces true decentralization) + +Conclusion: The claim is almost certainly infeasible. The project likely makes hidden compromises—either the validators aren't truly equal (delegated/weighted), finality has probabilistic caveats, or the security threshold is lower than stated. Any two of the three properties can be achieved, but all three simultaneously contradicts known distributed systems theory. +``` + +--- + +### Example 2: + +Input: + +``` +Consider two blockchain networks: + +Network A: Proof of Work +- Block time: 10 minutes +- 10,000 miners worldwide +- Top 3 mining pools control 51% of hashrate +- Energy consumption: 100 TWh/year + +Network B: Delegated Proof of Stake +- Block time: 2 seconds +- 21 elected block producers +- Token holders vote for producers +- Energy consumption: 0.01 TWh/year + +Which network is more decentralized? Consider multiple dimensions of decentralization. +``` + +Output: + +``` +Decentralization is multi-dimensional, and these networks make different tradeoffs: + +Dimension 1 - Validator/Miner Distribution: + - Network A: 10,000 miners, but 3 pools control majority → high nominal count, concentrated actual power + - Network B: Only 21 producers → low count, but each is explicitly elected + - Edge: Network A has more participants, but effective decentralization is similar due to pool concentration + +Dimension 2 - Barrier to Entry: + - Network A: Requires expensive, specialized hardware (ASICs) + cheap electricity → high capital barrier + - Network B: Requires community votes, not capital investment in hardware → political barrier instead + - Edge: Different barrier types. Network A excludes the poor, Network B excludes the unpopular + +Dimension 3 - Censorship Resistance: + - Network A: A censored transaction can be included by any of the ~10,000 miners eventually + - Network B: If a majority of the 21 producers collude, they can censor indefinitely + - Edge: Network A. More independent block producers means more paths to inclusion + +Dimension 4 - Governance: + - Network A: Changes require social consensus among miners, developers, and users (hard forks are contentious) + - Network B: 21 producers can coordinate changes quickly, but voters can replace them + - Edge: Network A has slower but more distributed governance + +Dimension 5 - Geographic Distribution: + - Network A: Mining concentrates where electricity is cheapest (often one or two countries) + - Network B: Producers can operate from anywhere (low energy needs) + - Edge: Network B potentially more geographically distributed + +Overall assessment: Network A is more decentralized in censorship resistance and governance, while Network B offers better geographic distribution and lower barriers to participation. Neither is definitively "more decentralized"—the answer depends on which dimensions you prioritize for your use case. +``` + +--- + +### Example 3: + +Input: + +``` +In a Proof of Stake system, validators must lock (stake) 32 ETH to participate. The protocol randomly selects validators to propose blocks and assigns committees to attest. Validators earn rewards for correct behavior and lose stake (get "slashed") for misbehavior. + +A wealthy attacker acquires 34% of all staked ETH. What attacks become possible, what remains impossible, and what economic consequences does the attacker face? +``` + +Output: + +``` +With 34% of stake, the attacker crosses the critical 33% threshold for BFT systems: + +POSSIBLE ATTACKS: + +1. Liveness attack (halting finality): + - Ethereum's Casper FFG requires 2/3 (66.7%) of validators to agree for finality + - The attacker can withhold attestations, preventing the 66.7% threshold + - Result: The chain continues producing blocks, but no epoch reaches finality + - Impact: Transactions process but lack the strong guarantee of irreversibility + +2. Censorship by committee: + - The attacker has ~34% chance of dominating any given attestation committee + - Can selectively refuse to attest to blocks containing specific transactions + - Effectiveness: Partial. Transactions may be delayed but will likely be included eventually when honest validators dominate the committee + +IMPOSSIBLE ATTACKS (even with 34%): + +1. Double spending / finality reversion: + - Requires controlling 2/3+ of stake (66.7%) + - With 34%, the attacker cannot create conflicting finalized checkpoints + +2. Creating invalid blocks: + - Other validators independently verify block validity + - Invalid blocks are rejected regardless of the proposer's stake + +3. Stealing other validators' funds: + - Protocol rules are enforced by all nodes, not by majority vote + +ECONOMIC CONSEQUENCES: + +1. Slashing for the liveness attack: + - If the attacker's validators go offline to prevent finality, they face inactivity leak + - Penalties escalate quadratically over time + - After ~2-3 weeks of non-finality, the attacker's stake would be significantly reduced + - Eventually, their share drops below 33%, restoring finality + +2. Cost of attack: + - 34% of staked ETH is tens of billions of dollars + - Slashing could destroy a significant portion of this + - The attack also devalues ETH, destroying the attacker's remaining holdings + +3. Social layer defense: + - The community could coordinate a hard fork to slash the attacker's stake entirely + - This "nuclear option" makes the attack economically suicidal + +Key insight: Proof of Stake is designed so that attacks are economically self-defeating. The quadratic inactivity leak specifically targets the 33%+ liveness attack, gradually restoring finality even if the attacker persists. +``` + +--- + +### Example 4: + +Input: + +``` +A blockchain uses an AI-augmented consensus mechanism called "Optimistic Democracy" where: +- Multiple AI validators independently process the same input +- If all validators agree, the result is accepted immediately +- If there is disagreement, a more expensive "full consensus" round is triggered +- Validators are rewarded for agreeing with the final consensus and penalized for disagreement + +What are the game-theoretic implications of this design? Identify at least one incentive misalignment. +``` + +Output: + +``` +Game-theoretic analysis of Optimistic Democracy: + +INTENDED INCENTIVES: +- Validators are motivated to be accurate (correct results lead to agreement and rewards) +- The optimistic path (immediate acceptance) makes the common case efficient +- The penalty for disagreement discourages random or lazy validation + +INCENTIVE MISALIGNMENT #1 - Herding Behavior: + - Validators are rewarded for AGREEING, not for being CORRECT + - If a validator suspects it has the minority opinion, it's rational to change its answer to match the expected majority + - This creates pressure toward conformity rather than independent verification + - Worst case: All validators converge on the same wrong answer because each fears being the dissenter + - This mirrors the "Keynesian beauty contest" problem in economics + +INCENTIVE MISALIGNMENT #2 - Discouraging Dissent: + - Triggering full consensus is costly for the network + - If a validator detects an error but knows dissenting will trigger the expensive path, it faces a dilemma: + - Dissent: Correct behavior, but risks penalty if other validators don't agree + - Stay silent: Incorrect behavior, but guaranteed reward + - Rational validators may let small errors pass to avoid the cost of full consensus + +INCENTIVE MISALIGNMENT #3 - Copycat Strategies: + - If one validator is known to be highly accurate, others might simply copy its outputs + - This reduces the system to effectively having one validator, destroying the security benefit of multiple independent checks + - Detection is difficult if validators can observe each other's preliminary results + +POSSIBLE FIXES: +1. Commit-reveal scheme: Validators commit to answers before seeing others' responses +2. Reward dissent: Provide a bonus for validators who correctly identify errors (even if they're in the minority) +3. Random audits: Occasionally inject known-answer challenges to verify independent processing +4. Asymmetric penalties: Make the penalty for agreeing on a wrong answer worse than the penalty for lone dissent + +Key insight: Any consensus mechanism that rewards agreement must carefully balance this against the need for independent verification. The "optimistic" assumption works well when errors are rare, but the incentive structure must ensure that errors are caught when they do occur. +``` + +## Tags: +- Consensus Mechanisms +- Distributed Systems +- Byzantine Fault Tolerance +- Game Theory +- Blockchain Security +- Decentralization Analysis +- Incentive Design +- Synthetic diff --git a/tasks/smart-contract-logic-reasoning.md b/tasks/smart-contract-logic-reasoning.md new file mode 100644 index 0000000..09867ee --- /dev/null +++ b/tasks/smart-contract-logic-reasoning.md @@ -0,0 +1,227 @@ +# Smart Contract Logic Reasoning + +## Description: +This task involves analyzing smart contract code, rules, or specifications to predict execution outcomes, identify potential vulnerabilities, and reason about state transitions. It evaluates the model's ability to trace program logic, understand conditional execution paths, and identify edge cases in deterministic, blockchain-based systems where errors are irreversible and financially consequential. + +## Modality: +Text only + +## Examples: + +### Example 1: + +Input: + +``` +A smart contract implements a token sale with the following rules: +- The price starts at 1 ETH per 100 tokens +- After every 1,000 tokens sold, the price increases by 0.5 ETH per 100 tokens +- There is a maximum supply of 5,000 tokens +- Users cannot buy more than 500 tokens in a single transaction + +Alice wants to buy 500 tokens when 900 tokens have already been sold. How much ETH will she need to pay, and why? +``` + +Output: + +``` +Alice's purchase crosses a price tier boundary, so she pays two different rates: + +1. Current tier (0-999 tokens sold): Price is 1 ETH per 100 tokens + - Only 100 tokens remain at this price (1,000 - 900 = 100) + - Cost for first 100 tokens: 1 ETH + +2. Next tier (1,000-1,999 tokens sold): Price is 1.5 ETH per 100 tokens + - Remaining 400 tokens fall into this tier + - Cost for next 400 tokens: 4 × 1.5 = 6 ETH + +Total cost: 1 + 6 = 7 ETH for 500 tokens + +Key reasoning: The contract must handle purchases that span price boundaries. If the contract only checks the price at the start of the transaction, Alice would pay just 5 ETH (500/100 × 1). This discrepancy between intended and actual behavior is a common source of smart contract bugs. +``` + +--- + +### Example 2: + +Input: + +``` +Consider a simple escrow smart contract with these rules: +- A buyer deposits funds into the contract +- The seller delivers goods off-chain and marks the order as "delivered" +- The buyer has 7 days to either confirm receipt or raise a dispute +- If the buyer confirms, funds release to the seller +- If the buyer disputes, a designated arbitrator decides +- If 7 days pass with no action, funds automatically release to the seller + +What happens if the buyer sends the deposit transaction but it gets included in a block right after the seller marks "delivered" in the same block? Trace the state transitions. +``` + +Output: + +``` +This scenario involves transaction ordering within the same block, which requires careful reasoning: + +State transitions: +1. Initial state: Contract exists, no active order +2. Block N contains two transactions (order depends on miner/validator): + +Scenario A - Buyer's deposit is processed first: + - State: order = {status: "funded", buyer: Alice, amount: 1 ETH} + - Seller's "delivered" tx processes next + - State: order = {status: "delivered", deadline: block.timestamp + 7 days} + - Result: Normal flow, buyer has 7 days to confirm or dispute + +Scenario B - Seller's "delivered" tx is processed first: + - State: No active order exists yet + - Seller's tx reverts (cannot mark delivered on non-existent order) + - Buyer's deposit processes successfully + - State: order = {status: "funded", buyer: Alice, amount: 1 ETH} + - Result: Seller must send a new "delivered" transaction + +Key insight: Transaction ordering within a block matters. In Scenario B, the seller wastes gas on a reverted transaction. A well-designed contract checks that the order is in the correct state before allowing transitions, making Scenario B fail gracefully rather than creating an inconsistent state. +``` + +--- + +### Example 3: + +Input: + +``` +A decentralized voting contract has these rules: +- Each address gets exactly one vote +- Voting is open for 100 blocks after deployment +- A proposal passes if it receives more "yes" votes than "no" votes +- The result can only be finalized after the voting period ends + +A user creates a contract that: +1. Calls the voting contract to vote "yes" +2. Transfers its tokens to a new address +3. The new address calls the voting contract to vote "yes" again + +Does this attack work? Why or why not? +``` + +Output: + +``` +Whether this attack works depends on how the voting contract tracks voters: + +Case 1 - Contract tracks by address (mapping(address => bool) hasVoted): + The attack WORKS. Each new contract address is a fresh address that hasn't voted yet. + - Step 1: Contract A votes "yes" → hasVoted[A] = true + - Step 2: Tokens transfer to address B (a new contract) + - Step 3: Contract B votes "yes" → hasVoted[B] = true + - Result: One token holder has cast two votes + +Case 2 - Contract tracks by token balance at a snapshot block: + The attack FAILS. A snapshot of balances is taken at a specific block. + - The snapshot records which addresses held tokens at block X + - Transferring tokens after the snapshot doesn't grant new voting rights + - Address B either had tokens at snapshot time or didn't + +Case 3 - Contract checks current token balance when voting: + The attack PARTIALLY works. The user can vote with address A, transfer, then vote with address B. However, address A's vote might be invalidated if the contract checks balance at finalization. + +Key insight: This is the "double voting" or "vote buying" problem. Snapshot-based voting (Case 2) is the standard defense, commonly implemented as ERC-20 token snapshots taken at proposal creation time. +``` + +--- + +### Example 4: + +Input: + +``` +A lending protocol smart contract has these rules: +- Users deposit collateral (ETH) and borrow stablecoins +- The collateralization ratio must stay above 150% +- If the ratio drops below 150%, anyone can liquidate the position +- Liquidators repay part of the debt and receive the collateral at a 10% discount +- The protocol charges a 0.5% fee on each borrow + +Bob deposits 10 ETH (worth $2,000 each, total $20,000) and borrows $10,000 in stablecoins. ETH then drops to $1,400. What is Bob's collateralization ratio, can he be liquidated, and what would a liquidator's profit be if they liquidate 50% of the debt? +``` + +Output: + +``` +Step 1: Calculate current collateralization ratio + - Collateral value: 10 ETH × $1,400 = $14,000 + - Debt: $10,000 (plus $50 borrow fee = $10,050 total) + - Ratio: $14,000 / $10,050 = 139.3% + +Step 2: Can Bob be liquidated? + - Yes. The ratio (139.3%) is below the 150% threshold. + +Step 3: Calculate liquidator's profit on 50% liquidation + - Debt repaid by liquidator: $10,050 × 50% = $5,025 + - Collateral received at 10% discount: + - $5,025 worth of ETH at market price = 3.589 ETH + - With 10% bonus: 3.589 / 0.9 = 3.988 ETH + - Liquidator spends: $5,025 + - Liquidator receives: 3.988 ETH (worth $5,583.20 at $1,400/ETH) + - Liquidator's profit: $5,583.20 - $5,025 = $558.20 + +Step 4: Bob's position after liquidation + - Remaining collateral: 10 - 3.988 = 6.012 ETH (worth $8,416.80) + - Remaining debt: $10,050 - $5,025 = $5,025 + - New ratio: $8,416.80 / $5,025 = 167.5% (now healthy) + +Key insight: Liquidation mechanics create profitable opportunities that incentivize external actors to keep the protocol solvent. The 10% discount must be large enough to attract liquidators even during high gas price periods, but not so large that borrowers lose excessive collateral. +``` + +--- + +### Example 5: + +Input: + +``` +A time-locked wallet contract has these rules: +- The owner deposits tokens with a lock period (e.g., 365 days) +- Tokens cannot be withdrawn before the lock expires +- The owner can extend the lock period but cannot shorten it +- After the lock expires, only the owner can withdraw + +The contract stores the unlock time as: unlockTime = block.timestamp + lockDuration + +A user sets a lock duration of type uint256 to the value (2^256 - 1). What happens? +``` + +Output: + +``` +This is an integer overflow vulnerability: + +Analysis: +- block.timestamp is a non-zero positive integer (e.g., 1700000000) +- lockDuration = 2^256 - 1 (the maximum uint256 value) +- unlockTime = block.timestamp + lockDuration + +In Solidity versions < 0.8.0 (without SafeMath): + - The addition overflows silently + - unlockTime wraps around to a very small number + - Example: 1700000000 + (2^256 - 1) = 1699999999 (approximately) + - The unlock time is now in the PAST + - The user can immediately withdraw, defeating the time lock + +In Solidity versions >= 0.8.0: + - Built-in overflow checking causes the transaction to revert + - The attack fails, and the user cannot set this lock duration + - No tokens are locked with an invalid duration + +Key insight: Integer overflow was one of the most common smart contract vulnerabilities before Solidity 0.8.0 introduced automatic overflow checks. The fix is either using Solidity >= 0.8.0 or applying OpenZeppelin's SafeMath library. Additionally, the contract should validate that lockDuration falls within a reasonable range (e.g., between 1 day and 10 years). +``` + +## Tags: +- Smart Contracts +- Blockchain Reasoning +- Program Logic Tracing +- State Machine Analysis +- Vulnerability Identification +- Edge Case Detection +- Deterministic Systems +- Synthetic diff --git a/tasks/tokenomics-and-incentive-design-reasoning.md b/tasks/tokenomics-and-incentive-design-reasoning.md new file mode 100644 index 0000000..023a6f2 --- /dev/null +++ b/tasks/tokenomics-and-incentive-design-reasoning.md @@ -0,0 +1,344 @@ +# Tokenomics and Incentive Design Reasoning + +## Description: +This task involves analyzing economic models, reward mechanisms, and incentive structures in token-based systems. It evaluates the model's ability to reason about supply and demand dynamics, identify misaligned incentives, detect potential economic attack vectors, and assess the long-term sustainability of token distribution and reward models in decentralized systems. + +## Modality: +Text only + +## Examples: + +### Example 1: + +Input: + +``` +A new DeFi protocol launches with the following tokenomics: +- Total supply: 100 million tokens +- Distribution: 20% team (4-year vest), 30% investors (2-year vest), 10% community airdrop (no lock), 40% emissions over 5 years +- The token is used for governance voting +- Staking rewards: 15% APY paid from the emissions pool + +At launch, what percentage of tokens are immediately circulating, and what governance implications does this create? +``` + +Output: + +``` +Circulating supply analysis at launch: + +Immediately circulating: +- Community airdrop: 10% of 100M = 10 million tokens (no lock) +- Emissions begin: Some portion of the 40% starts distributing + +Locked at launch: +- Team: 20% locked (4-year vest, likely with 1-year cliff = 0% available) +- Investors: 30% locked (2-year vest, terms vary but typically 0% at launch) + +Circulating at launch: ~10 million tokens (10% of total supply) + +Governance implications: + +1. Airdrop recipients control 100% of governance power at launch + - Many airdrop recipients are short-term holders who may sell immediately + - Those who keep tokens have outsized voting power + - A coordinated group holding just 5.1M tokens (5.1% of total) could pass any vote + +2. Investor-team misalignment: + - Team and investors (50% of supply) have no governance power initially + - Early governance decisions are made by the least financially committed group + - Critical protocol parameters could be set before major stakeholders can participate + +3. Progressive centralization risk: + - As team/investor tokens vest, governance shifts from community to insiders + - Year 2: Investors fully unlock 30M tokens, potentially dominating governance + - Year 4: Team unlocks 20M more, and insiders could control 50% of all votes + +4. Whale risk in the airdrop: + - If the airdrop criteria favored large users, a few addresses may hold millions of tokens + - These "airdrop whales" could extract value through governance before others unlock + +Recommendation: Implement time-weighted voting or require tokens to be staked for a minimum period before gaining voting rights. This aligns governance power with long-term commitment rather than simply holding tokens at the right moment. +``` + +--- + +### Example 2: + +Input: + +``` +A play-to-earn game has the following economy: +- Players earn 100 GOLD tokens per day by playing +- GOLD can be used to buy in-game items or sold on exchanges +- New items cost 500-2000 GOLD to craft +- The game has 10,000 active players and is growing 20% monthly +- There is no mechanism to remove GOLD from circulation other than crafting + +After 6 months, the player base has grown from 10,000 to approximately 30,000. Analyze the economic sustainability of this model. +``` + +Output: + +``` +Economic analysis over 6 months: + +Supply calculation: +- Month 1: ~10,000 players × 100 GOLD/day × 30 days = 30,000,000 GOLD created +- Month 2: ~12,000 players → 36,000,000 GOLD +- Month 3: ~14,400 players → 43,200,000 GOLD +- Month 4: ~17,280 players → 51,840,000 GOLD +- Month 5: ~20,736 players → 62,208,000 GOLD +- Month 6: ~24,883 players → 74,649,600 GOLD +- Total GOLD created: ~297,897,600 GOLD + +Demand estimation (assuming 30% of daily earnings spent on crafting): +- Average daily sink per player: 30 GOLD (30% of 100) +- Total removed via crafting over 6 months: ~89,369,280 GOLD + +Net inflation: ~208,528,320 GOLD added to circulation with insufficient sinks + +The "death spiral" problem: +1. Excess supply → GOLD price drops on exchanges +2. Dropping price → Players earn less real value per day +3. Less real value → Players leave or stop playing +4. Players leaving → Less crafting demand → Fewer tokens removed +5. Even more excess supply → Price drops further +6. Repeat until the economy collapses + +Why growth temporarily masks the problem: +- New players create buying pressure (they need items, so they buy GOLD) +- Growth feels like a healthy economy, but it requires perpetual new entrants +- This is structurally similar to a Ponzi scheme: early players profit from later ones +- When growth slows (inevitable), the excess supply becomes immediately apparent + +Missing economic mechanisms: +1. No transaction fees or taxes (no passive burn) +2. No item degradation or durability (no recurring demand) +3. No GOLD staking or lock-up mechanisms (no supply reduction) +4. Fixed emissions regardless of price (no adaptive supply) + +Sustainable alternatives: +- Implement item durability: items break after N uses, requiring re-crafting +- Add transaction fees: 2-5% tax on all GOLD transfers, burned permanently +- Dynamic emissions: Reduce GOLD per day as player count grows +- Staking: Lock GOLD for boosted rewards, reducing circulating supply +- External revenue: Use real-world revenue to buy and burn GOLD + +Key insight: Any token economy where supply grows faster than organic demand is unsustainable. The critical metric is not token price but the ratio of tokens created to tokens permanently removed. A sustainable economy requires this ratio to approach 1:1 over time. +``` + +--- + +### Example 3: + +Input: + +``` +A decentralized protocol offers two staking options: + +Option A: Liquid staking +- Stake ETH, receive stETH (tradeable receipt token) +- 4% APY in rewards +- Can sell stETH at any time (usually trades near 1:1 with ETH) +- No lock-up period + +Option B: Locked staking +- Stake ETH directly, no receipt token +- 7% APY in rewards +- 6-month lock-up, cannot withdraw early +- Penalty of 10% if you exit before lock expires (emergency withdrawal) + +Analyze which option a rational actor chooses under different market conditions and identify any systemic risks. +``` + +Output: + +``` +Rational actor analysis: + +Scenario 1 - Stable/bull market (ETH price steady or rising): + Option A is preferred for most users: + - The 3% APY difference (4% vs 7%) may not justify losing liquidity for 6 months + - stETH can be used as collateral in DeFi for additional yield + - Total effective APY with DeFi composability: 4% staking + 3-8% lending = 7-12% + - Option A actually beats Option B on total returns while maintaining liquidity + +Scenario 2 - Bear market (ETH price falling sharply): + Option B users are trapped: + - 6-month lock means watching their position lose value + - Emergency exit costs 10% penalty on top of market losses + - Example: ETH drops 40% + 10% penalty = ~46% total loss + Option A users can exit: + - Sell stETH immediately (may trade at 2-5% discount in a crisis) + - Limit losses to the market drop + small stETH discount + +Scenario 3 - Black swan event (protocol vulnerability discovered): + Both options face risk, but differently: + - Option A: stETH may depeg severely if markets panic (could trade at 0.80-0.90 ETH) + - Option B: Cannot exit at all, fully exposed to whatever happens over 6 months + - Paradox: The "safer" locked option becomes riskier during crises + +Systemic risks: + +1. stETH depeg cascade: + - stETH is widely used as collateral in lending protocols + - If stETH depegs from ETH, it triggers liquidation cascades + - Liquidations flood the market with more stETH, deepening the depeg + - This nearly happened in June 2022 during the Celsius/3AC crisis + +2. Concentration risk: + - If Option A dominates (likely due to composability advantages), most staked ETH flows to one liquid staking provider + - One provider controlling >33% of staked ETH creates centralization risk + - This is a real concern for the Ethereum ecosystem today + +3. Lock-up false security: + - Option B's lock-up appears to provide protocol stability + - But in a crisis, users requesting emergency withdrawals simultaneously could drain the protocol + - The 10% penalty creates a bank-run dynamic: exit early to avoid being last + +Key insight: Liquid staking dominates locked staking in almost every scenario due to DeFi composability, which is why liquid staking has captured the majority of the market. The systemic risk this creates (concentration in a few liquid staking providers) is now a major concern for blockchain decentralization. +``` + +--- + +### Example 4: + +Input: + +``` +A DAO (Decentralized Autonomous Organization) treasury holds $50 million in its native TOKEN. A proposal is submitted: + +"Spend $5 million from the treasury to buy back TOKEN from the open market and burn it, reducing supply and increasing the price for all holders." + +Analyze whether this proposal benefits TOKEN holders. Consider who gains, who loses, and what second-order effects occur. +``` + +Output: + +``` +First-order analysis - Apparent benefit: +- Current supply: 100 million TOKEN at $0.50 each (market cap $50M) +- Buyback: $5M buys 10 million TOKEN at $0.50 +- Burn: Supply reduces to 90 million TOKEN +- If market cap stays constant: New price = $50M / 90M = $0.556 (11.1% increase) +- Seems beneficial for all holders + +Deeper analysis - Who actually benefits: + +1. The treasury IS part of the market cap: + - Treasury holds $50M in TOKEN, but this is already priced in + - Spending $5M from treasury reduces treasury value to $45M + - The DAO collectively became $5M poorer to buy its own tokens + - This is analogous to a company buying back stock with its own stock + +2. Immediate sellers benefit most: + - The $5M buy pressure temporarily increases price + - Traders who sell into the buyback capture real value + - After the buyback completes, buying pressure disappears + - Price likely settles back near original levels + +3. Token holders face diluted treasury: + - Before: Each TOKEN represents a claim on $50M treasury / 100M tokens = $0.50 per token + - After: Each TOKEN represents $45M treasury / 90M tokens = $0.50 per token + - The per-token treasury backing is UNCHANGED + - Holders gained nothing; they just own a larger percentage of a smaller treasury + +Second-order effects: + +1. Opportunity cost: $5M could have funded development, marketing, or partnerships that create real value +2. Signal effect: Buybacks signal the DAO has no better use for capital, which is bearish +3. Governance capture: Large holders vote for buybacks because they benefit from short-term price increases, at the expense of long-term protocol development +4. Tax implications: In some jurisdictions, buyback-driven price increases create taxable events for holders + +When buybacks DO make sense: +- When TOKEN is trading significantly below fundamental value (book value, revenue multiples) +- When the DAO genuinely has no productive use for excess capital +- When combined with real revenue (not just spending the treasury) + +Key insight: Token buybacks from a treasury that holds the same token are largely cosmetic. Real value creation comes from building products or services that generate external revenue, not from financial engineering that shuffles tokens between the treasury and the market. +``` + +--- + +### Example 5: + +Input: + +``` +Two competing decentralized exchanges (DEXs) launch with different fee models: + +DEX A: Fixed 0.3% fee on every swap +- Fees go 100% to liquidity providers (LPs) +- No protocol token + +DEX B: Variable fees (0.1% to 1%, set by governance) +- 80% of fees go to LPs +- 20% of fees go to TOKEN stakers +- TOKEN holders vote on fee rates + +Predict how these models evolve over time and which captures more market share. +``` + +Output: + +``` +Short-term evolution (0-6 months): + +DEX A advantages: +- Simpler, more predictable for users and LPs +- 100% fee share attracts more liquidity providers +- More liquidity → better prices → more users (virtuous cycle) + +DEX B advantages: +- TOKEN creates speculative interest and community +- Governance participation feels empowering +- Lower initial fees (0.1%) can undercut DEX A to attract volume + +Prediction: DEX A likely captures more initial liquidity due to higher LP rewards. + +Medium-term evolution (6-18 months): + +The governance fee dilemma emerges on DEX B: +- TOKEN holders want HIGH fees (maximizes their 20% share) +- Users want LOW fees (cheaper trading) +- LPs want HIGH fees (more revenue per trade) +- These incentives conflict, and TOKEN holders control the vote + +Likely outcome on DEX B: +1. TOKEN holders vote to increase fees to 0.5-1% +2. Higher fees drive users to DEX A or other competitors +3. Lower volume means less total revenue despite higher fee rate +4. LPs leave for DEX A (more volume = more total fees at 0.3%) +5. Less liquidity → worse prices → more users leave +6. Death spiral of increasing fees on decreasing volume + +The "fee switch" trap: +- DEX A faces pressure to add a token and protocol fee to compete for developer funding +- Adding a protocol fee reduces LP returns, potentially losing liquidity +- Not adding a token means no war chest for development or incentives +- This is the fundamental tension between LP economics and protocol sustainability + +Long-term equilibrium: + +The market likely converges toward: +- Fee rates around 0.05-0.3% for competitive pairs (ETH/USDC) +- Higher fees (0.3-1%) for exotic or low-liquidity pairs +- Concentrated liquidity models where LPs earn more per dollar deployed +- Protocol revenue coming from value-added services, not base swap fees + +Historical parallel: This played out with Uniswap (fixed fee, no token initially) vs SushiSwap (token + protocol fee). Uniswap maintained dominance, later added a token (UNI) but still hasn't turned on the fee switch after years of governance debate. + +Key insight: Fee models that align all stakeholders (users, LPs, token holders) outperform those that create adversarial governance dynamics. The "protocol fee" sounds like free money for token holders, but it's actually a tax on the protocol's competitive position that reduces total value over time. +``` + +## Tags: +- Tokenomics +- Economic Reasoning +- Incentive Design +- Game Theory +- Supply and Demand Analysis +- DeFi Mechanisms +- Market Dynamics +- Attack Vector Identification +- Synthetic