# FOMO ### The Franchise Model for AI Inference FOMO introduces a new economic model for AI inference: a franchise-style system where every model deployment becomes its own programmable micro-economy. Instead of treating inference as a stateless commodity sold by centralized gateways, FOMO transforms model usage into an onchain economic loop powered by: * Revenue-backed model economies * Usage-linked token burns * Demand-driven emissions * Programmable inference discounts * Transparent value routing At the center of the system are two assets: **$FLOCK** is the macro-level ecosystem token. It is used for protocol incentives, governance, emissions, launch participation, and platform-level value capture. Inference revenue can also be routed into $FLOCK buybacks and burns, linking network-wide demand to long-term token scarcity. **$MT**, or Model Token, is a deployment-specific token. Each $MT corresponds to a particular model deployment and its associated economic setup. A single model may have multiple deployments, and therefore multiple $MTs, depending on hosting configuration, pricing, and use case. In the current design, each deployment mints a fixed supply of **1,000,000 $MT**. Each Model Token represents a specific model deployment and its associated inference economy. As the model is used, revenue can be routed into token buybacks, burns, staking rewards, and protocol-level value accrual. #### Quick Reference | Lever | Score effect | Notes | | -------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------- | | API spend on MT | Multiplies factor by `usage share` | Linear: spend splitting does not increase combined base score | | Stake on MT | Lifts factor from `α` toward `1.0`: `α + (1 − α)·√(stake share)` | α is expected to start around 0.9 and step down toward 0.5 | | gmFLOCK balance | Multiplies score on every MT by `1 + λ × G` | Log-scale; no need to be a whale | | MT incentive vintage | Bigger pool while incentive is fresh | Time-limited (\~180 days per MT) | #### $MT Supply Distribution Each Model Token has a fixed supply of **1,000,000 $MT**, distributed as follows: | Allocation | Share | Purpose | | --------------------------- | ----: | ------------------------------------------------------- | | Public Sale | 40% | Sold during the RMO / FOMO launch | | Liquidity Pool | 20% | Paired with raised $FLOCK and migrated to DEX liquidity | | Incentive Reserve | 20% | Emitted to users and stakers over the incentive period | | RMA Issuer / MTO Allocation | 10% | Vested allocation for the issuer | | Platform Treasury | 10% | Vested allocation for FLock Platform | This structure gives each model deployment its own micro-economy: a fundraising phase, a liquidity base, user incentives, issuer upside, and platform alignment. #### Launch and Fundraising When a new model deployment is launched, participants can purchase $MT using $FLOCK through an internal market. The current design uses a **constant-product bonding curve**, similar to Uniswap v2, where price increases as more $FLOCK flows into the pool and $MT inventory decreases. Users cannot sell $MT back into the internal market during the fundraising phase. If the launch fails to reach its target by the deadline, pledges are cancelled and the token is not minted or distributed. If the launch succeeds, liquidity is migrated to an external DEX such as Aerodrome. #### Revenue Waterfall Once a model is live on the FLock API Platform, users pay for inference in fiat, USDC, or equivalent supported payment methods. After compute costs are paid, the remaining amount is treated as **Net Revenue**. The current waterfall is: | Destination | Share of Net Revenue | Function | | ---------------------- | -------------------- | -------------------------------------------- | | $FLOCK Buyback / Burn | 30% | Supports macro-token value capture | | Platform Treasury | 30% | Funds operations and platform sustainability | | $MT Buyback / Burn | 30% | Creates model-level deflation | | RMA Issuer / MTO Yield | 10% | Rewards the model deployment operator | This is the core usage-to-value loop: real inference demand creates revenue, revenue triggers buybacks, buybacks reduce token supply, and token scarcity reinforces the model economy. #### Daily Reward Streams Each supported $MT can distribute **three kinds of daily rewards**: 1. **Global $FLOCK Emission**\ A fixed daily amount of FLOCK divided across all MTs in proportion to how much each MT was used. 2. **Per-$MT $FLOCK Incentive**\ A FLOCK pool dedicated to that specific MT, paid out evenly over \~180 days. 3. **Per-$MT Token Incentive**\ A pool of the MT's own token, also paid over \~180 days. These rewards are designed to bootstrap real usage and reward the participants who help a model gain traction. The non-staker rewards draft also specifies that users do **not necessarily need to stake to earn**; API usage alone can make a user eligible, although stakers earn more than non-stakers at equal usage. #### Transition Emission During the first transition phase, emissions come from the **emission gap period**. This means FOMO can begin distributing incentives before the full long-term incentive structure is fully activated. This transition phase is useful because it gives the system a bootstrapping window: models can begin competing for usage, users can begin forming habits around the API Platform, and $MT economies can start producing measurable demand signals before the mature incentive regime takes over. #### Competition-Based Reward Share Within each supported $MT, rewards are distributed according to a competition-based scoring system. A participant’s share is determined by: ``` participant share = participant score / total score of all participants on that MT ``` The score is based on three factors: ``` score = usage share × staking factor × gmFLOCK multiplier ``` **1. API Usage Share** Usage share measures how much API spending a participant contributes to a specific $MT compared to all other users of that $MT. ``` usage share = user spending on this MT / total spending on this MT ``` In **Season 1**, usage may be automatically mapped through the API Platform. In **Season 2 and forward**, usage should be mapped more explicitly through **model ID**, meaning users will need to generate usage through the correct model identity in order for that activity to count toward the corresponding $MT. This is important because FOMO rewards are model-specific. Spending on one model should not dilute or inflate reward share on another model. **2. Staking Factor** The staking factor rewards participants who stake the $MT they use. The current reward logic allows non-stakers to earn if they generate usage, but stakers receive a higher score at equal usage. The non-staker reward draft uses a square-root staking factor, where the staking boost grows with stake share but does not scale linearly, reducing the risk of whale dominance. In **Season 1**, the staking factor is primarily based on how much $MT a participant holds or stakes relative to the total staked amount for that $MT. In **Season 2 and forward**, the staking factor should become more sophisticated by incorporating both: ``` staking amount + lock duration ``` This means long-term aligned supporters can receive a stronger reward position than short-term holders. **3. gmFLOCK Multiplier** gmFLOCK acts as a global score multiplier across supported $MTs. The multiplier is designed to be **non-linear**. As a participant holds more gmFLOCK, their boost approaches a higher effectiveness level, potentially close to **2x**, but with diminishing returns. This means large holders receive an advantage, but whales do not dominate the reward system linearly. Conceptually: ``` gmFLOCK multiplier = 1 + λ × G ``` Where `G` reflects a user’s gmFLOCK balance on a log-style or diminishing-return scale. The key design principle is: > gmFLOCK should reward long-term ecosystem alignment, but it should not allow pure capital size to overpower real model usage. gmFLOCK can also be used across both **FOMO** and **AI Arena**, creating an incentive bridge between the demand side of the ecosystem and the model training / supply side. #### Worked Examples One MT, daily pool = 100 FLOCK, linear usage, square-root staking, nobody holds gmFLOCK. * **Alice** stakes the MT and is the **only staker** (stake\_share = 1.0). Accounts for 50% of API spending. * **Bob** doesn't stake, accounts for the other 50% of spending. With early-stage `α = 0.9`, staking helps, but only a little: | | usage share | staking factor | combined `factor × usage` | | ----- | ----------- | ---------------------- | ------------------------- | | Alice | 0.5 | `0.9 + 0.1·√1` = 1.000 | 1.000 × 0.5 = 0.500 | | Bob | 0.5 | `α` = 0.900 | 0.900 × 0.5 = 0.450 | Alice earns `0.500 / (0.500 + 0.450)` ≈ **52.6 FLOCK**. Bob earns **47.4 FLOCK**. If Alice held only 10% of the MT's total stake, her factor would be `0.9 + 0.1·√0.1 ≈ 0.932`. With equal usage, she would earn roughly **50.9 FLOCK** vs. Bob's **49.1 FLOCK**. That is intentional: early rewards are not meant to heavily favor people who were already staked. With mature-stage `α = 0.5`, staking has a much stronger effect: | | usage share | staking factor | combined `factor × usage` | | ----- | ----------- | ---------------------- | ------------------------- | | Alice | 0.5 | `0.5 + 0.5·√1` = 1.000 | 1.000 × 0.5 = 0.500 | | Bob | 0.5 | `α` = 0.500 | 0.500 × 0.5 = 0.250 | Alice earns `0.500 / (0.500 + 0.250)` ≈ **66.7 FLOCK**. Bob earns **33.3 FLOCK**. If Alice held only 10% of the MT's total stake (someone else stakes the other 90% but doesn't use the API), her factor drops to `0.5 + 0.5·√0.1 ≈ 0.658` — but she still beats Bob's `0.5`, earning roughly **56.8 FLOCK** vs. Bob's **43.2 FLOCK**. The lift from staking is smaller, but much more visible than it was at `α = 0.9`. Now suppose Bob also picks up some gmFLOCK so his multiplier becomes `2×`. His score doubles, shifting the split further in his favour. Holding gmFLOCK helps stakers and non-stakers alike. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.flock.io/flock-tokenomics/network-participation/fomo.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.