LAUNCHPAD.FAIL Pink Paper:
Token Distribution, Rewards, and Launch Economy

1  Introduction

Token launches are usually described as discrete events: a project creates a token, seeds liquidity, opens a sale or bonding curve, and distributes allocations. In practice, a launch is not one event. It is an evolving economic system involving liquidity, reward emissions, team unlocks, participant incentives, governance, community missions, vesting, and circulating supply management.

LPF introduces a launch model in which the token distribution is interactive. Participants acquire or commit a project token amount, enter verifiable launch rounds, and receive allocations according to public game rules. The White Paper defines the fairness and settlement layer; this Pink Paper defines the economic layer around that protocol. The core idea is that a launch can combine: token acquisition; interactive game-based allocation; a transparent protocol edge; explicit loss routing; reward vaults; seasonal campaigns; liquidity backstops; vesting and locks; milestone-based unlocks; governance controls; and project-level launch dashboards. This design is not limited to FUEL — FUEL is the reference deployment, and the framework supports any compatible project token \(T_i\).

1.1  Design objectives

The economic design has five objectives. Firstly, it should make token distribution more engaging than passive purchase flows. Secondly, it should keep the allocation math transparent: the protocol edge, loss routing, reward boosts, vesting, and unlock logic are all defined explicitly. Thirdly, it should make the project launch configuration visible — a project should understand where its supply is allocated, how much has been claimed, what remains locked, and how reward vaults are being used. Fourthly, it should acknowledge reflexive market dynamics: participants may buy through a pool, win allocations from a vault, and later sell into the same market; this is not a hidden side effect but a part of the launch economy which must be modeled. Fifthly, it should separate core fairness from economic configuration: the state-channel fairness model decides whether a round result is valid, and the Pink Paper decides how valid allocations are funded, boosted, vested, locked, and governed.

2  System Overview

The LPF economic system consists of nine modules: (1) Launch Configuration — supply buckets, launch parameters, reward vaults, vesting schedules, governance settings; (2) Liquidity Acquisition — converts a quote asset \(Q\) such as SOL into the project token \(T_i\); (3) Game Distribution — allocates supply through interactive launch rounds; (4) Protocol Edge — accounts for the expected-value margin and directs it to configured uses; (5) Reward and Season — missions, leaderboards, boosts, periodic campaigns; (6) Vesting and Lock — time-based, milestone-based, or governance-controlled unlocks; (7) Backstop and Solvency — tracks liabilities and ensures vaults can support claims; (8) Governance and Curation — controls launch parameters, milestone approvals, reward schedules; (9) Dashboard and Accounting — project-level and participant-level views.

The economic flow can be summarized as

\[Q \rightarrow T_i \rightarrow b \rightarrow A \rightarrow C_P(t),\]

where \(Q\) is the quote asset, \(T_i\) the project token, \(b\) the escrowed round amount, \(A\) the resulting gross allocation, and \(C_P(t)\) the participant's claimable amount over time. On the losing branch, the flow continues \(b\rightarrow\) loss route (§5.3), which is where the economy's largest inflow lives.

3  Token Supply Allocation Model

Let \(S_i\) denote the total supply of \(T_i\). LPF models supply as configurable buckets:

\[S_i=S_{\text{team}}+S_{\text{liquidity}}+S_{\text{game}}+S_{\text{rewards}}+S_{\text{vesting}}+S_{\text{reserve}}.\]

The table is illustrative, not normative. Buckets are launch configuration parameters, not protocol constants; different projects will use different distributions.

3.1  Supply bucket accounting

Each bucket should track: initial allocation; current balance; committed liabilities; claimed amount; vested-but-unclaimed amount; locked amount; governance-controlled amount; and remaining available amount. A dashboard can represent the state as

\[S_{\text{bucket}}=S_{\text{available}}+S_{\text{committed}}+S_{\text{claimed}}+S_{\text{locked}}.\]

3.2  Inflows are part of the accounting

Version 0.1 tracked only outflows. In v0.2, bucket accounting also tracks inflows, because two inflows are structural: routed losing entries into the game vault (§5.3), and edge-allocated replenishment (§6). Interactive allocation creates liabilities over time, but it creates inflows over time too; an accounting model that shows one side only will misprice the launch.

