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

# Rewards Case Study

Almost all rewards delivered to operators are dependant on the total number of *other* operators providing the same service (relays, authorities, even staked tokens!) and their relative quality. Hence, any estimations into per-user token rewards must cast assumptions on this value.

The following section is an example breakdown of rewards in different scenarios. None of it is to be taken as a guarantee or as formal advice - your token rewards, especially in the early days, could vary significantly. Throughout this section, all relays are considered to earn equal rewards and thus create projections for *mean* rewards.

### Fixed Emissions By Year

Here we outline the tokens emitted per category per year - this is fixed regardless of the number of relays

<table data-full-width="false"><thead><tr><th width="226">Reward Constants</th><th> All Relays </th><th>HW Bonus </th><th> Stakers </th></tr></thead><tbody><tr><td>% Rewards Emitted</td><td>70%</td><td>20%</td><td>10%</td></tr><tr><td>% of pool emitted daily</td><td>0.100%</td><td>0.100%</td><td>0.100%</td></tr><tr><td>% of pool emitted yearly</td><td>31%</td><td>31%</td><td>31%</td></tr></tbody></table>

This naturally leads to the following base tokens emitted per category for each year

<table><thead><tr><th width="98">Year</th><th width="138">Tokens in Pool </th><th>Emitted </th><th>Emitted All</th><th> Emitted HW </th><th> Emitted BW </th></tr></thead><tbody><tr><td>1</td><td>10,000,000</td><td>3,059,301.13</td><td>2,141,510.79</td><td>611,860.23</td><td>305,930.11</td></tr><tr><td>2</td><td>7,140,698.87</td><td>2,184,554.81</td><td>1,529,188.37</td><td>218,455.48</td><td>436,910.96</td></tr><tr><td>3</td><td>5,456,144.06</td><td>1,669,198.77</td><td>1,168,439.14</td><td>166,919.88</td><td>333,839.75</td></tr><tr><td>4</td><td>4,786,945.29</td><td>1,464,470.71</td><td>1,025,129.50</td><td>146,447.07</td><td>292,894.14</td></tr></tbody></table>

### Year-1 Emissions Per Scenario

The following tables show the mean base rewards (rewards without the inclusion of premium rewards or refilled token pools) for different numbers of total active relays in the network. In reality, for a given number of relays, a proportion are likely to be non-performant and thus leave more rewards for consistently active operators.&#x20;

#### Regular Relays

| Relays: | 2,500.00 | 10,000.00 | 25,000.00 | 50,000.00 |
| ------- | -------- | --------- | --------- | --------- |
| Year 1  | 856.60   | 214.15    | 85.66     | 42.83     |
| Year 2  | 611.68   | 152.92    | 61.17     | 30.58     |
| Year 3  | 467.38   | 116.84    | 46.74     | 23.37     |
| Year 4  | 410.05   | 102.51    | 41.01     | 20.50     |

#### Hardware Relays&#x20;

<table><thead><tr><th width="175">Hardware Relays</th><th>1000</th><th>5000</th><th>10000</th><th>10000</th></tr></thead><tbody><tr><td>(Regular Relays)</td><td>2,500.00</td><td>10,000.00</td><td>25,000.00</td><td>50,000.00</td></tr><tr><td>Year 1</td><td>1,468.46</td><td>336.52</td><td>146.85</td><td>104.02</td></tr><tr><td>Year 2</td><td>830.13</td><td>196.61</td><td>83.01</td><td>52.43</td></tr><tr><td>Year 3</td><td>634.30</td><td>150.23</td><td>63.43</td><td>40.06</td></tr><tr><td>Year 4</td><td>556.50</td><td>131.80</td><td>55.65</td><td>35.15</td></tr></tbody></table>

## Case Study With Assumptions

This case study is based on assumptions on the total number of active relays at the end of each  year. However, for the purpose of net relay rewards for the year, the *average* number of active relays in the year is more accurate.

#### End-of-Year Active Relays or Staked Tokens

