Reward Emission: Halving, Decay Curves, and GameFi Rewards

In the five supply models overview, the reward model is described briefly: “new tokens are created as rewards for useful actions.” But it’s in the design details where the biggest opportunities and traps hide. Too generous an emission kills the token price. Too stingy — fails to attract participants. This article covers the math, types, and practical design of reward models.

What Is the Reward Model

Reward model is a supply model where new tokens are minted as rewards for targeted actions in the system. Unlike allocation, where tokens are distributed upfront, in the reward model tokens appear only when a participant performs useful work.

Three key components:

1. Targeted actions — what exactly is rewarded (block validation, providing hashrate, gameplay, data provision)
2. Reward size — how many tokens a participant receives per action
3. Emission curve — how the reward size changes over time

Types of Reward Models

Consensus Rewards

Tokens are created for maintaining network operations:

Consensus rewards are the purest case of the reward model: tokens are created strictly for work necessary for the network to function.

Game and Product Rewards

Tokens are created for in-product activity:

Staking Rewards

A subtype combining the reward model with the staking mechanism:

Staking rewards create a positive feedback loop: the participant locks tokens (reducing sell pressure) and receives new ones (increasing supply). Balancing these forces is the main design challenge.

Emission Mathematics

Decaying Emission (Halving)

The classic solution to the inflation problem — decaying emission, where reward size decreases on a schedule.

Halving guarantees a finite supply (for Bitcoin — 21,000,000 BTC) and declining inflation. But it also creates a problem: when emission becomes too small, will fees alone be enough to motivate miners?

Linear Decaying Emission

An alternative to halving — linear reward reduction:

Activity-Linked Emission

In product reward models, emission is often tied not to time but to participant count:

This model directly links emission to product growth: more users → more actions → more tokens created. Advantage: connected to real system development. Risk: during rapid growth, emission can become uncontrollable.

Designing a Reward Model: Step by Step

Step 1: Define Targeted Actions

Which actions create value for the system? Each action must have a measurable contribution.

Step 2: Set Weights for Each Action

Not all actions are equal. Weight determines how many tokens a participant earns:

Step 3: Forecast Participant Count

A reward model requires a user growth forecast because emission depends on the number of actions:

Step 4: Calculate Emission and Check Sustainability

Combining actions, weights, and participant counts yields an emission forecast. Sustainability criterion: emission must not exceed the value created.

Example for an app acquiring 300 users/month with 5% churn:

Over 12 months, the system emits ~71.2M tokens. If total supply is capped at 1B — that’s 7.1% per year. Key question: are users creating value commensurate with this emission? If not — action weights are too high or the model needs a decaying multiplier.

actions = {
    "register":        {"weight": 3000, "pct_users": 0.90, "once": True},
    "avatar":          {"weight": 2000, "pct_users": 0.80, "once": True},
    "invite_3":        {"weight": 5000, "pct_users": 0.40, "once": True},
    "trading_volume":  {"weight": 8000, "pct_users": 0.20, "once": False},
    "transaction":     {"weight": 4000, "pct_users": 0.30, "once": False},
}

acquisition_month_1 = 100
acquisition_per_month = 300
churn_rate = 0.05
months = 12

users = 0
total_emission = 0

for m in range(1, months + 1):
    new_users = acquisition_month_1 if m == 1 else acquisition_per_month
    churned = int(users * churn_rate)
    users = users - churned + new_users

    month_emission = 0
    for name, a in actions.items():
        if a["once"]:
            eligible = new_users * a["pct_users"]
        else:
            eligible = users * a["pct_users"]
        month_emission += eligible * a["weight"]

    total_emission += month_emission
    print(f"Month {m:2d}: users={users:,}, emission={month_emission:,.0f}, cumulative={total_emission:,.0f}")

Common Mistakes

Reward model traps

Reward vs Other Supply Models

The reward model is essential for projects where stakeholders perform work for the network. But it requires careful mechanism design to ensure emission doesn’t exceed the value created.