4  Launch Pool and Acquisition Dynamics

Before a participant enters a round, the protocol establishes the token amount \(b\), which then moves to the round escrow (White Paper §10). The amount may come from a pool swap, a bonding curve, a fixed-price vault, or another configured acquisition mechanism.

4.1  Pool-based acquisition

For a constant-product pool \(XY=k\) with quote reserve \(X\), token reserve \(Y\), fee factor \(\gamma\), and effective input \(\Delta Q'=\gamma\,\Delta Q\):

\[\Delta T=\frac{Y\,\Delta Q'}{X+\Delta Q'},\qquad b=\Delta T_{\text{confirmed}}.\]

The game must not use a frontend quote as \(b\); it uses the confirmed output.

4.2  Bonding curve and fixed-price acquisition

A project may instead use a bonding function \(\Delta T=B(\Delta Q,\theta)\) with curve parameters \(\theta\), which encodes deterministic launch pricing, or a fixed-price vault \(\Delta T=p^{-1}\Delta Q\), which is simpler but less market-responsive.

4.3  Minimum output protection

Participants can require \(\Delta T\ge\Delta T_{\min}\); if the acquisition cannot satisfy this, the launch entry fails and no round opens.

4.4  Entry price and user experience

The effective entry price is \(p_{\text{eff}}=\Delta Q/\Delta T\); the pool spot price is \(p_{\text{spot}}=X/Y\); slippage is \(\sigma=(p_{\text{eff}}-p_{\text{spot}})/p_{\text{spot}}\). Deeper liquidity reduces slippage and improves launch usability; thin liquidity increases price impact and reduces the predictability of entry amounts.

5  Game Distribution Vault and Loss Routing

The game distribution vault funds the vault-side portion of winning allocations, and it receives the routed losing entries. Under the gross-payout convention of White Paper §6.5, a winning round pays the participant \(A=bE\) total: the escrowed \(b\) returns inside the payout, and the vault supplies the remainder \(A-b=b(E-1)\). A losing round forfeits the escrow, which then routes per §5.3. Vault exposure and vault inflow are therefore both stated net of the returned escrow.

5.1  Liabilities and solvency

Let \(V_{\text{game}}\) denote the available balance of the game distribution vault. Outstanding gross allocation liabilities are

\[L_{\text{game}}=\sum_{P,r}A_{P,r}^{\text{unclaimed}}+\sum_{P,r}A_{P,r}^{\text{vested-unclaimed}}+\sum_{P,r}A_{P,r}^{\text{locked}},\]

of which the vault-funded portion is \(L_{\text{game}}^{\text{vault}}=\sum(A_{P,r}-b_{P,r})\) for winning rounds, the balance being covered by held escrows. A basic solvency condition is \(V_{\text{game}}\ge L_{\text{game}}^{\text{vault}}\); with an edge reserve and backstop, the condition becomes

\[V_{\text{game}}+R_{\text{edge}}+B_{\text{backstop}}\;\ge\;L_{\text{game}}^{\text{vault}}.\]

5.2  Vault states and liability timing

The vault should track states: available; reserved (committed to unsettled rounds); claimable; vested; locked; claimed; expired or forfeited. Interactive allocation creates stochastic liabilities — a run of participant wins can create claim obligations faster than the average edge replenishes reserves. Vault design must therefore account for variance, not only for the long-run expected value; the Red Paper owns that analysis.

5.3  Loss routing

Loss routing is the largest single flow in the launch economy, and each destination shapes the economy differently. Routing to the vault is self-balancing: the same pool that pays winners is fed by losers, and the expected net vault flow per round is \(+bh\) under calibration. Routing to burn makes losses deflationary — the vault then depends on its initial allocation and edge splits alone, so burn routing demands stricter Red Paper reserve sizing. Routing to treasury converts losses into discretionary capital, which is operationally flexible but is also the configuration a skeptical reader scrutinizes first; heavy treasury routing should be paired with public accounting. Routing to LP deepens the very pool participants buy and sell through, which dampens the reflexive loops of §8.

6  Protocol Edge and Revenue Allocation

Let \(h\) be the protocol edge. In the classical rule set the expected participant net return is \(\mathbb{E}[R_e]=-bh\), and the corresponding expected protocol-side margin is \(\mathbb{E}[M]=bh\). Note that under vault-routed losses (\(\delta_{\text{vault}}=1\)), this margin already materializes inside the vault as the expected surplus of loss inflows over win outflows; the edge split below then describes how that surplus is directed onward.

6.1  Edge allocation buckets

The edge may be allocated to: game vault replenishment; reward vaults; the liquidity backstop; project treasury; protocol treasury; seasonal boosts; insurance reserve; operations; or buyback/burn mechanisms if configured. With the split

\[1=\alpha_{\text{game}}+\alpha_{\text{rewards}}+\alpha_{\text{backstop}}+\alpha_{\text{treasury}}+\alpha_{\text{protocol}}+\alpha_{\text{other}},\]

the expected edge flow into bucket \(j\) is \(R_j=\alpha_j\,bh\) per round.

6.2  Transparency requirement

The edge is not hidden — it is a configured protocol parameter. A participant should be able to understand: the expected protocol edge; the loss route \(\boldsymbol{\delta}\); reward funding rules; claim rules; vesting or lock rules; active boosts; and the payout function with its cap. The LPF economic design treats negative expected value as a transparent funding source for rewards, backstops, and launch economics.

6.3  Variance and reserve requirements

Long-run expected edge does not guarantee short-run solvency. A reserve model should account for participation volume, payout variance, maximum multiplier exposure, boost commitments, claim timing, vesting release timing, and pool liquidity conditions. A simple requirement is \(R_{\min}\ge\kappa\cdot\sigma_A\), with allocation volatility \(\sigma_A\) and risk multiplier \(\kappa\). This is not a complete risk model; the Red Paper carries the complete treatment, including the redefinition of what “ruin” actually means under fractional caps.

7  Liquidity Backstops

A liquidity backstop supports the launch economy during high variance, early participation, or thin liquidity. Let \(B\) denote backstop capacity, which may be denominated in the project token \(T_i\), the quote asset \(Q\), LP tokens, protocol reserve assets, or treasury-controlled vault balances.

7.1  Backstop functions

A backstop serves several roles: payout solvency (valid allocations can be honored); liquidity depth (reduced slippage); early variance absorption (before long-run edge stabilizes reserves); reward reliability (seasonal and boosted rewards remain fundable); and participant confidence (transparent coverage of claim liabilities).

7.2  Backstop health on effective values

Version 0.1 measured backstop health at face value, which overstates coverage whenever the backstop is denominated in the project's own token: selling a token-denominated backstop into its own pool moves the price against the seller. Version 0.2 states health on effective values, using the liquidity haircut \(\chi\in[0,1]\) defined in Red Paper §5. Splitting the backstop into a quote-denominated part \(B_Q\) and a token-denominated part \(B_T\) (marked at spot):

\[H_{\text{backstop}}=\frac{V_{\text{game}}+R_{\text{edge}}+B_Q+\chi\,B_T}{L_{\text{game}}^{\text{vault}}}.\]

If \(H_{\text{backstop}}\ge1\) on effective values, the system can cover outstanding vault-funded liabilities; if \(H_{\text{backstop}}<1\), the system is undercollateralized relative to current claims and commitments, no matter what the face-value ratio says. The haircut model, its coupling to pool depth, and the stress double-count warning all live in Red Paper §5 and Appendix C, and this section defers to them.

7.3  Backstop policy

A project may define: a minimum effective health ratio; an automatic pause threshold; reduced maximum entry size under stress; reduced reward boosts under stress; a governance review threshold; and reserve replenishment rules.

8  Reflexivity and Circulating Supply

LPF launches have reflexive dynamics because acquisition, game allocation, loss routing, claims, and market liquidity interact. A participant may: (1) buy \(T_i\) through a pool; (2) enter an allocation game; (3) win additional \(T_i\) from the vault, or forfeit the entry to the loss route; (4) claim \(T_i\); (5) sell \(T_i\) back into the same market. This creates feedback among participation, circulating supply, price, liquidity depth, and reward incentives.

8.1  The four loops

Demand loop. Participation creates acquisition demand, \(\Delta Q\rightarrow\Delta T_i\); more entries mean more pool activity, affecting price and slippage in a pool-based launch. Supply release loop. Winning allocations and rewards release supply into participant hands, \(A_P\rightarrow C_P(t)\); claimed tokens can increase circulating supply. Sell pressure loop. Recipients may sell, \(T_i\rightarrow Q\), creating pressure against the same pool used for acquisition. Loss sink loop (new in v0.2). Losing entries exit circulation into the loss route: vault-routed losses become future win liabilities rather than circulating supply; burned losses exit permanently; LP-routed losses deepen the market. In expectation the sink absorbs more than the release loop emits — that is exactly what a positive edge means — so the net reflexive pressure of the game itself is mildly contractionary, while emissions and boosts (§9–§10) push the other way.

8.2  Reflexive balance

A simplified circulating-supply dynamic, now including the sink:

\[\Delta S_{\text{circ}}(t)=C_{\text{claims}}(t)+U_{\text{vesting}}(t)+R_{\text{rewards}}(t)-L_{\text{locks}}(t)-\underbrace{(\delta_{\text{vault}}+\delta_{\text{burn}})\,B_{\text{lost}}(t)}_{\text{loss sink}},\]

where \(B_{\text{lost}}(t)\) is the sum of forfeited entries in the period. The launch economy must balance acquisition demand, reward emissions, claim timing, vesting schedules, liquidity depth, backstop capacity, protocol edge, and participant retention.

8.3  Design implication

The reflexive loop is not a flaw to hide; it is the economic system being designed. LPF can modulate it using vesting, claim delays, reward schedules, backstop reserves, season timing, boost caps, liquidity incentives, maximum entry sizes, the loss route \(\boldsymbol{\delta}\), and edge allocation.

9  Reward Vaults and Seasons

Reward vaults support recurring participation. Let \(S_{\text{rewards}}\) be the total reward supply, divided into seasons: \(S_{\text{rewards}}=\sum_{k=1}^{K}S_{\text{season},k}\). Each season \(k\) has a reward budget, start and end times, eligible rule sets, missions, leaderboard categories, boost parameters, and claim or vesting rules.

9.1  Season cadence

A project may run daily, weekly, bi-weekly, or event-based seasons. Cadence affects participant retention, reward pacing, leaderboard competitiveness, emission rate, and content refresh frequency.

9.2  Daily missions

A mission is a condition over participant activity: \(m_j(P,t)\in\{0,1\}\) denotes whether participant \(P\) completed mission \(j\) during window \(t\). Examples: participate in \(n\) rounds; eject above a multiplier threshold; survive at least \(x\) checkpoints; reach an arcade altitude threshold; travel a configured distance; participate on consecutive days; claim or vest an allocation; vote on a project parameter.

9.3  Leaderboards

Leaderboards can rank total participation, highest multiplier, longest travel time, highest altitude, missions completed, net allocation, season points, or streaks. For Arcade Rocket, the offchain telemetry — altitude, distance, acceleration, travel time — is especially useful here: such metrics create a changing game meta without complicating the core explosion or adjudication math (White Paper §7).

9.4  Season points and distribution

A season score can be modeled as

\[\text{Score}_{P,k}=\sum_j w_j\,m_j(P,k)+\sum_l \eta_l\,x_l(P,k),\]

with mission weights \(w_j\), continuous activity metrics \(x_l\), and metric weights \(\eta_l\). Rewards may distribute by rank, points, lottery, threshold, or a hybrid. For proportional points:

\[R_{P,k}=S_{\text{season},k}\cdot\frac{\text{Score}_{P,k}}{\sum_{P'}\text{Score}_{P',k}}.\]

9.5  Reward caps

Reward systems should cap: maximum reward per participant; per day; per round boost; per season emission; and maximum leaderboard share. Caps protect vault solvency, and Appendix F shows the aggregate constraint every cap must respect.

10  Boost Functions

Boosts modify allocation or reward outcomes. With base allocation \(A\), a boost may be additive, \(A'=A+B_k(P,r)\), or multiplicative, \(A'=A(1+\beta_k(P,r))\).

Additive boosts are easier to cap, \(0\le B_k\le B_{\max}\), and suit mission rewards, participation bonuses, small fixed incentives, and streaks. Multiplicative boosts scale with the base allocation, \(0\le\beta_k\le\beta_{\max}\), and suit seasonal multipliers, special events, partner campaigns, and loyalty modifiers — but they create higher variance and demand stronger reserve controls. Eligibility may depend on season, missions, participant tier, holdings, governance vote, launch rules, referral campaigns, or prior participation.

10.1  Boost solvency

Boost liabilities must enter vault accounting: \(L_{\text{boost}}=\sum_{P,r}(A'_{P,r}-A_{P,r})\), with the safety condition \(V_{\text{rewards}}\ge L_{\text{boost}}\). If reward vault health falls below threshold, boost issuance pauses or scales down. Boosts are pure emissions — the loss route does not fund them in expectation unless the edge split says so — which is why the sustainability inequality of Appendix F puts boosts on the cost side.

11  Vesting and Locks

Vesting and locks let launches balance excitement against responsible circulating supply management. An allocation may be immediately claimable, \(A_{\text{claim}}=A\), which is simple but raises circulating supply at once; or it vests over time as \(V_P(t)=A_P\cdot v(t)\), \(v(t)\in[0,1]\), with claimable amount \(C_P(t)=V_P(t)-C_P^{\text{claimed}}\).

Linear vesting between \(t_0\) and \(t_1\):

\[v(t)=\begin{cases}0,&t<t_0,\\[1pt]\frac{t-t_0}{t_1-t_0},&t_0\le t\le t_1,\\[1pt]1,&t>t_1.\end{cases}\]

Cliff vesting at \(t_c\): \(v(t)=0\) for \(t<t_c\), \(1\) for \(t\ge t_c\). A hybrid schedule combines both:

\[v(t)=\begin{cases}0,&t<t_c,\\[1pt]\alpha+(1-\alpha)\frac{t-t_c}{t_1-t_c},&t_c\le t\le t_1,\\[1pt]1,&t>t_1.\end{cases}\]

Allocations may also be locked until a condition is satisfied: a time threshold, milestone completion, governance vote, season end, liquidity threshold, project verification, or dispute resolution. Locked allocations remain protocol liabilities even before they become claimable.

12  Milestone-Based Unlocks

Milestone unlocks bind token release to project progress or governance-confirmed conditions. Let \(M_j\) denote milestone \(j\), with unlock indicator \(u(M_j)\in\{0,1\}\); a milestone-gated tranche \(S_j\) unlocks as \(U_j=u(M_j)\,S_j\). Milestones may include: prototype release; public beta; mainnet launch; audited contract deployment; liquidity threshold; user participation threshold; governance vote; partner integration; revenue threshold. A participant allocation can combine both gates: \(V_P(t,M)=A_P\cdot v(t)\cdot u(M)\).

12.1  Milestone verification

Milestones can be verified by governance vote, multisig approval, oracle or attestation, an onchain condition, manual review, or a project-defined verifier. The verification method must be specified in the launch configuration.

12.2  A trust boundary, stated plainly

12.3  Project accountability

Milestone unlocks bridge token distribution and project delivery. They let a project communicate what must be delivered, what unlocks when delivered, who verifies delivery, and which tranches are affected.

13  Team, Investor, and Contributor Tranches

LPF models structured stakeholder allocations. The team allocation divides into tranches, \(S_{\text{team}}=\sum_{j=1}^{J}S_{\text{team},j}\), each with a recipient or group, an amount, a start time, a cliff, a vesting curve, a milestone condition, and a claim authority. Investor allocations follow separate schedules with the same machinery, \(S_{\text{investor}}=\sum_j S_{\text{investor},j}\); contributor tranches may be tied to role, deliverable, grant, milestone, vesting period, or DAO approval. Participants who win allocations may likewise receive a configured split, \(A_P=A_{P,\text{claimable}}+A_{P,\text{vested}}+A_{P,\text{locked}}\), which reduces the immediate circulating supply impact of wins.

14  Governance and Curation

Governance controls how launches are configured, updated, and verified. Its scope may include: launch approval; project verification; supply bucket configuration; the loss route \(\boldsymbol{\delta}\); reward schedules and season settings; milestone verification; edge allocation; backstop requirements; liquidity parameters; rule-set availability; dispute parameters; and emergency pause controls — subject, always, to the settlement carve-out of Red Paper §10.5: no governance action can block a committed round from reaching settlement.

Governance actions take the form \(G_j=(\text{action},\text{parameters},\text{execution condition})\): approve a launch, change season weights, verify a milestone, release a tranche, adjust a boost cap, pause new entries, update the allowed rule set. Governance introduces risks — parameter abuse, reward misallocation, milestone fraud, insider capture, inconsistent approvals, emergency-control misuse — mitigated by timelocks, multisig thresholds, quorum requirements, transparent proposal history, a public parameter registry, role-based permissions, emergency-only pause roles, and immutable rule-set versions.

15  Project Dashboard and Accounting Views

A core LPF economic primitive is visibility: a project should view its launch as an accounting system, not a black-box campaign.

A project dashboard may show: total supply; bucket allocations; launch pool reserves; game vault balance and loss-route inflows; reward vault balance; effective backstop health (§7.2); claimable, vested, and locked liabilities; season reward usage; milestone status with the proven/attested distinction of §12.2; participant count; average allocation; and circulating supply estimates. A participant dashboard may show: total allocation; claimable, vested, and locked tokens; season rewards; mission progress; leaderboard rank; claim history; vesting schedule; and dispute or settlement status.

The dashboard solvency view uses the effective-value ratio of §7.2, so projects and participants see one honest coverage number rather than a face-value one.

16  Reference Economy: FUEL

The reference deployment uses FUEL, \(T_i=F\), which can serve as launched token, game allocation token, reward token, claim token, season reward token, coordination token, and launch ecosystem utility token. Participants contribute SOL; the acquisition module outputs FUEL; the confirmed amount becomes \(b=\Delta F_{\text{confirmed}}\). The FUEL game vault funds allocations won through rounds and receives the routed losing entries under the default \(\boldsymbol{\delta}=(1,0,0,0)\). FUEL reward vaults may fund daily missions, weekly or bi-weekly seasons, leaderboard prizes, participation boosts, arcade telemetry challenges, and community campaigns. FUEL allocations may be immediately claimable, linearly vested, cliff-vested, milestone-locked, season-locked, or governance-unlocked. FUEL may also coordinate the broader ecosystem through fee discounts, launch curation, reward boosts, governance participation, staking or locking modules, and access to launch features — such roles must be configured explicitly, and they must not interfere with the core fairness proof of allocation rounds.

17  Economic Risk Analysis

18  Parameterization

19  Relationship to the White Paper and Red Paper

The White Paper defines the base protocol: the escrowed amount \(b\); rule sets; expected value; dual-entropy commit–reveal randomness; signed participant actions; the scheduled checkpoint channel; onchain adjudication; emergency eject; settlement; and claims. This Pink Paper defines the surrounding economic system: supply buckets; liquidity pools; loss routing; game vaults; edge allocation; reward vaults; seasons; boosts; vesting; milestones; governance; dashboards; and reflexive dynamics. The Red Paper constrains both.

The White Paper answers: was the allocation result fair and verifiable?
The Pink Paper answers: how is the allocation funded, distributed, retained, vested, and governed?
The Red Paper answers: can the protocol survive its own variance?

20  Conclusion

LPF treats a token launch as a dynamic economic system. The White Paper makes interactive allocation rounds verifiable; this Pink Paper organizes the surrounding economy — token supply, launch pools, loss routing, game vaults, protocol edge, reward seasons, boosts, vesting, milestone unlocks, governance, dashboards, and backstops — with every major flow, including the largest one, stated explicitly and accounted on effective values. The reference deployment uses FUEL, but the model generalizes to arbitrary compatible project tokens. The central economic thesis stands: token launches can be more than passive swaps or static allocation pages. They can be interactive distribution systems with explicit expected value, transparent accounting, configurable rewards, structured unlocks, and auditable claims.

Appendix A: Example Launch Configuration

Appendix B: Example Season Configuration

Appendix C: Example Vesting Schedule

A hybrid schedule: 10% immediate; 20% after a 30-day cliff; the remaining 70% linear over 12 months. With total allocation \(A_P\):

\[A_{\text{immediate}}=0.10\,A_P,\qquad A_{\text{cliff}}(t)=\begin{cases}0,&t<30\text{ d},\\0.20\,A_P,&t\ge30\text{ d},\end{cases}\qquad A_{\text{linear}}(t)=0.70\,A_P\cdot v(t),\]

\[V_P(t)=A_{\text{immediate}}+A_{\text{cliff}}(t)+A_{\text{linear}}(t).\]

This is the gold curve of Figure 3.

Appendix D: Reflexivity Example

Suppose participants buy \(T_i\) through a pool; the game vault distributes additional \(T_i\); participants claim and sell a fraction \(\phi\) of claimed tokens. With total claimed tokens \(C(t)\) in period \(t\), potential sell pressure is \(S_{\text{sell}}(t)=\phi\,C(t)\); with acquisition demand \(D_{\text{buy}}(t)\), net pressure approximates \(N(t)=D_{\text{buy}}(t)-S_{\text{sell}}(t)\). Under the default loss route, forfeited entries \(B_{\text{lost}}(t)\) never reach circulation in the first place, which lifts \(N(t)\) relative to a naive model. This simplified model does not predict price; it highlights the reflexive relationship between acquisition demand and claim-driven supply.

Appendix E: Economic Risk Checklist

A launch configuration should answer: (1) total supply; (2) game distribution funding; (3) reward funding; (4) the protocol edge; (5) where the edge flows; (6) where losing entries flow, and under what split; (7) max entry sizes; (8) the effective backstop health threshold; (9) the vesting schedule; (10) which milestones affect unlocks, and who verifies them, with the proven/attested distinction stated; (11) season reward budgets; (12) boost caps; (13) behavior under vault stress; (14) pause controls and the settlement carve-out; (15) claim tracking; (16) circulating supply estimation, including the loss sink; (17) governance delay and approval; (18) whether the Appendix F inequality holds at the projected volume.

Appendix F: The Sustainability Inequality

Every reward promise the economy makes must be paid from somewhere, and there are only two structural sources: the protocol edge on wagered volume, and whatever share of edge-equivalent flow the loss route directs to fundable buckets. Emissions and boosts are the structural costs. Over an accounting period, let \(V_{w}\) denote total wagered volume (the sum of entries \(b\)), \(h\) the edge, \(R_{\text{emit}}\) the period's season and mission emissions, \(L_{\text{boost}}\) the period's boost liabilities, and \(O\) operating costs charged to the launch economy. The launch is sustainable in expectation only if

\[\boxed{\;h\cdot V_{w}\;\ge\;R_{\text{emit}}+L_{\text{boost}}+O.\;}\]

Equivalently, the break-even wagered volume is

\[V_{w}^{*}=\frac{R_{\text{emit}}+L_{\text{boost}}+O}{h}.\]

Worked example. Take \(h=0.03\), weekly season emissions of 30{,}000 FUEL, weekly boost liabilities of 6{,}000 FUEL, and operating costs of 4{,}000 FUEL charged to the economy. Then

\[V_{w}^{*}=\frac{30{,}000+6{,}000+4{,}000}{0.03}\approx 1.33\text{M FUEL wagered per week}.\]

Below this volume, the reward economy runs on inventory — it spends down \(S_{\text{rewards}}\) and \(S_{\text{game}}\) — which is acceptable as deliberate, budgeted launch marketing, and dangerous as an unexamined default. A dashboard should display the realized ratio \(hV_w/(R_{\text{emit}}+L_{\text{boost}}+O)\) each period; the Red Paper's variance analysis then determines how much buffer above 1.0 the ratio needs, since edge income arrives noisily while emissions leave on schedule.