> For the complete documentation index, see [llms.txt](https://docs.flock.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flock.io/flock-tokenomics/network-participation/fomo.md).

# 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
* Stake-gated model-specific incentives

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.

In this design, API usage remains the primary signal of real demand, while staking determines who is economically aligned with a specific model deployment. Global ecosystem emissions remain accessible to active users, but model-specific incentive pools are reserved for participants who both use and stake the corresponding Model Token.

#### Quick Reference

| Lever                | Global FLOCK effect                                                                     | Reserved FLOCK / MT Reward effect                                               | Notes                                                                                                                  |
| -------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| API spend on MT      | Multiplies `global_score` by `usage_share`                                              | Multiplies `incentive_score` by `usage_share`                                   | Usage is the base demand signal. Spend splitting does not increase total share.                                        |
| Stake on MT          | Boosts `global_staking_factor` from `α` toward `1.0` using `α + (1 − α) × √stake_share` | Unlocks model-specific incentives through linear `stake_share`                  | No stake = no Reserved FLOCK or MT Reward.                                                                             |
| gmFLOCK balance      | Multiplies `global_score`                                                               | Multiplies `incentive_score`, but only if the user has positive stake and usage | Uses effective gmFLOCK balance, weighted by remaining lock duration. Longer remaining lock duration gives more weight. |
| MT incentive vintage | N/A                                                                                     | Larger pool while incentive is fresh                                            | Time-limited, approximately 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 supported MTs according to model usage. Within each MT, participants can earn from this pool through API usage. Staking improves a participant’s score, but non-stakers can still receive a share through the global non-staker floor.
2. **Reserved $FLOCK**\
   A $FLOCK incentive pool dedicated to a specific MT, paid out over approximately 180 days. This pool is staker-gated: users must stake the relevant MT to be eligible, and actual distribution depends on their incentive score, which also includes API usage.
3. **MT Reward**\
   A pool of the MT’s own token, also distributed over approximately 180 days. Like Reserved $FLOCK, this pool is staker-gated. Distribution is based on each eligible participant’s incentive score, which combines usage share, linear stake share, and the gmFLOCK multiplier.

Together, these streams separate ecosystem-level usage rewards from model-specific stakeholder rewards. API usage alone can still earn Global $FLOCK, but unlocking Reserved $FLOCK and MT Reward requires staking the corresponding MT.

#### 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 two parallel scoring systems:

`global_score = usage_share × global_staking_factor × gmFLOCK_multiplier`

`incentive_score = usage_share × incentive_staking_factor × gmFLOCK_multiplier`

The normalized `global_score` determines a participant’s share of Global FLOCK Emission.

The normalized `incentive_score` determines a participant’s share of Reserved FLOCK and MT Reward.

Both scores are based on three factors: API usage share, staking factor, and gmFLOCK multiplier. The difference is that the staking factor is calculated differently for global rewards and model-specific incentives.

**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 now differs by reward bucket.

For **Global $FLOCK Emission**, FOMO continues to use a square-root staking curve with a non-staker floor:

`global_staking_factor = α + (1 − α) × √stake_share`

This preserves accessibility for active API users. A participant who generates real usage can still earn Global $FLOCK even without staking, while stakers receive a higher score at equal usage.

For **Reserved $FLOCK** and **MT Reward**, the staking factor is linear:

`incentive_staking_factor = stake_share`

There is no α floor for these model-specific incentive pools. A participant with zero stake has an incentive staking factor of zero, which means they receive no Reserved $FLOCK or MT Reward from that MT regardless of API usage.

This creates a clear separation between demand contribution and model-specific economic alignment: usage can earn global emissions, but staking is required to unlock the incentive pools attached to a specific model deployment.

**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 effective 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 effective gmFLOCK balance, normalized on a log-style or diminishing-return scale.

Effective gmFLOCK balance is time-weighted by the remaining lock duration of the user’s gmFLOCK position. In other words, gmFLOCK that remains locked for longer contributes more weight than gmFLOCK that is close to unlocking.

For example, conceptually, `100 gmFLOCK` with `1 year` remaining until unlock can have the same effective weight as `200 gmFLOCK` with `6 months` remaining until unlock, assuming a linear duration-weighting model.

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 Global FLOCK pool = 100 FLOCK, linear usage, square-root staking for the global pool, and nobody holds gmFLOCK.

Reserved FLOCK and MT Reward are separate model-specific incentive pools. They use linear stake share instead of the square-root global staking factor.

* **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 | global\_staking\_factor | global\_score       |
| ----- | ------------ | ----------------------- | ------------------- |
| 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.

This is because Alice’s global staking factor is `1.0`, while Bob’s non-staker floor is `0.9`.

However, the Reserved FLOCK and MT Reward pools work differently. These model-specific incentive pools are staker-gated. Since Alice is the only staker and Bob has no stake, Alice receives 100% of the Reserved FLOCK and MT Reward distributed for this MT, while Bob receives 0 from those pools.

Now suppose Alice is no longer the only staker and holds only 10% of the MT’s total stake. Her global staking factor would be:

`0.9 + 0.1 × √0.1 ≈ 0.932`

With equal usage, Alice would earn roughly `50.9 FLOCK` from the Global FLOCK pool, while Bob would earn `49.1 FLOCK`.

That is intentional: early global rewards are not meant to heavily favor people who were already staked.

For the Reserved FLOCK and MT Reward pools, Alice’s incentive staking factor would be `0.1`, while Bob’s would still be `0`. If Alice is the only participant with both positive stake and API usage on this MT, she receives 100% of the distributed model-specific incentives. If another staker also generates usage, the model-specific incentive split follows the incentive score based on usage share, stake share, and gmFLOCK multiplier.

With mature-stage `α = 0.5`, staking has a much stronger effect on the Global FLOCK pool:

|       | usage\_share | global\_staking\_factor | global\_score       |
| ----- | ------------ | ----------------------- | ------------------- |
| 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, her global staking factor would be: `0.5 + 0.5 × √0.1 ≈ 0.658`.

With equal usage, Alice would earn roughly `56.8 FLOCK` from the Global FLOCK pool, while Bob would earn `43.2 FLOCK`.

The lift from staking is smaller when Alice has only 10% of the stake, but much more visible than it was at `α = 0.9`.

For Reserved FLOCK and MT Reward, the same rule still applies: Bob receives nothing without staking. Alice can only earn from these model-specific pools because she has a positive stake share.

Now suppose Bob has enough effective gmFLOCK for his multiplier to become 2×.

For the Global FLOCK pool, Bob’s score doubles, shifting the global split further in his favour.

At `α = 0.9`, Bob’s global score becomes `0.450 × 2 = 0.900`, while Alice’s remains `0.500`. Bob would earn roughly `64.3 FLOCK`, while Alice would earn `35.7 FLOCK`.

At `α = 0.5`, Bob’s global score becomes `0.250 × 2 = 0.500`, matching Alice’s `0.500`. Alice and Bob would each earn `50 FLOCK` from the Global FLOCK pool.

But gmFLOCK does not bypass the staking requirement for Reserved FLOCK or MT Reward. Since Bob’s incentive staking factor is still `0`, his incentive score remains: `0 × 2 = 0`.

So Bob can use gmFLOCK to boost his Global FLOCK share, but he still earns no Reserved FLOCK or MT Reward unless he stakes the corresponding MT.

**Reserved FLOCK / MT Reward Example**

| User  | usage\_share | stake\_share | incentive\_staking\_factor | incentive\_score |
| ----- | -----------: | -----------: | -------------------------: | ---------------: |
| Alice |          0.5 |          1.0 |                        1.0 |            0.500 |
| Bob   |          0.5 |          0.0 |                        0.0 |            0.000 |

Alice receives 100% of the Reserved FLOCK and MT Reward distributed for this MT. Bob receives 0 because he has no stake, even though he contributes 50% of API usage.

#### Common Reasons People Earn Less Than Expected

No usage on an MT = no reward share from that MT. Staking and gmFLOCK can boost an existing score, but usage is still the base demand signal.

No stake on an MT = no Reserved FLOCK or MT Reward from that MT. Heavy API usage can still earn Global FLOCK, but model-specific incentive pools are staker-gated.

Holding gmFLOCK does not bypass staking. gmFLOCK can multiply an existing score, but it cannot turn a zero incentive score into a positive one.

Using the wrong model ID may not count toward the intended MT. From Season 2 onward, usage attribution is expected to map more explicitly through model ID.

gmFLOCK close to unlocking may have lower effective weight. The gmFLOCK multiplier is based on effective gmFLOCK balance, which reflects both the amount held and the remaining lock duration. For example, a smaller gmFLOCK position with a longer remaining lock duration can have similar effective weight to a larger gmFLOCK position that is closer to unlocking.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.flock.io/flock-tokenomics/network-participation/fomo.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.