@ballkidz/defifa 0.0.1

package/CRYPTO_ECON.md

@@ -0,0 +1,955 @@
+# Cryptoeconomics of Defifa
+
+**Claude Opus 4.6 (Anthropic) in coordination with Jango from the Defifa Team.**
+*This analysis was generated by Claude Opus 4.6 based on its study of the Defifa V5 codebase and the [Revnet Whitepaper](https://cryptoeconlab.com/paper/pub-0?paper=https%253A%252F%252Fstorage.googleapis.com%252Fcel-public-resources%252FRevnet-Whitepaper.pdf) by CryptoEconLab.*
+
+*March 2026*
+
+---
+
+## Abstract
+
+Defifa is a prediction-game protocol built on Juicebox V5 that transforms NFT minting into a parimutuel wagering mechanism with governance-ratified outcomes. Players purchase ERC-721 game pieces representing competing tiers (teams, candidates, outcomes), forming a shared treasury. After the event concludes, a decentralized attestation process ratifies a scorecard that assigns weights to each tier, redistributing the treasury proportionally. This paper formalizes the cryptoeconomic mechanics of Defifa games: the prize distribution formula, the attestation governance model, the fee extraction pipeline, the protocol-token incentive layer, and the rational actor strategies that emerge. We derive solvency guarantees, characterize equilibrium behavior under various participation profiles, analyze the game-theoretic properties of the scorecard ratification process, and identify the parameter regimes that maximize game integrity and participant welfare.
+
+---
+
+## Contents
+
+1. [Introduction](#1-introduction)
+   1. [What is Defifa?](#11-what-is-defifa)
+   2. [How a Defifa Game Works (at a glance)](#12-how-a-defifa-game-works-at-a-glance)
+   3. [The Design Parameters](#13-the-design-parameters)
+2. [Mathematical Model of Defifa Economics](#2-mathematical-model-of-defifa-economics)
+   1. [Parameters and State Variables](#21-parameters-and-state-variables)
+   2. [Minting — Pot Formation](#22-minting--pot-formation)
+   3. [Refund — Optionality Window](#23-refund--optionality-window)
+   4. [Prize Distribution — The Scorecard Formula](#24-prize-distribution--the-scorecard-formula)
+   5. [Fee Extraction Pipeline](#25-fee-extraction-pipeline)
+   6. [Protocol Token Allocation](#26-protocol-token-allocation)
+3. [Attestation Governance and Scorecard Ratification](#3-attestation-governance-and-scorecard-ratification)
+   1. [Voting Power Model](#31-voting-power-model)
+   2. [Quorum and Ratification Conditions](#32-quorum-and-ratification-conditions)
+   3. [Scorecard Lifecycle](#33-scorecard-lifecycle)
+   4. [Resistance to Strategic Manipulation](#34-resistance-to-strategic-manipulation)
+4. [Price Dynamics and Value Flows](#4-price-dynamics-and-value-flows)
+   1. [NFT Intrinsic Value During Minting](#41-nft-intrinsic-value-during-minting)
+   2. [Post-Scorecard Valuation](#42-post-scorecard-valuation)
+   3. [Secondary Market Implications](#43-secondary-market-implications)
+5. [Rational Actor Analysis](#5-rational-actor-analysis)
+   1. [Mint-Phase Strategy: Entry Timing](#51-mint-phase-strategy-entry-timing)
+   2. [Refund-Phase Strategy: Option Exercise](#52-refund-phase-strategy-option-exercise)
+   3. [Scoring-Phase Strategy: Attestation Delegation](#53-scoring-phase-strategy-attestation-delegation)
+   4. [Complete-Phase Strategy: Claim vs Hold](#54-complete-phase-strategy-claim-vs-hold)
+6. [Solvency and Conservation Laws](#6-solvency-and-conservation-laws)
+   1. [The Conservation Guarantee](#61-the-conservation-guarantee)
+   2. [Solvency Under Sequential Cash-Outs](#62-solvency-under-sequential-cash-outs)
+   3. [Fee Impact on Total Claimable Value](#63-fee-impact-on-total-claimable-value)
+7. [Game-Theoretic Properties](#7-game-theoretic-properties)
+   1. [Defifa as a Parimutuel Mechanism](#71-defifa-as-a-parimutuel-mechanism)
+   2. [Information Aggregation](#72-information-aggregation)
+   3. [Multi-Game Dynamics and Protocol Flywheel](#73-multi-game-dynamics-and-protocol-flywheel)
+8. [Parameter Design Space](#8-parameter-design-space)
+   1. [Tier Count and Price Calibration](#81-tier-count-and-price-calibration)
+   2. [Timing Parameters](#82-timing-parameters)
+   3. [Fee Calibration and Protocol Sustainability](#83-fee-calibration-and-protocol-sustainability)
+9. [Open Problems and Mechanism Design Recommendations](#9-open-problems-and-mechanism-design-recommendations)
+   1. [Governance Deadlock and Fund Recovery: A Deep Study](#91-governance-deadlock-and-fund-recovery-a-deep-study)
+   2. [Cheap Cross-Tier Attestation Capture](#92-cheap-cross-tier-attestation-capture)
+   3. [Prize Pool Under-Allocation](#93-prize-pool-under-allocation)
+   4. [Attestation Timing Misconfiguration](#94-attestation-timing-misconfiguration)
+   5. [Pre-Scoring Scorecard Submission](#95-pre-scoring-scorecard-submission)
+   6. [Fee Extraction Fragility](#96-fee-extraction-fragility)
+10. [Conclusions and Practical Implications](#10-conclusions-and-practical-implications)
+
+---
+
+## 1 Introduction
+
+### 1.1 What is Defifa?
+
+Defifa is a prediction-game protocol that transforms the act of purchasing an NFT into a wager on the outcome of a real-world event. It is deployed using the Juicebox V5 protocol and governed by a combination of immutable smart-contract rules and a minimal, time-bounded governance process for outcome resolution.
+
+A Defifa game is a *tokenized parimutuel pool*: money goes in via NFT purchases, forming a shared pot; after the event concludes, a governance process assigns weights to each tier (team, outcome, candidate), and the pot is distributed proportionally. The game pieces are ERC-721 tokens organized into tiers, where each tier represents a distinct prediction. The purchase price of a tier token is fixed at game creation, and the payout is determined by post-event scorecard ratification.
+
+Defifa games are:
+
+- **Deterministic in structure**: all phases, durations, tier prices, and fee schedules are fixed at deployment.
+- **Governance-minimal**: the only human input is the scorecard — a mapping from tiers to weights — ratified through an attestation process.
+- **Self-custodial**: all funds remain in the Juicebox treasury; no operator can access them outside the protocol rules.
+- **Composable**: games are standard Juicebox projects, inheriting the full protocol's accounting, terminal, and hook infrastructure.
+
+### 1.2 How a Defifa Game Works (at a glance)
+
+1. **Mint (pot formation).** During the mint phase, anyone can purchase NFTs representing tiers. Each NFT has a fixed price denominated in the game's base asset (e.g., ETH). All payments flow into a shared treasury — the *pot*. Players may delegate their attestation power to a chosen delegate at mint time.
+
+2. **Refund (optional exit window).** If configured, a refund phase follows minting. During this period, players may burn their NFTs to reclaim the original mint price, allowing a risk-free exit for those who change their minds. No new mints are accepted.
+
+3. **Score (outcome resolution).** Once the real-world event concludes, anyone may propose a *scorecard* — a vector of weights summing to $W_{\text{total}} = 10^{18}$ — assigning each tier its share of the pot. NFT holders attest to the scorecard they believe reflects the correct outcome. Once a scorecard achieves quorum, it can be ratified.
+
+4. **Complete (prize distribution).** After ratification, protocol fees are extracted, and the remaining pot is available for claims. Each NFT holder burns their token to receive their proportional share, plus any accrued protocol tokens ($\text{DEFIFA}$ and $\text{BASE\_PROTOCOL}$).
+
+### 1.3 The Design Parameters
+
+A Defifa game is fully specified at deployment by a parameter tuple:
+
+$$\mathcal{G} = \left( \{T_i\}_{i=1}^{N}, \; t_{\text{mint}}, \; t_{\text{refund}}, \; t_{\text{start}}, \; \phi_{\text{defifa}}, \; \phi_{\text{base}}, \; \mathcal{S}, \; \tau_{\text{attest}}, \; \tau_{\text{grace}} \right) \tag{1}$$
+
+Where:
+
+1. **Tier configuration** $\{T_i\}_{i=1}^{N}$: For each of the $N$ tiers, a fixed price $p_i$, an optional reserved rate $\rho_i$, and a reserved-token beneficiary address. The initial supply per tier is set to $999{,}999{,}999$ (effectively unlimited).
+
+2. **Mint period duration** ($t_{\text{mint}}$): How long the minting window stays open, in seconds.
+
+3. **Refund period duration** ($t_{\text{refund}}$): How long the refund window stays open after minting closes. May be zero (no refund phase).
+
+4. **Game start time** ($t_{\text{start}}$): When the scoring phase begins — typically aligned with the real-world event's conclusion.
+
+5. **Defifa fee divisor** ($\phi_{\text{defifa}}$): The fraction $1/\phi_{\text{defifa}}$ of the pot sent to the Defifa protocol project. Default: $\phi_{\text{defifa}} = 20$ (5%).
+
+6. **Base protocol fee divisor** ($\phi_{\text{base}}$): The fraction $1/\phi_{\text{base}}$ of the pot sent to the base protocol project. Default: $\phi_{\text{base}} = 20$ (5%).
+
+7. **Splits** ($\mathcal{S}$): Additional payout splits configured at deployment (e.g., for game organizers, charities).
+
+8. **Attestation start time** ($\tau_{\text{attest}}$): Delay before attestation voting opens on a submitted scorecard.
+
+9. **Attestation grace period** ($\tau_{\text{grace}}$): Duration of the attestation voting window.
+
+Once set, the tuple $\mathcal{G}$ is immutable. Phase transitions occur automatically by timestamp, with the scoring phase having infinite duration (duration = 0) until the scorecard is ratified.
+
+---
+
+## 2 Mathematical Model of Defifa Economics
+
+### 2.1 Parameters and State Variables
+
+The economic behavior of a Defifa game is determined jointly by:
+
+1. The immutable game parameters $\mathcal{G}$ (cf. Section 1.3), fixed at deployment;
+2. The evolving state variables, which track the pot, token supplies, and claim status over time.
+
+**Game parameters.** For reference, the parameter tuple is:
+
+$$\mathcal{G} = \left( \{T_i\}_{i=1}^{N}, \; t_{\text{mint}}, \; t_{\text{refund}}, \; t_{\text{start}}, \; \phi_{\text{defifa}}, \; \phi_{\text{base}}, \; \mathcal{S}, \; \tau_{\text{attest}}, \; \tau_{\text{grace}} \right)$$
+
+**State variables.** The core dynamic variables are listed in Table 1.
+
+| Variable | Description |
+|----------|-------------|
+| $B(t)$ | Pot (treasury balance) at time $t$ |
+| $n_i(t)$ | Number of NFTs minted in tier $i$ at time $t$ |
+| $N_{\text{total}}(t)$ | Total NFTs outstanding across all tiers: $\sum_i n_i(t)$ |
+| $M(t)$ | Total mint cost accumulated: $\sum_i n_i(t) \cdot p_i$ |
+| $w_i$ | Scorecard weight assigned to tier $i$ (set at ratification, $\sum_i w_i = W_{\text{total}}$) |
+| $d_i(t)$ | Number of NFTs redeemed (burned for prize) from tier $i$ after ratification |
+| $B_{\text{prize}}$ | Net prize pool after fee extraction |
+
+*Table 1: Core state variables of a Defifa game.*
+
+At any time $t$, the state of the game is fully determined by the pair $\left(\mathcal{G}, \; \{B(t), n_i(t), w_i, d_i(t)\}\right)$, where $\mathcal{G}$ is the fixed game configuration and the second component evolves endogenously as players interact with the game. The next subsections formalize how each mechanism updates these variables.
+
+### 2.2 Minting — Pot Formation
+
+During the mint phase $[t_{\text{mint\_start}}, \; t_{\text{mint\_start}} + t_{\text{mint}})$, any participant may purchase NFTs from any tier $i$ at the fixed price $p_i$ per token (denominated in the game's base asset).
+
+**Minted quantity.** For a payment amount $x$ of base asset directed at tier $i$:
+
+$$q_i = \left\lfloor \frac{x}{p_i} \right\rfloor \tag{2}$$
+
+The discrete nature of NFTs means that fractional tokens are not issued; any remainder is refunded.
+
+**Reserved minting.** If tier $i$ has a reserved rate $\rho_i > 0$, then for every $\rho_i$ tokens minted by paying players, one additional token is minted to the reserved-token beneficiary. Reserved tokens are *not* paid for, but their cost is counted toward $M(t)$ for purposes of protocol-token distribution (cf. Section 2.6).
+
+**State updates.** At the instant of a mint event where player $j$ purchases $q$ tokens of tier $i$:
+
+$$B(t^+) = B(t^-) + q \cdot p_i \tag{3}$$
+
+$$n_i(t^+) = n_i(t^-) + q \tag{4}$$
+
+$$M(t^+) = M(t^-) + q \cdot p_i \tag{5}$$
+
+These update rules define a monotonically increasing pot $B(t)$ during the mint phase, with the pot serving as a *fully-backed prize pool* — every unit of base asset entering the treasury corresponds to exactly $1/p_i$ NFTs issued to the payer.
+
+**Pot composition.** At the end of the mint phase, the pot is:
+
+$$B_{\text{mint}} = \sum_{i=1}^{N} n_i \cdot p_i \tag{6}$$
+
+This is the total capital at risk in the game, and represents the complete prize pool before fee extraction.
+
+### 2.3 Refund — Optionality Window
+
+If $t_{\text{refund}} > 0$, a refund phase follows minting. During $[t_{\text{mint\_end}}, \; t_{\text{mint\_end}} + t_{\text{refund}})$:
+
+- No new mints are accepted ($\texttt{pausePay} = \text{true}$).
+- Any NFT holder may burn their token to reclaim its mint price.
+
+**Refund mechanics.** A player burning $q$ tokens of tier $i$ receives exactly $q \cdot p_i$ base asset from the treasury:
+
+$$R_{\text{refund}} = q \cdot p_i \tag{7}$$
+
+**State updates.** After a refund:
+
+$$B(t^+) = B(t^-) - q \cdot p_i \tag{8}$$
+
+$$n_i(t^+) = n_i(t^-) - q \tag{9}$$
+
+$$M(t^+) = M(t^-) - q \cdot p_i \tag{10}$$
+
+The refund phase creates a *free option* for participants: they can observe late-breaking information (injury reports, market movements, team changes) and exit at zero cost. This option has value and we analyze its implications in Section 5.2.
+
+**Key property.** The refund is dollar-for-dollar: every token refunded removes exactly its mint price from the pot, preserving the per-NFT backing ratio $B(t) / N_{\text{total}}(t)$ for uniform-priced games.
+
+### 2.4 Prize Distribution — The Scorecard Formula
+
+After the real-world event concludes and a scorecard is ratified, the game enters the COMPLETE phase. Players may burn their NFTs to claim their share of the prize pool.
+
+**The scorecard.** A scorecard is a vector of weights $\mathbf{w} = (w_1, w_2, \ldots, w_N)$ satisfying:
+
+$$\sum_{i=1}^{N} w_i = W_{\text{total}} = 10^{18} \tag{11}$$
+
+Each $w_i \in [0, W_{\text{total}}]$ represents the fraction of the prize pool allocated to tier $i$'s holders.
+
+**Per-token weight.** The weight assigned to a single NFT in tier $i$ is:
+
+$$w_i^{\text{token}} = \frac{w_i}{\hat{n}_i} \tag{12}$$
+
+where $\hat{n}_i$ is the *effective* number of tokens eligible for redemption in tier $i$ at the time the scorecard is ratified:
+
+$$\hat{n}_i = n_i^{\text{minted}} - n_i^{\text{remaining}} - (n_i^{\text{burned}} - d_i) \tag{13}$$
+
+Here $n_i^{\text{minted}}$ is the initial supply, $n_i^{\text{remaining}}$ is the unminted supply, $n_i^{\text{burned}}$ is the total burned count, and $d_i$ is the number of tokens redeemed *in the complete phase specifically*. This formula ensures that as tokens are redeemed in the complete phase, the denominator adjusts to maintain fair distribution for remaining holders.
+
+**Cash-out value.** When a player burns a set of token IDs $\{k_1, k_2, \ldots, k_m\}$, the total claim is computed as:
+
+$$C(\{k_j\}) = \frac{\sum_{j=1}^{m} w_{i(k_j)}^{\text{token}}}{W_{\text{total}}} \cdot (B_{\text{prize}} + A_{\text{redeemed}}) \tag{14}$$
+
+where:
+- $i(k_j)$ is the tier of token $k_j$,
+- $B_{\text{prize}}$ is the current treasury balance (post-fee),
+- $A_{\text{redeemed}}$ is the cumulative amount already redeemed by prior players.
+
+The term $(B_{\text{prize}} + A_{\text{redeemed}})$ reconstructs the *original* post-fee pot, ensuring that the order of redemptions does not affect the payout per token. This is a critical design property: it makes Defifa a *path-independent* mechanism. The actual surplus from which the payout is drawn is the current treasury balance $B_{\text{prize}}$ — the formula normalizes against the full original pot to compute the correct fraction, then pays out from what remains.
+
+**Special cases:**
+
+- **Winner-take-all:** $w_j = W_{\text{total}}$ for a single tier $j$, all others zero.
+- **Proportional split:** $w_i = W_{\text{total}} \cdot n_i / N_{\text{total}}$ weights by participation count.
+- **No contest (by convention):** All $w_i$ set proportionally to return mint prices, effectively implementing a full refund through the standard scorecard mechanism.
+
+### 2.5 Fee Extraction Pipeline
+
+Before prize distribution begins, the Deployer contract extracts protocol fees by calling `fulfillCommitmentsOf`. This triggers a `sendPayoutsOf` call on the terminal, distributing the pot according to the scoring-phase splits.
+
+**Split structure.** The splits configured at game launch allocate the pot as follows:
+
+1. **Base protocol fee:** $\frac{1}{\phi_{\text{base}}}$ of the pot to the base protocol project (default: 5%)
+2. **Defifa fee:** $\frac{1}{\phi_{\text{defifa}}}$ of the pot to the Defifa project (default: 5%)
+3. **Custom splits** ($\mathcal{S}$): Any additional game-creator-defined splits
+4. **Remainder:** Returned to the game's treasury via `addToBalanceOf`
+
+**Fee formulas.** Let $B_{\text{pot}}$ be the treasury balance at commitment fulfillment. The fee amounts are:
+
+$$F_{\text{base}} = \frac{B_{\text{pot}}}{\phi_{\text{base}}} \tag{15}$$
+
+$$F_{\text{defifa}} = \frac{B_{\text{pot}}}{\phi_{\text{defifa}}} \tag{16}$$
+
+$$F_{\text{custom}} = \sum_{s \in \mathcal{S}} \frac{B_{\text{pot}} \cdot \text{percent}_s}{\text{SPLITS\_TOTAL\_PERCENT}} \tag{17}$$
+
+The prize pool available for player claims is:
+
+$$B_{\text{prize}} = B_{\text{pot}} - F_{\text{base}} - F_{\text{defifa}} - F_{\text{custom}} \tag{18}$$
+
+With default parameters ($\phi_{\text{base}} = \phi_{\text{defifa}} = 20$, no custom splits), the prize pool is:
+
+$$B_{\text{prize}} = B_{\text{pot}} \cdot \left(1 - \frac{1}{20} - \frac{1}{20}\right) = 0.9 \cdot B_{\text{pot}} \tag{19}$$
+
+**Fee recycling.** The fees paid to the Defifa and base protocol projects are processed as standard Juicebox payments, which mint project tokens (e.g., $\text{DEFIFA}$, $\text{BASE\_PROTOCOL}$) to the beneficiary — in this case, the game's hook contract. These tokens are later distributed to players upon claim (Section 2.6).
+
+### 2.6 Protocol Token Allocation
+
+When fees are paid to the Defifa and base protocol projects, those projects mint their respective tokens to the game hook's address. The hook contract accumulates these tokens and distributes them proportionally when players burn their NFTs in the COMPLETE phase.
+
+**Token allocation per player.** For a player burning tokens with cumulative mint cost $c$:
+
+$$X_{\text{defifa}} = \frac{c}{M} \cdot D_{\text{total}} \tag{20}$$
+
+$$X_{\text{base}} = \frac{c}{M} \cdot P_{\text{total}} \tag{21}$$
+
+where:
+- $M = $ total mint cost of all tokens ever minted in the game ($\texttt{\_totalMintCost}$),
+- $D_{\text{total}} = $ total $\text{DEFIFA}$ tokens held by the hook contract,
+- $P_{\text{total}} = $ total $\text{BASE\_PROTOCOL}$ tokens held by the hook contract.
+
+**Key property.** Protocol token distribution is proportional to *original mint cost*, not to scorecard weight. This means that even holders of losing tiers (weight = 0) receive protocol tokens when burning their NFTs, creating a partial consolation mechanism that rewards participation regardless of outcome.
+
+**Incentive alignment.** This design ensures that:
+- *Larger bets* (higher mint cost) receive proportionally more protocol tokens,
+- *All participants* have an incentive to burn their NFTs even in losing tiers (to claim protocol tokens),
+- The protocol *captures value* from every game through its fee-token flywheel.
+
+---
+
+## 3 Attestation Governance and Scorecard Ratification
+
+### 3.1 Voting Power Model
+
+The attestation mechanism uses a *per-tier proportional representation* model rather than a simple one-token-one-vote system. This design prevents any single tier's holders from dominating the governance process.
+
+**Attestation units.** Each tier $i$ carries a maximum attestation power of:
+
+$$V_{\text{max}} = 10^9 \quad \text{(MAX\_ATTESTATION\_POWER\_TIER)} \tag{22}$$
+
+This maximum is shared among all holders of tier $i$. A holder's attestation weight for tier $i$ is:
+
+$$v_i^{\text{holder}} = V_{\text{max}} \cdot \frac{n_i^{\text{holder}}}{n_i^{\text{total}}} \tag{23}$$
+
+where $n_i^{\text{holder}}$ is the number of tier-$i$ tokens delegated to (or held by) the attestor, and $n_i^{\text{total}}$ is the total minted supply of tier $i$ at the attestation snapshot timestamp.
+
+**Total attestation weight.** A holder's total attestation power across all tiers is:
+
+$$v^{\text{holder}} = \sum_{i : n_i^{\text{holder}} > 0} V_{\text{max}} \cdot \frac{n_i^{\text{holder}}}{n_i^{\text{total}}} \tag{24}$$
+
+**Checkpoint-based snapshots.** Attestation power is measured at a fixed timestamp (the scorecard's `attestationsBegin` time), using historical checkpoints. This prevents vote-buying attacks where an actor acquires tokens immediately before voting.
+
+**Delegation.** During the mint phase only, holders may delegate their attestation units to a chosen delegate address per tier. Delegation is:
+- Per-tier (a holder can delegate different tiers to different delegates),
+- Snapshot-locked (only the delegation state at `attestationsBegin` counts),
+- Mint-phase-only (no delegation changes after minting closes).
+
+### 3.2 Quorum and Ratification Conditions
+
+**Quorum calculation.** The quorum required for scorecard ratification is:
+
+$$Q = \frac{N_{\text{minted\_tiers}}}{2} \cdot V_{\text{max}} \tag{25}$$
+
+where $N_{\text{minted\_tiers}}$ is the number of tiers that have at least one minted token. This means a scorecard must achieve attestation weight equivalent to *half of all minted tiers voting unanimously* to pass.
+
+**Example.** For a game with 4 tiers (all minted), the quorum is:
+
+$$Q = \frac{4}{2} \cdot 10^9 = 2 \times 10^9$$
+
+This requires the equivalent of 2 full tiers' worth of unanimous attestation — for instance, all holders of 2 tiers attesting, or 50% of holders across all 4 tiers.
+
+**Ratification conditions.** A scorecard can be ratified when all three conditions are met:
+1. The scorecard's grace period has expired ($\texttt{gracePeriodEnds} < \texttt{block.timestamp}$),
+2. The attestation count meets or exceeds quorum ($\texttt{attestations.count} \geq Q$),
+3. No other scorecard has been ratified for this game.
+
+### 3.3 Scorecard Lifecycle
+
+Each submitted scorecard passes through five states:
+
+| State | Condition |
+|-------|-----------|
+| **PENDING** | $\texttt{attestationsBegin} > \texttt{block.timestamp}$ |
+| **ACTIVE** | $\texttt{attestationsBegin} \leq \texttt{now} \leq \texttt{gracePeriodEnds}$ |
+| **SUCCEEDED** | Grace period expired AND attestations $\geq$ quorum |
+| **DEFEATED** | A different scorecard was ratified |
+| **RATIFIED** | This scorecard was ratified |
+
+Multiple scorecards may coexist in ACTIVE or SUCCEEDED state simultaneously, but only one can ever be ratified. This creates a competitive dynamic where multiple proposed outcomes compete for attestation support.
+
+### 3.4 Resistance to Strategic Manipulation
+
+The attestation model incorporates several defenses against strategic manipulation:
+
+**Defense 1: Per-tier cap.** No single tier's holders can contribute more than $V_{\text{max}}$ attestation units, regardless of how many tokens they hold. A whale who buys the entire supply of one tier has exactly $V_{\text{max}}$ power — the same as if any single holder held the tier.
+
+**Defense 2: Checkpoint snapshots.** Attestation power is computed at a fixed historical timestamp. Acquiring tokens after the snapshot provides zero additional voting power for that scorecard.
+
+**Defense 3: Mint-phase-only delegation.** Delegation is locked after the mint phase, preventing last-minute delegation changes during the scoring phase.
+
+**Defense 4: 50% quorum across tiers.** Requiring half of all minted tiers' worth of attestation power means that no coalition controlling fewer than half the minted tiers can unilaterally ratify a fraudulent scorecard — even with 100% participation within their controlled tiers.
+
+**Remaining attack surface.** A coalition controlling sufficient attestation power across $\lceil N_{\text{minted}}/2 \rceil$ tiers can ratify an arbitrary scorecard. The critical insight is that attestation power within a tier is *proportional to token holdings*, not absolute. An attacker holding 100% of a tier's supply — even just 1 token — receives the full $V_{\text{max}} = 10^9$ attestation power for that tier.
+
+**Worst-case attack cost (heavily minted tiers).** When all tiers are well-populated, the attacker must acquire majority holdings in at least $\lceil N/2 \rceil$ tiers:
+
+$$C_{\text{attack}}^{\text{worst}} \geq \sum_{i \in \text{majority set}} \left\lceil \frac{n_i + 1}{2} \right\rceil \cdot p_i \tag{26}$$
+
+**Best-case attack cost (sparse tiers).** When some tiers have zero or minimal mints, the attacker can buy 1 token in each unminted tier, becoming the sole holder and receiving full attestation power:
+
+$$C_{\text{attack}}^{\text{best}} = \sum_{i \in \text{cheapest } \lceil N/2 \rceil \text{ unminted tiers}} p_i \tag{26a}$$
+
+This is potentially orders of magnitude cheaper than Eq. 26. In a game with 32 tiers at 0.01 ETH where 16 tiers have zero mints, the attacker spends just $16 \times 0.01 = 0.16$ ETH to meet quorum single-handedly — regardless of pot size. They could then ratify a scorecard directing the entire prize pool to their tokens. **This is the most significant governance vulnerability identified in this analysis** and is discussed further in Section 9.2.
+
+For the attack to be profitable, the attacker must redirect more than $C_{\text{attack}}$ in prize value to their controlled tiers:
+
+$$B_{\text{prize}} > C_{\text{attack}} \cdot \frac{W_{\text{total}}}{\sum_{i \in \text{majority set}} w_i^{\text{proposed}}} \tag{27}$$
+
+For the sparse-tier attack, this condition is almost always satisfied when the pot is nontrivial, making the attack economically rational. Games with broad, uniform participation across all tiers are resistant; games with uneven participation are vulnerable.
+
+---
+
+## 4 Price Dynamics and Value Flows
+
+### 4.1 NFT Intrinsic Value During Minting
+
+During the mint phase, the intrinsic value of a tier-$i$ NFT depends on the holder's subjective probability assessment of the outcomes.
+
+**Expected value at mint.** Let $\pi_i$ be a player's subjective probability that tier $i$ receives scorecard weight $w_i$. The expected post-fee payout for one tier-$i$ NFT is:
+
+$$\mathbb{E}[V_i] = B_{\text{prize}} \cdot \frac{\mathbb{E}[w_i^{\text{token}}]}{W_{\text{total}}} + X_i^{\text{protocol}} \tag{28}$$
+
+where $X_i^{\text{protocol}}$ is the expected protocol token value from burning.
+
+For a binary game (winner-take-all, $N = 2$), this simplifies to:
+
+$$\mathbb{E}[V_i] = \pi_i \cdot \frac{B_{\text{prize}}}{n_i} + X_i^{\text{protocol}} \tag{29}$$
+
+A rational risk-neutral player mints tier $i$ when:
+
+$$\mathbb{E}[V_i] > p_i \tag{30}$$
+
+Substituting:
+
+$$\pi_i > \frac{p_i - X_i^{\text{protocol}}}{B_{\text{prize}} / n_i} \tag{31}$$
+
+This threshold probability decreases as the pot grows (more participants in other tiers create larger prizes for a given probability) and increases as more tokens of tier $i$ are minted (diluting the per-token payout within the tier).
+
+### 4.2 Post-Scorecard Valuation
+
+After the scorecard is ratified and fees are extracted, each NFT has a deterministic value:
+
+**Tier-$i$ token value.** For a single token in tier $i$:
+
+$$V_i^{\text{token}} = \frac{w_i}{\hat{n}_i \cdot W_{\text{total}}} \cdot (B_{\text{prize}} + A_{\text{redeemed}}) + V_i^{\text{protocol}} \tag{32}$$
+
+where $V_i^{\text{protocol}} = \frac{p_i}{M} \cdot (D_{\text{total}} \cdot P_D + P_{\text{total}} \cdot P_P)$ is the protocol-token value, with $P_D$ and $P_P$ being the market prices of $\text{DEFIFA}$ and $\text{BASE\_PROTOCOL}$ tokens respectively.
+
+**Winning tier (full weight).** In a winner-take-all game with $w_j = W_{\text{total}}$:
+
+$$V_j^{\text{token}} = \frac{B_{\text{prize}} + A_{\text{redeemed}}}{\hat{n}_j} + V_j^{\text{protocol}} \tag{33}$$
+
+The winning-tier payout per token is the entire post-fee pot divided by the number of winning-tier tokens.
+
+**Losing tier (zero weight).** When $w_i = 0$:
+
+$$V_i^{\text{token}} = V_i^{\text{protocol}} \tag{34}$$
+
+Losing-tier tokens have zero prize value but retain protocol-token value, providing a non-zero incentive to burn.
+
+### 4.3 Secondary Market Implications
+
+The deterministic valuation after scorecard ratification creates clear secondary-market dynamics:
+
+**Pre-ratification.** NFT value is driven by subjective outcome probabilities. Prices reflect the market's consensus probability-weighted expected payout, analogous to prediction-market shares.
+
+**Post-ratification.** NFT value is deterministic and publicly computable. Any secondary-market price deviating from the redemption value creates an arbitrage:
+- If $P_{\text{market}} < V_i^{\text{token}}$: buy on the market, burn for profit.
+- If $P_{\text{market}} > V_i^{\text{token}}$: never occurs rationally (burn dominates holding).
+
+This means post-ratification secondary markets should converge immediately to redemption value, eliminating any residual price discovery.
+
+---
+
+## 5 Rational Actor Analysis
+
+### 5.1 Mint-Phase Strategy: Entry Timing
+
+**Early minting advantage.** In a fixed-price game, there is no direct price advantage to minting early vs. late within the mint phase (prices are fixed). However, early minters benefit from:
+
+1. **Information asymmetry**: later minters may have better information about the likely outcome, concentrating on winning tiers and diluting per-token payouts within those tiers.
+
+2. **Delegation coordination**: early minters can establish delegation networks, securing attestation influence.
+
+**Late minting advantage.** Late minters benefit from:
+
+1. **Pot observability**: the total pot size and tier distribution are observable on-chain, allowing more informed expected-value calculations.
+
+2. **Implied probability extraction**: the distribution of mints across tiers reveals collective sentiment, analogous to odds in a betting market.
+
+**Equilibrium.** In a Nash equilibrium of the minting game with risk-neutral players, each player mints the tier maximizing their expected payoff. Denoting by $\pi_i$ the true probability of tier $i$ winning and by $f_i = n_i \cdot p_i / B$ the fraction of the pot allocated to tier $i$:
+
+$$\mathbb{E}[\text{return}_i] = \frac{\pi_i}{f_i} \cdot (1 - \phi) - 1 \tag{35}$$
+
+where $\phi = 1/\phi_{\text{defifa}} + 1/\phi_{\text{base}} + \phi_{\text{custom}}$ is the total fee rate.
+
+In equilibrium, expected returns equalize across tiers: $\mathbb{E}[\text{return}_i] = \mathbb{E}[\text{return}_j]$ for all $i, j$ with non-zero minting, which implies:
+
+$$\frac{\pi_i}{f_i} = \frac{\pi_j}{f_j} \quad \Rightarrow \quad f_i = \frac{\pi_i}{\sum_k \pi_k} = \pi_i \tag{36}$$
+
+**Result.** In equilibrium, the fraction of the pot in each tier equals the market's consensus probability of that tier winning. This is the classical parimutuel result: the pot allocation *reveals* the collective probability assessment.
+
+### 5.2 Refund-Phase Strategy: Option Exercise
+
+The refund phase creates a *free put option* on each minted NFT, struck at the mint price.
+
+**Option value.** Let $V_i(t_{\text{refund\_end}})$ be the expected value of a tier-$i$ token at the end of the refund phase. The refund option has value:
+
+$$O_i = \max\left(p_i - V_i(t_{\text{refund\_end}}), \; 0\right) \tag{37}$$
+
+A rational player exercises (refunds) when $V_i(t_{\text{refund\_end}}) < p_i$, which occurs when new information shifts the expected outcome against their chosen tier.
+
+**Strategic implications.** The refund phase serves three purposes:
+
+1. **Risk reduction**: allows players to participate speculatively during the mint phase, with a guaranteed exit if conditions change.
+
+2. **Information revelation**: refund activity signals belief updates. Tiers experiencing heavy refunds are perceived as less likely to win, reinforcing the signal.
+
+3. **Adverse selection mitigation**: the refund phase partially solves the "winner's curse" problem, where early minters in popular tiers may overpay relative to their per-token payout.
+
+**Pot contraction.** Refunds shrink the pot proportionally. If a fraction $\alpha$ of tier-$i$ tokens are refunded, the pot decreases by $\alpha \cdot n_i \cdot p_i$ and tier $i$'s outstanding supply decreases by $\alpha \cdot n_i$. The per-token expected value for remaining tier-$i$ holders *increases* (fewer tokens sharing the same weight), partially offsetting the information content of the refund signal.
+
+### 5.3 Scoring-Phase Strategy: Attestation Delegation
+
+During the scoring phase, the key strategic variable is delegation. Rational players delegate their attestation power to the address most likely to submit and attest to the correct scorecard.
+
+**Default delegation.** Games may specify a `defaultAttestationDelegate` — a trusted address (e.g., the game organizer) whose scorecard proposals are flagged. Players delegating to this address at mint time reduce coordination costs.
+
+**Strategic delegation.** A player holding tokens in tier $i$ has an incentive to delegate to addresses that will attest to scorecards assigning high weight to tier $i$. However, the quorum requirement (50% of minted tiers) means that no single tier's strategy can unilaterally determine the outcome. Scorecards that deviate from the true outcome face the collective opposition of all other tiers' holders.
+
+**Equilibrium.** In the unique subgame-perfect equilibrium of the attestation game (assuming common knowledge of the event outcome):
+
+1. All holders attest to the *truthful* scorecard — the one reflecting the actual event outcome.
+2. The truthful scorecard achieves quorum, as holders of winning tiers have the strongest incentive to attest (they benefit from high weight) and holders of losing tiers are indifferent between truthful scorecards (their weight is zero regardless).
+
+### 5.4 Complete-Phase Strategy: Claim vs Hold
+
+After ratification, holding an NFT rather than burning it has the following payoff profile:
+
+**Burn immediately.** Receive $V_i^{\text{token}} = w_i^{\text{token}} / W_{\text{total}} \cdot (B_{\text{prize}} + A_{\text{redeemed}}) + V_i^{\text{protocol}}$.
+
+**Hold.** The NFT retains the same deterministic value $V_i^{\text{token}}$ indefinitely (the contract imposes no time decay on claims). The only reason to delay is if the player expects the protocol tokens ($\text{DEFIFA}$, $\text{BASE\_PROTOCOL}$) to appreciate in value before claiming.
+
+**Dominant strategy.** For risk-neutral players with positive time preference, burning immediately weakly dominates holding. The claim value does not depreciate (the path-independent formula ensures later claimants receive the same amount), but the time value of money favors immediate realization. Holding is justified only by expected protocol-token appreciation exceeding the discount rate:
+
+$$\frac{dP_D}{dt} \cdot \frac{p_i}{M} \cdot D_{\text{total}} > r \cdot V_i^{\text{token}} \tag{38}$$
+
+where $r$ is the player's discount rate.
+
+---
+
+## 6 Solvency and Conservation Laws
+
+### 6.1 The Conservation Guarantee
+
+A Defifa game satisfies a fundamental conservation property: the total claims available to all NFT holders exactly equal the prize pool, regardless of the order or timing of redemptions.
+
+**Theorem 6.1 (Prize Pool Conservation).** For any scorecard $\mathbf{w}$ with $\sum_i w_i = W_{\text{total}}$ and any sequence of redemptions, the total amount paid out to all NFT holders equals $B_{\text{prize}}$.
+
+*Proof.* The total claim across all tokens is:
+
+$$\sum_{i=1}^{N} n_i^{\text{eligible}} \cdot \frac{w_i}{\hat{n}_i \cdot W_{\text{total}}} \cdot (B_{\text{prize}} + A_{\text{redeemed}})$$
+
+Since $n_i^{\text{eligible}} = \hat{n}_i$ at the start (before any complete-phase redemptions), and the term $(B_{\text{prize}} + A_{\text{redeemed}})$ is invariant (it reconstructs the original pot), this equals:
+
+$$\sum_{i=1}^{N} \frac{w_i}{W_{\text{total}}} \cdot B_{\text{prize}} = \frac{B_{\text{prize}}}{W_{\text{total}}} \sum_{i=1}^{N} w_i = B_{\text{prize}} \quad \square$$
+
+This guarantees that the treasury is exactly drained after all eligible tokens are redeemed — there is no residual and no shortfall.
+
+### 6.2 Solvency Under Sequential Cash-Outs
+
+**Corollary 6.2 (Order Independence).** The payout to any individual NFT holder is independent of the order in which other holders redeem their tokens.
+
+*Proof.* The per-token claim formula (Eq. 14) uses $(B_{\text{prize}} + A_{\text{redeemed}})$ as the reference pot, which is constant regardless of how many tokens have been redeemed. The denominator $\hat{n}_i$ adjusts via the $d_i$ (tokens redeemed from tier $i$) counter, but the per-token weight formula $w_i / \hat{n}_i$ uses the *original* eligible count (at scorecard ratification), not the current count. The Solidity implementation achieves this by tracking `tokensRedeemedFrom[tierId]` and subtracting from the denominator:
+
+$$\hat{n}_i = n_i^{\text{minted}} - n_i^{\text{remaining}} - (n_i^{\text{burned}} - d_i) \tag{39}$$
+
+As each token is redeemed, both $n_i^{\text{burned}}$ and $d_i$ increment by 1, leaving $\hat{n}_i$ invariant. Therefore, each token receives the same payout regardless of when it is redeemed. $\square$
+
+### 6.3 Fee Impact on Total Claimable Value
+
+The total value available to players (prize + protocol tokens) is:
+
+$$V_{\text{total}} = B_{\text{prize}} + V_{\text{protocol}} = B_{\text{pot}} \cdot (1 - \phi) + V_{\text{protocol}} \tag{40}$$
+
+where $V_{\text{protocol}}$ is the market value of protocol tokens allocated to the game. With default fees ($\phi = 10\%$):
+
+$$V_{\text{total}} = 0.9 \cdot B_{\text{pot}} + V_{\text{protocol}} \tag{41}$$
+
+Whether the net present value exceeds the mint cost depends on whether $V_{\text{protocol}} > 0.1 \cdot B_{\text{pot}}$ — i.e., whether protocol token value compensates for the fee extraction. This creates a circular dependency: protocol token value derives from the aggregate fees across all games, which depends on game volume, which depends on expected player returns, which depends on protocol token value. We analyze this flywheel in Section 7.3.
+
+---
+
+## 7 Game-Theoretic Properties
+
+### 7.1 Defifa as a Parimutuel Mechanism
+
+Defifa implements a *generalized parimutuel mechanism* with several distinctive features compared to traditional parimutuel systems:
+
+| Property | Traditional Parimutuel | Defifa |
+|----------|----------------------|--------|
+| Outcome resolution | Centralized oracle | Decentralized attestation |
+| Payout computation | House-computed odds | On-chain formula |
+| Fee structure | Fixed takeout rate | Split-based, configurable |
+| Asset type | Fungible bet tickets | Non-fungible ERC-721 tokens |
+| Secondary market | Typically none | Full ERC-721 transferability |
+| Refund option | Typically none | Configurable refund phase |
+| Token rewards | None | Protocol token distribution |
+
+**Parimutuel equivalence.** Under the following conditions, a Defifa game is equivalent to a classical parimutuel pool:
+- All tiers have the same price ($p_i = p$ for all $i$),
+- The scorecard is binary (one winning tier gets $W_{\text{total}}$, all others get 0),
+- No refund phase.
+
+In this case, the odds implied by the pot distribution match classical parimutuel odds:
+
+$$\text{odds}_i = \frac{B_{\text{prize}}}{n_i \cdot p} = \frac{(1 - \phi) \cdot \sum_k n_k}{n_i} \tag{42}$$
+
+### 7.2 Information Aggregation
+
+The minting and refund dynamics of Defifa create a multi-round price-discovery mechanism:
+
+**Round 1 (Mint phase).** Players reveal information through tier selection. Under the equilibrium result from Section 5.1, the pot distribution converges to the collective probability distribution.
+
+**Round 2 (Refund phase).** Players who received new information can exit, and the refund pattern reveals belief updates. The post-refund pot distribution reflects updated probability assessments.
+
+**Round 3 (Secondary market).** If NFTs trade on secondary markets during the scoring phase, prices reflect the most current probability assessments, including information arriving after minting closes.
+
+This three-round structure is informationally richer than single-shot betting mechanisms, as it allows for belief revision without the sunk-cost problem (thanks to the refund option).
+
+### 7.3 Multi-Game Dynamics and Protocol Flywheel
+
+Defifa generates a *protocol-level flywheel* through its fee-token mechanism:
+
+1. **Game fees** → minted to protocol projects as payments,
+2. **Protocol tokens** are issued to the game hook,
+3. **Players claim protocol tokens** upon burning NFTs,
+4. **Protocol token value** reflects aggregate fee revenue across all games,
+5. **Higher token value** → higher expected returns for players → more game participation → more fees.
+
+**Flywheel dynamics.** Let $G$ be the number of active games, $\bar{B}$ the average pot size, and $\phi$ the fee rate. The aggregate fee revenue is:
+
+$$R = G \cdot \bar{B} \cdot \phi \tag{43}$$
+
+If protocol token value is a multiple $\mu$ of aggregate revenue: $V_{\text{token}} = \mu \cdot R$, then the protocol token allocation per game is approximately:
+
+$$V_{\text{protocol}}^{\text{game}} \approx \frac{\bar{B} \cdot \phi}{\bar{B}} \cdot V_{\text{token}} = \phi \cdot \mu \cdot G \cdot \bar{B} \cdot \phi \tag{44}$$
+
+The fraction of the pot recovered through protocol tokens is:
+
+$$\frac{V_{\text{protocol}}^{\text{game}}}{\bar{B}} = \phi^2 \cdot \mu \cdot G \tag{45}$$
+
+This shows that the protocol-token recovery rate increases linearly with the number of games $G$ and the revenue multiple $\mu$. For $\phi = 0.1$, $\mu = 10$, and $G = 100$:
+
+$$\frac{V_{\text{protocol}}^{\text{game}}}{\bar{B}} = 0.01 \cdot 10 \cdot 100 = 10$$
+
+In this (illustrative) regime, protocol tokens would be worth 10x the pot — making Defifa games a *net-positive expected value* activity. While this extreme scenario is unlikely at scale, it demonstrates the directional incentive: more games create more protocol token value, which attracts more players.
+
+---
+
+## 8 Parameter Design Space
+
+### 8.1 Tier Count and Price Calibration
+
+**Tier count.** The number of tiers $N$ affects:
+
+- **Quorum difficulty**: $Q = (N_{\text{minted}} / 2) \cdot V_{\text{max}}$. More tiers require more attestation weight, increasing governance robustness but potentially slowing ratification.
+- **Per-tier dilution**: In a winner-take-all game, the winning tier's payout is diluted only by the number of tokens in that tier, not by total tiers. However, more tiers spread the pot thinner in proportional-split scorecards.
+- **Attack cost**: More tiers increase the cost of majority control (Eq. 26).
+
+**Optimal regime**: $4 \leq N \leq 32$ tiers balances governance tractability with outcome granularity. Beyond 32 tiers, quorum coordination becomes challenging; below 4, the game reduces to a coin flip with limited appeal.
+
+**Price calibration.** Tier prices affect:
+
+- **Accessibility**: Lower prices attract more participants but increase gas costs relative to the bet size.
+- **Pot concentration**: Uniform pricing ($p_i = p$) creates a clean parimutuel pool where pot fractions equal minting fractions. Non-uniform pricing allows odds-adjustment at design time (e.g., favorites priced higher).
+- **Attack economics**: Higher prices increase the cost of acquiring majority positions for attestation manipulation.
+
+**Recommendation**: Uniform pricing between 0.01 and 1 ETH per NFT provides a balance between accessibility, gas efficiency, and attack resistance for most games.
+
+### 8.2 Timing Parameters
+
+**Mint duration** ($t_{\text{mint}}$): Should be long enough for information dissemination and participation growth, but short enough to maintain urgency. For event-based games:
+
+$$t_{\text{mint}} \approx \min(\text{time until event}, \; 30 \text{ days}) \tag{46}$$
+
+**Refund duration** ($t_{\text{refund}}$): Creates optionality value. Longer refund periods increase the option value for minters but may reduce pot stability (more uncertainty about final pot size). A refund period of 1–7 days provides meaningful optionality without excessive uncertainty.
+
+**Attestation start time** ($\tau_{\text{attest}}$): Delay between scorecard submission and voting activation. Longer delays give more holders time to prepare delegations and review scorecards. Recommended: 1–24 hours.
+
+**Attestation grace period** ($\tau_{\text{grace}}$): Duration of the voting window. Must be long enough for broad participation but short enough to deliver results promptly. Recommended: 1–7 days.
+
+### 8.3 Fee Calibration and Protocol Sustainability
+
+The default fee structure (5% Defifa + 5% base protocol = 10% total) is competitive with:
+
+| Platform | Takeout Rate |
+|----------|-------------|
+| Horse racing (parimutuel) | 15–25% |
+| Sports betting (vig) | 4–10% |
+| Prediction markets (fees) | 1–5% |
+| **Defifa (default)** | **10%** |
+
+The 10% rate positions Defifa between traditional parimutuel systems and modern prediction markets. The key differentiation is the *protocol token rebate*: while the 10% is extracted as fees, a portion returns to players as protocol tokens, making the effective fee rate lower than the nominal rate.
+
+**Effective fee rate.** If protocol tokens retain $\alpha$ fraction of their fee value:
+
+$$\phi_{\text{eff}} = \phi \cdot (1 - \alpha) \tag{47}$$
+
+For $\alpha = 0.5$ (protocol tokens retain 50% of their minting value): $\phi_{\text{eff}} = 0.10 \cdot 0.5 = 5\%$, competitive with low-fee prediction markets.
+
+---
+
+## 9 Open Problems and Mechanism Design Recommendations
+
+The formal analysis in Sections 2–8 reveals several structural properties of the Defifa mechanism that merit attention. This section catalogs open problems discovered through systematic code review and game-theoretic analysis, ordered by severity, and proposes concrete protocol-level mitigations.
+
+### 9.1 Governance Deadlock and Fund Recovery: A Deep Study
+
+**Severity: Significant (design consideration).**
+
+#### 9.1.1 Historical Context
+
+The original Defifa (Juicebox V3 era) included `NO_CONTEST` and `NO_CONTEST_INEVITABLE` phases. In V3, each game phase had to be manually advanced by calling `queueNextPhaseOf()`. If nobody called this function before a funding cycle "rolled over" (repeated instead of advancing to the next phase), the `_noContestInevitable()` check detected the rollover and `_queueNoContest()` reconfigured the project for permanent full-price refunds (duration = 0, cashOutTaxRate = 0, pausePay = true). The V5 port pre-queues all rulesets at launch, eliminating the rollover risk — but also eliminating the *sole trigger* for no-contest. The dead enum values and handler code were removed as part of the V5 cleanup (see AUDIT\_FINDINGS L-D5).
+
+This section formally analyzes whether a new form of no-contest should be reintroduced, what triggers and parameters would be needed, and whether the existing mechanisms are sufficient.
+
+#### 9.1.2 Exhaustive Deadlock Scenario Analysis
+
+We identify five distinct scenarios in which game funds could become permanently inaccessible:
+
+**Scenario A: No scorecard submitted.** The game reaches SCORING. Nobody calls `submitScorecardFor()`. All tier cash-out weights remain zero. The `beforeCashOutRecordedWith` hook returns `cashOutCount = 0` for any cash-out attempt (since weight = 0), and `afterCashOutRecordedWith` reverts with `NOTHING_TO_CLAIM` because `reclaimedAmount.value == 0`. Funds remain in the Juicebox treasury indefinitely.
+
+**Scenario B: Scorecard submitted, quorum unreachable.** A scorecard exists but attestation power is fragmented. No single scorecard accumulates 50% of eligible attestation weight. The governor's `stateOf()` returns `ACTIVE` indefinitely (it never transitions to `DEFEATED` — there is no expiry on attestation). The game remains in SCORING with no mechanism to break the stalemate.
+
+**Scenario C: Default attestation delegate is inaccessible.** The `defaultAttestationDelegate` is set to a contract that cannot execute transactions, or to a lost EOA. Since delegation can only be changed during the MINT phase (`_update` enforces `DELEGATE_CHANGES_UNAVAILABLE_IN_THIS_PHASE` after MINT), the accumulated attestation power is irrecoverably locked. Even if other participants want to coordinate, the delegate holds the majority of attestation units with no way to reclaim them.
+
+**Scenario D: Attestation power in dead addresses.** If >50% of game pieces are transferred to contracts that cannot call `attestToScorecardFrom()`, the exercisable attestation power drops below quorum permanently. This is distinct from Scenario C because the delegation may be correct but the delegatees are inaccessible.
+
+**Scenario E: Split target reverts on ratification.** `ratifyScorecardFrom()` calls `fulfillCommitmentsOf()`, which calls `sendPayoutsOf()`. If a split target is a reverting contract, the entire ratification transaction fails. The scorecard reached SUCCEEDED state in the governor, but the on-chain execution of `setTierCashOutWeightsTo` never completes. The game is stuck in SCORING despite having a governance-approved outcome.
+
+| Scenario | Funds stuck? | Delegate resolves? | Automated resolution? |
+|:---------|:------------:|:------------------:|:---------------------:|
+| A: No scorecard | Yes | Yes, if active | No |
+| B: Quorum unreachable | Yes | Yes, if has power | No |
+| C: Dead delegate | Yes | No | No |
+| D: Dead attestation holders | Yes | No | No |
+| E: Split target reverts | Yes | No | No |
+
+Note: the case where *all* minters refund during REFUND is not a deadlock — the treasury balance drops to zero and there are no funds to recover.
+
+#### 9.1.3 Effectiveness of the `defaultAttestationDelegate`
+
+The `defaultAttestationDelegate` is the protocol's primary soft mitigation against governance deadlock. When set, every minter who does not specify a custom delegate has their attestation units delegated to this address. If no minter re-delegates, the delegate holds 100% of attestation power across all minted tiers — easily exceeding the 50% quorum.
+
+The delegate can:
+1. Submit a scorecard via `submitScorecardFor()`
+2. Attest to it via `attestToScorecardFrom()`
+3. Once quorum is met, anyone can call `ratifyScorecardFrom()` to execute
+
+This resolves Scenarios A and B in the common case. However, it provides no hard guarantee because it depends on four assumptions:
+
+1. **The delegate is set.** It is an optional parameter; `address(0)` is valid.
+2. **The delegate remains operational.** Multi-sigs lose keys; DAOs cease operating; EOAs get lost.
+3. **The delegate acts honestly.** A delegate could submit a self-serving scorecard and self-ratify, stealing the entire pot. Participants have no recourse except to not play games with untrusted delegates.
+4. **Minters do not re-delegate.** During the MINT phase, any minter can change their delegation, reducing the delegate's power.
+
+**Conclusion:** The delegate is an excellent first line of defense but is insufficient as a sole guarantee. It is a trusted, social mechanism — not a trustless, automated one. For permissionlessly created games with untrusted or absent organizers, the delegate provides no assurance.
+
+#### 9.1.4 Candidate Mechanism A: Minimum Participation Threshold
+
+**Concept.** At game initialization, the organizer sets `minParticipation` — a minimum treasury balance required for the game to proceed past REFUND to SCORING. If the balance is below this threshold when SCORING would begin, the game enters a no-contest state where cash-outs return mint prices.
+
+**Implementation.** One new `uint256` in the game's ops data. The `currentGamePhaseOf()` view function checks the treasury balance against the threshold before returning SCORING. Cash-out handling reuses the existing MINT/REFUND refund path (returning `_cumulativeMintPrice`). No new rulesets or state transitions are required — the no-contest state is computed purely from the view function.
+
+**What it solves.** Ghost games with negligible participation skip directly to refundability without requiring any governance action. This is the simplest and most targeted safety net.
+
+**What it does not solve.** If a game exceeds the threshold but governance subsequently deadlocks (Scenarios B–E), the threshold provides no help. It is purely a pre-scoring safety valve.
+
+**Attack surface.** An adversary who wants to force no-contest can refund enough tokens to push the balance below the threshold. If they hold a majority position, they can unilaterally kill the game. Mitigation: set the threshold conservatively low relative to expected participation (e.g., 10% of the maximum expected pot).
+
+**Design consideration.** The threshold is set at launch before any minting occurs, so calibration depends on organizer judgment. A threshold that is too high risks triggering no-contest in a moderately successful game; too low and it only catches completely abandoned games.
+
+#### 9.1.5 Candidate Mechanism B: Scorecard Ratification Timeout
+
+**Concept.** At game initialization, the organizer sets `scorecardTimeout` — a duration (in seconds) after the SCORING phase begins. If no scorecard is ratified within this window, the game enters a no-contest state where cash-outs return mint prices.
+
+**Implementation.** One new `uint256` in the game's ops data. The `currentGamePhaseOf()` view function checks `block.timestamp > scoringRulesetStart + scorecardTimeout` before returning SCORING. If the timeout has passed and `cashOutWeightIsSet` is still false, return a no-contest state.
+
+**What it solves.** All five deadlock scenarios (A–E). This is the only mechanism that provides a hard, trustless, time-bounded guarantee that funds cannot be locked permanently. Regardless of delegate failures, governance fragmentation, or operational issues, every game eventually becomes refundable.
+
+**Interaction with the governor.** Several sub-cases:
+
+- *No scorecard submitted before timeout:* Clean. Game enters no-contest. Refunds at mint price.
+- *Scorecard partially attested, quorum not met:* Game enters no-contest. The scorecard's governor state remains ACTIVE, but `setTierCashOutWeightsTo` is unreachable (it requires SCORING phase, which no longer holds). The scorecard effectively expires.
+- *Scorecard reaches SUCCEEDED but not yet ratified:* This is the critical edge case. A community-approved scorecard exists but nobody called `ratifyScorecardFrom()` in time. The timeout converts it to no-contest, invalidating a valid governance outcome. **Mitigation:** either (a) set timeouts generously (90–180 days), or (b) add a "ratification grace period" — a short window after the main timeout during which a SUCCEEDED scorecard can still be ratified.
+- *Competing scorecards, none reaching quorum:* Governance couldn't resolve. No-contest is the correct outcome.
+
+**Attack surface.** Minimal. An adversary cannot accelerate the timeout. The only strategic concern is that a timeout creates a deadline effect: participants near the timeout boundary may rush governance, reducing deliberation quality. Long timeouts (90+ days) mitigate this.
+
+**Design consideration.** A protocol-level minimum timeout (e.g., 30 days) could prevent game creators from setting absurdly short values that effectively make games unresolvable. A default value of 0 (disabled) preserves backward compatibility.
+
+#### 9.1.6 Do We Need a NO_CONTEST State?
+
+The fundamental question is whether the `NO_CONTEST` enum value and its associated handler code should be reintroduced, or whether the existing phase system is sufficient.
+
+**Arguments for reintroduction:**
+- Provides a clean, named state that UIs and indexers can unambiguously identify
+- The existing handler code (`beforeCashOutRecordedWith` returning `_cumulativeMintPrice`) is the correct behavior for no-contest refunds
+- The `DefifaTokenUriResolver` can display clear messaging to NFT holders
+
+**Arguments against reintroduction:**
+- Both candidate mechanisms can be implemented as *computed states* in the `currentGamePhaseOf()` view function, requiring no on-chain state transition
+- The no-contest behavior (mint-price refund) is identical to the REFUND phase behavior, so no new handler logic is needed — the existing MINT/REFUND cash-out path already returns `_cumulativeMintPrice`
+- Adding another enum value increases the state space that every consumer (UIs, indexers, other contracts) must handle
+- The V3 NO\_CONTEST required a destructive reconfiguration (`_queueNoContest`). The V5 approach is purely a view-level computation — no treasury reconfiguration is needed because the SCORING ruleset already has `cashOutTaxRate = 0` and `pausePay = true`, which are the correct parameters for refunds
+
+**Recommendation.** The no-contest behavior should be reintroduced as a *computed phase* — not a stored state. The `currentGamePhaseOf()` view function should return a no-contest indicator when the threshold or timeout conditions are met, and the cash-out handler should treat this identically to the REFUND phase. This preserves the simplicity of the V5 architecture (no on-chain state transitions beyond the pre-queued rulesets) while providing the safety guarantees that the original V3 design intended.
+
+#### 9.1.7 Assessment and Recommendation
+
+The `defaultAttestationDelegate` provides a strong first line of defense and will resolve the vast majority of governance deadlocks in practice. For games with trusted organizers and active communities, it is likely sufficient.
+
+However, the protocol aspires to permissionless, trustless game creation. For this use case, a hard guarantee is essential. We recommend:
+
+1. **Scorecard ratification timeout** (Mechanism B) as the primary safety mechanism. It is the only approach that covers all five deadlock scenarios with a single, trustless, time-bounded guarantee. Implementation cost: one `uint256`, one timestamp comparison. The timeout should be generous (recommended default: 90 days) with an optional ratification grace period (7 days) for SUCCEEDED scorecards.
+
+2. **Minimum participation threshold** (Mechanism A) as an optional, complementary safety net. It provides early termination for obviously non-viable games, improving UX by avoiding a long SCORING → timeout wait for games that never attracted meaningful participation. Implementation cost: one `uint256`, one balance check.
+
+3. Both mechanisms should be **optional** (default: disabled, value = 0) to preserve backward compatibility and support use cases where the organizer explicitly desires open-ended scoring.
+
+4. The game should **remain fully playable without either mechanism** — they are safety nets, not requirements. A game with no threshold and no timeout functions exactly as today, relying on the delegate and community coordination. The mechanisms add optionality for risk-averse game designers, not complexity for all games.
+
+The combination of `defaultAttestationDelegate` (fast-path social resolution) + `scorecardTimeout` (hard backstop) + `minParticipation` (early exit for ghost games) provides defense in depth where each mechanism covers the failure modes of the others.
+
+### 9.2 Cheap Cross-Tier Attestation Capture
+
+**Severity: Critical.**
+
+As identified in the corrected attack cost analysis (Section 3.4, Eq. 26a), the per-tier attestation power cap creates an unintended vulnerability in games with uneven participation. The mechanism assigns equal maximum attestation power ($V_{\text{max}} = 10^9$) to every tier *regardless of its minted supply*. A tier with 1 token has the same governance weight as a tier with 10,000 tokens.
+
+**The attack.** An adversary identifies $\lceil N/2 \rceil$ tiers with zero or minimal mints (typically obscure/unlikely outcomes). They purchase 1 token in each, becoming the sole holder and receiving full $V_{\text{max}}$ attestation power per tier. Their total attestation power:
+
+$$A_{\text{attacker}} = \lceil N/2 \rceil \cdot V_{\text{max}} \geq Q = \frac{N_{\text{minted}}}{2} \cdot V_{\text{max}}$$
+
+The attacker meets quorum unilaterally. They then submit a scorecard assigning $W_{\text{total}}$ to one of their tiers and ratify it.
+
+**Numerical example.** A 32-tier sports game at 0.01 ETH per token. Popular tiers (say 16 NFL teams) accumulate 1,000 tokens each. The remaining 16 tiers receive no organic mints. The attacker buys 1 token in each of the 16 empty tiers for 0.16 ETH total. They can now ratify a scorecard directing the entire prize pool ($\sim$144 ETH after fees) to a single tier they hold. **Return on investment: $\sim$900x.**
+
+**Root cause.** The quorum function counts *any tier with nonzero supply* as eligible, giving each equal weight. This conflates "a tier that represents meaningful community participation" with "a tier that a single actor created a position in."
+
+**Recommended fix.** Introduce a minimum supply threshold for quorum eligibility:
+
+$$Q = \frac{1}{2} \sum_{i=1}^{N} \mathbb{1}\left[n_i \geq n_{\text{min}}\right] \cdot V_{\text{max}}$$
+
+where $n_{\text{min}} \geq 2$ (or better, a configurable parameter). Alternatively, weight each tier's attestation power by a concave function of its supply, such as $\min(V_{\text{max}}, \; \sqrt{n_i} \cdot V_{\text{max}} / \sqrt{n_{\text{ref}}})$, which provides sublinear scaling that resists both single-token capture and whale dominance.
+
+### 9.3 Prize Pool Under-Allocation
+
+**Severity: Significant.**
+
+The weight validation in `setTierCashOutWeightsTo` (`DefifaHook.sol:643`) uses a strict greater-than check:
+
+```solidity
+if (_cumulativeCashOutWeight > TOTAL_CASHOUT_WEIGHT) revert INVALID_CASHOUT_WEIGHTS();
+```
+
+A scorecard with weights summing to *less than* $W_{\text{total}}$ passes this check. The total distributed to all players is then:
+
+$$\text{Total payouts} = B_{\text{prize}} \cdot \frac{\sum_i w_i}{W_{\text{total}}} < B_{\text{prize}}$$
+
+The difference $B_{\text{prize}} \cdot \left(1 - \frac{\sum_i w_i}{W_{\text{total}}}\right)$ remains permanently trapped in the treasury. This breaks the conservation guarantee of Theorem 6.1, which assumes $\sum_i w_i = W_{\text{total}}$.
+
+**Strategic exploitation.** A coalition controlling quorum could propose a scorecard where their tiers receive generous weights but the total is intentionally less than $W_{\text{total}}$. The "burned" fraction harms all participants equally, but the coalition benefits disproportionately from the redistributed portion. This is preferable for them when the alternative is sharing with non-coalition tiers.
+
+**Recommended fix.** Change the check to exact equality:
+
+```solidity
+if (_cumulativeCashOutWeight != TOTAL_CASHOUT_WEIGHT) revert INVALID_CASHOUT_WEIGHTS();
+```
+
+This restores the conservation guarantee of Theorem 6.1 unconditionally.
+
+### 9.4 Attestation Timing Misconfiguration
+
+**Severity: Significant.**
+
+In `submitScorecardFor`, both `attestationsBegin` and `gracePeriodEnds` are computed relative to `block.timestamp` at submission time — not relative to each other:
+
+```solidity
+_scorecard.attestationsBegin = uint48(block.timestamp + _timeUntilAttestationsBegin);
+_scorecard.gracePeriodEnds = uint48(block.timestamp + attestationGracePeriodOf(_gameId));
+```
+
+If `attestationGracePeriod < attestationStartTime`, the grace period expires *before attestations even begin*. The `stateOf` function then transitions from PENDING directly past the grace period check, creating a zero-length effective attestation window. Additionally, `initializeGame` performs no validation on the relationship between these parameters.
+
+**Impact.** A misconfigured game — whether through error or intentional parameter choice — could have its scorecard ratified with no effective attestation window, bypassing the governance protections that Sections 3.1–3.4 assume.
+
+**Recommended fix.** Compute `gracePeriodEnds` relative to `attestationsBegin`:
+
+$$t_{\text{grace\_end}} = t_{\text{attest\_begin}} + \tau_{\text{grace}}$$
+
+Or equivalently, validate in `initializeGame` that `attestationGracePeriod >= attestationStartTime`.
+
+### 9.5 Pre-Scoring Scorecard Submission
+
+**Severity: Moderate.**
+
+The `submitScorecardFor` function contains no check on the current game phase. Scorecards can be submitted and accumulate attestations during the MINT phase — before the underlying event has even occurred. While `setTierCashOutWeightsTo` does enforce the SCORING phase for weight application, the ability to pre-accumulate attestations means a well-coordinated group can achieve SUCCEEDED state before scoring opens, then ratify instantly when it does.
+
+This front-running advantage is particularly pronounced for the `defaultAttestationDelegate`, whose submissions are flagged and likely to attract delegation during the mint phase. In the worst case, a game's outcome could be decided by governance before the real-world event even starts, if the delegate's scorecard reaches quorum during minting.
+
+**Recommended fix.** Add a phase check in `submitScorecardFor`:
+
+```solidity
+if (gamePhaseReporter.currentGamePhaseOf(_gameId) != DefifaGamePhase.SCORING) {
+    revert NOT_ALLOWED();
+}
+```
+
+### 9.6 Fee Extraction Fragility
+
+**Severity: Moderate.**
+
+In `fulfillCommitmentsOf` (`DefifaDeployer.sol:439–445`), the function calls `sendPayoutsOf` with `minTokensPaidOut` set to the full treasury balance:
+
+```solidity
+_terminal.sendPayoutsOf({
+    projectId: _gameId,
+    token: _token,
+    amount: _pot,
+    currency: ...,
+    minTokensPaidOut: _pot
+});
+```
+
+The split structure routes fees (~10%) to protocol projects and returns the remainder (~90%) back to the game treasury via `addToBalanceOf`. If `sendPayoutsOf` interprets `minTokensPaidOut` as the minimum that permanently leaves the project (rather than the total processed), this transaction will revert — because only ~10% actually leaves. This would permanently block fee extraction and game completion, trapping all funds.
+
+**Recommended fix.** Set `minTokensPaidOut` to 0 or to the expected fee amount (i.e., `_pot / baseProtocolFeeDivisor + _pot / defifaFeeDivisor`). This preserves the economic intent while removing the revert risk.
+
+---
+
+## 10 Conclusions and Practical Implications
+
+This paper has formalized the cryptoeconomic mechanisms of Defifa: a prediction-game protocol that transforms NFT minting into a parimutuel wagering mechanism with governance-ratified outcomes. Through mathematical analysis of the minting, refund, scorecard, and prize distribution operations, we have derived conservation guarantees, characterized equilibrium behavior, analyzed governance security, and mapped the parameter design space.
+
+### Prize Distribution Mechanics
+
+Defifa implements a *path-independent, weight-proportional* prize distribution through Equation 14. The key insight is the use of $(B_{\text{prize}} + A_{\text{redeemed}})$ as the reference pot: by reconstructing the original post-fee pot rather than using the current balance, the protocol ensures that every token holder receives the same payout regardless of redemption order. Theorem 6.1 proves that the total payout across all holders exactly exhausts the prize pool, with no residual or shortfall.
+
+The scorecard weight system ($\sum w_i = 10^{18}$) provides a flexible framework for expressing arbitrary outcome distributions: winner-take-all, proportional splits, partial credit, or any mixture. The per-token weight formula (Eq. 12) correctly adjusts for tier size, ensuring that a tier's total claim equals its weight fraction of the pot regardless of how many tokens were minted in that tier.
+
+### Governance Security
+
+The attestation model (Section 3) achieves a balance between decentralization and efficiency. The per-tier cap on attestation power ($V_{\text{max}} = 10^9$) prevents any single tier from dominating governance, while the 50% quorum across minted tiers ensures broad participation. The checkpoint-based snapshot prevents vote-buying, and mint-phase-only delegation prevents last-minute manipulation.
+
+However, Section 9 identifies a critical governance vulnerability: cheap cross-tier attestation capture (9.2), where an attacker buying 1 token in each of $N/2$ unpopular tiers can unilaterally meet quorum. The corrected attack cost (Eq. 26a) shows that governance security depends not just on tier count and prices, but critically on participation uniformity across tiers. The deep study in Section 9.1 identifies five distinct deadlock scenarios and evaluates two candidate safety mechanisms (participation thresholds and ratification timeouts), concluding that both are valuable optional additions but that the existing system remains fully playable without them when games have active organizers and trusted delegates.
+
+### Market Efficiency
+
+The equilibrium analysis (Section 5.1) demonstrates that Defifa games converge to the classical parimutuel result: pot fractions equal consensus probabilities. The three-round information structure (mint → refund → secondary) provides richer information aggregation than single-shot mechanisms, with the refund phase serving as a particularly elegant solution to the adverse-selection problem in prediction markets.
+
+### Protocol Sustainability
+
+The fee-token flywheel (Section 7.3) creates a positive feedback loop between game volume and protocol token value. While the flywheel dynamics are inherently circular, the directional incentive is clear: more games → more fees → higher protocol token value → lower effective fee rates → more attractive games → more participation. The critical mass required to activate this flywheel depends on aggregate fee revenue relative to protocol token market capitalization.
+
+### Practical Recommendations
+
+For game designers deploying Defifa games:
+
+1. **Tier count**: 4–32 tiers balances governance security with outcome expressiveness.
+2. **Pricing**: Uniform pricing between 0.01–1 ETH provides the cleanest parimutuel dynamics.
+3. **Refund phase**: 1–7 days gives meaningful optionality without excessive pot instability.
+4. **Attestation**: A trusted default delegate reduces coordination costs; 24-hour attestation start delay and 3-day grace period balance speed with security. Ensure `attestationGracePeriod >= attestationStartTime` (Section 9.4).
+5. **Fees**: The default 10% split (5% Defifa + 5% base protocol) is competitive; additional organizer splits should not exceed 5% to keep effective rates under 15%.
+6. **Participation uniformity**: Ensure all tiers attract meaningful participation to resist cheap governance capture (Section 9.2). Consider minimum-supply quorum thresholds.
+7. **Deadlock protection**: For permissionless games, set a scorecard ratification timeout (90–180 days recommended) and optionally a minimum participation threshold. For trusted-organizer games, the `defaultAttestationDelegate` is sufficient (Section 9.1).
+
+### Synthesis
+
+Defifa implements a rigorous approach to prediction gaming through the composition of three well-understood mechanisms: parimutuel pooling for price formation, attestation governance for outcome resolution, and Juicebox V5 for treasury management. The mathematical analysis confirms that the system conserves value and converges to informationally efficient equilibria. The protocol token layer adds a novel incentive dimension that aligns participant, organizer, and protocol interests around game volume growth.
+
+The open problems identified in Section 9 — particularly the cheap cross-tier attestation capture (9.2) and prize pool under-allocation (9.3) — represent the most important areas for protocol hardening before production deployment at scale. The recommended mitigations (minimum-supply quorum thresholds, exact weight validation) are backwards-compatible and address the identified vulnerabilities without altering the core mechanism design. The deep study of governance deadlock (9.1) confirms that the existing architecture is sound — the `defaultAttestationDelegate` resolves the majority of practical deadlocks — but that optional safety mechanisms (ratification timeout, participation threshold) provide valuable defense in depth for permissionless deployment without adding mandatory complexity.
+
+The elegance of Defifa resides in its architectural composability: prediction games with arbitrary outcomes, arbitrary tier structures, and arbitrary payout distributions emerge from the same set of seven parameters (Eq. 1), executed deterministically by immutable smart contracts with a single, time-bounded governance input. The game remains fully playable and efficient without additional states — the proposed safety mechanisms are optional parameters that expand the design space for risk-averse game creators while preserving the protocol's minimalist architecture for those who prefer it.