| (End of) Year | Virtual Relays | Hardware Relays | Tokens Staked |
| ------------- | -------------- | --------------- | ------------- |
| 0             | 3,000.00       | 500.00          | -             |
| 1             | 10,000         | 2,500           | 1,000,000.00  |
| 2             | 30,000         | 5,000           | 2,000,000.00  |
| 3             | 50,000         | 10,000          | 3,000,000.00  |
| 4             | 0,000          | 10,000          | 4,000,000.00  |

#### Year Average Number of Relays

| Year | Virtual Relays | Hardware Relays | Tokens Staked |
| ---- | -------------- | --------------- | ------------- |
| 1    | 6,500          | 1,500           | 500,000       |
| 2    | 20,000         | 3,750           | 1,500,000     |
| 3    | 40,000         | 7,500           | 2,500,000     |
| 4    | 50,000         | 10,000          | 3,500,000     |

#### Yearly Assumptions - Inflow to Reward Pools

Given these average active relays values, we can form an additional assumption - the total token inflow for premium rewards that enter the general reward pools.&#x20;

<table data-full-width="false"><thead><tr><th>Year</th><th> Token Inflow </th></tr></thead><tbody><tr><td>1</td><td>0.00</td></tr><tr><td>2</td><td>200,000.00</td></tr><tr><td>3</td><td>500,000.00</td></tr><tr><td>4</td><td>1,000,000.00</td></tr></tbody></table>

#### Relay Rewards By Category

Thus, we can form the projected number of tokens rewarded, on average, to each relay type.

| Year | Virtual Relays | Hardware Relays |
| ---- | -------------- | --------------- |
| 1    | 267.69         | 675.60          |
| 2    | 64.39          | 122.64          |
| 3    | 24.60          | 46.85           |
| 4    | 17.09          | 31.73           |

#### Staking APYs

We can also consider the staking 'APY' (percentage yield) on tokens delegated to bandwidth alternative.

| Year | APY |
| ---- | --- |
| 1    | 61% |
| 2    | 29% |
| 3    | 13% |
| 4    | 8%  |

#### Total Tokens Locked&#x20;

We can alternatively consider a minimum return that holders expect, before they stake tokens. Given that staked tokens only have a 14-day unstake period, the required premium could be as low as 5%. We can add this to the tokens locked for relays to get an estimate, on the above assumptions, for the total tokens that may end up being locked up.&#x20;

| Year | Relay Staked | BW Staked    | Total Staked  |
| ---- | ------------ | ------------ | ------------- |
| 1    | 1,000,000.00 | 6,118,602.26 | 7,118,602.26  |
| 2    | 3,000,000.00 | 8,738,219.25 | 11,738,219.25 |
| 3    | 5,000,000.00 | 6,676,795.07 | 11,676,795.07 |
| 4    | 5,000,000.00 | 5,857,882.85 | 10,857,882.85 |

## Uptime Quality Tiers

The introduction of uptime quality tiers will see 20% of normal relay rewards (the pool of 7,000,000 tokens) allocated purely to relays that demonstrate consistent uptime as opposed to raw bandwidth. This biases the network slightly towards smaller operators who nevertheless maintain their relays, making rewards slightly more egalitarian and rewards more accessible for home setups.&#x20;

| Points     | 0-3 days | 3-14 days | 14+ days |
| ---------- | -------- | --------- | -------- |
| All Relays | 0        | 1         | 3        |

**Assumptions**\
Average Non-Hardware Relays Y1: 6500\
Average Hardware Relays Y1: 1500&#x20;

We can also assume the following distribution of relays and their average 'uptime status'&#x20;

| Proportion | 0-3 days | 3-14 days | 14+ days |
| ---------- | -------- | --------- | -------- |
| Hardware   | 30%      | 30%       | 35%      |
| Other      | 20%      | 20%       | 50%      |

Based on this, we get an idea of the delta (addition or reduction in yearly rewards) for being consistently in different categories

| Delta (year) | 0-3 days                               | 3-14 days    | 14+ days    |
| ------------ | -------------------------------------- | ------------ | ----------- |
| Hardware     | <mark style="color:red;">-53.53</mark> | -20.78043454 | 44.73423592 |
| Software     | -53.53776977                           | -20.78       | 44.73423592 |


---

# 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.anyone.io/tokenomics/summary/rewards-case-study.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.