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.