Introduction

Web3 infrastructure networks have emitted > $ 10 Bn in rewards over the past years, yet little research is available to understand how these emissions have been paid out and how different emission schedules look like. With this first article in a series we’re trying to bring a bit of light into the dark.

We define Web3 infrastructure networks as those in which a decentralized network of service nodes provides resources for use cases beyond security, e.g. compute, storage, message routing, access control.

Whilst that definition includes a wide range of protocols, those networks always comprise the same roles:

• Service nodes: provide the actual resource e.g. storage, compute etc.

• Validators: form consensus bout the fulfillment of services provided by other node types of the network

• Delegators (optional): token holders that stake their tokens with validators and/or service nodes

• Gateway (optional): orchestrate the connection between users and service nodes

Service nodes are the workers every network needs to organize. No service nodes, no service. Hence, we will focus on their reward incentives¹.

Specifically, we looked at the following projects:

• Storage: Arweave, Filecoin, Storj, Sia

• Compute: Livepeer, Akash, Render

• Data/message routing/mixing (incl. RPC): Pocket, Nym, Hopr

• Wireless network: Helium (LoRaWAN), Helium (5g), Pollen (5g)

• Data access/indexing: The Graph, Covalent

• Access Control: Nucyper

Hence, this list extends the networks monitored by the Web3 Index and is similar to Messari’s DePIN (Decentralized Physical Infrastructure networks) sector.

Overcoming the Chicken-Egg Problem: Ways to incentivize the supply side

The main idea behind the incentivization of supply is simple: At inception, when there is little demand and/or willingness to pay for the network service, supply needs to be subsidized via incentives to overcome the chicken-egg problem of lacking demand because of insufficient supply. There are three sources to compensate the supply side:

i) Share of network earnings/fees: as the network earns revenue from users paying for the services, service nodes get a share (if not all) — we’ll dig more into that in a separate article.

ii) Token rewards: funds allocated/minted by the network to incentivize the supply, typically based on stake and paid in the native token. This will be the focus for the remainder of this article.

iii) Other sources: For example, endowments funded by i) and/or ii)

The reward is available to the node operator after the work is validated, sometimes after a lock-up/vesting period (e.g. Filecoin). Typically rewards can be claimed by the service nodes, while some networks facilitate their payments via probabilistic micro-payments (e.g. Livepeer, Hopr).

Token rewards are the only source that networks can directly control by design, which is why we analyze these first. Considering existing reward mechanics, there are three aspects impacting the token reward design:

1. Total token supply: – Limited supply: The maximum supply of native tokens is limited. Unless there is a burn-mechanism, the rewards the network can distribute to node operators is limited as well and hence will eventually diminish – Unlimited supply: The network has some sort of inflation mechanism that will continuously mint tokens without any set limit.

2. Immutability: - Adjustable: Governance can vote to change the total token supply (1.) and/or the overall emission schedule (next point) - despite having the ability most networks didn't adjust their reward mechanisms to date (examples of those wo did: Pocket, Akash, Helium & Render²) - Not adjustable: There is no governance or the token supply and emission schedule are out of scope of governance (e.g. Arweave, Sia, Storj)

3. Emission schedule: How much of the supply is set aside for the node operator incentives and how it is allocated over time

The emission schedule offers greater complexity, which is why we discuss it separately in the following section.

Planning out the incentives: emission schedules

Emission schedules are the plan that defines the rate at which token incentives are distributed to node operators over time. That plan comes in form of a function, which has two dimensions:

Complexity of the emission function:

• Fixed: total rewards are only dependent on time or some variation of it like number of blocks (e.g. Bitcoin)

• KPI-driven: additional KPIs (Key Performance Indicators) impact the reward emissions. Note that this doesn't refer to the ability to adjust the schedules via governance we mentioned earlier. A famous example here would be Ethereum PoS rewards, as they are dependent on the amount of ETH that has been staked.

Shape of the emission function:

• Decaying: emitted rewards are decreasing towards zero over time (e.g. Bitcoin)

• Constant: emitted rewards follow a constant amount or rate

Storj isn’t shown in this graphic as storage nodes are paid fixed $-amounts for their services, i.e. there are no token rewards. Filecoin and Nucypher are represented twice as they have two components of their schedule falling into different quadrants. Let’s dig into each of the four quadrants to explain them a bit further:

1. Fixed and decaying

   In the spirit of Bitcoin, token issuance is reduced over time by a pre-set schedule. In the case of Bitcoin this means that every 210,000 Blocks (~4 years) the BTC issuance rate halves. Most networks in this quadrant also follow such exponential decay, but typically have shorter ‘halving periods’, e.g. Helium 2 years or Arweave ~1 year:

Example: Arweave

The other networks with fixed and decaying emissions are:

• Pollen: planned 50% of the total token supply for reward emissions for service nodes, validators and users, starting with 0.21% of total supply (2.1 M PCN) per week and halving once this pool decreased by ⅓, which is after ~1.5 years and a second time ~3 years after that. The split amongst the user groups depends on their participation detailed out here.

• Sia: started with emissions of 300,000 SIA per block (0.0067% of genesis supply), which were reduced by 1 coin each block until it hit the minimum emission of 30,000 SIA as blockreward in July 2020. These rewards are only paid to validators of the SIA blockchain, i.e. there are no token rewards for service nodes.

• Filecoin (simple minting): Filecoin has two ways to issue tokens, the simple and the baseline minting. The former issues rewards every block following an exponential decay such that they halve every 6 years (the latter is covered in the next section).

• Helium (LoRaWAN): After the adjustments (mentioned in the ‘Ability to adjust’ examples²), Helium halves the reward emissions every two years (starting with 2.2% of total supply (5 M HNT) per month). Hotspots get a yearly adjusted share of those³.

• Helium (5g): Helium’s mobile network started with daily reward emissions of 0.04% of total supply (100 M MOBILE), which will halve in August 2023 (after some adjustment in the course of the Solana migration) and then follow the HNT schedule of halvings every two years (see details). Service nodes are allocated 60% of that.

• Render: didn’t have token rewards yet, but approved the switch to a burn and mint model similar to Helium’s approach. Additional 20% to the current maximum supply of 536 M RNDR will be minted to be distributed as incentives to node operators in a decaying fashion.

Takeaway: Fixed and decaying token rewards keep things simple. Whilst fading out eventually, rewards are known at all times and hardcoded into the consensus — unless the governance surface allows the emission schedule to change there is no ability to adjust it making it likely that networks overpay.

2. KPI-driven and decaying

Networks in this quadrant also apply an emission schedule that is decaying to zero. A KPI-driven schedule means that these emissions don’t depend (only) on time.

Example: Filecoin

Filecoin has a dual minting model: simple and baseline minting. The former allocates 30% and the baseline minting allocates the other 70% of rewards (55% of the total supply of 2 B FIL). Baseline minting emits rewards according to its KPI of an (increasing) target baseline of storage capacity provided by the network: Whenever the actual storage capacity of the network exceeds the current target baseline, the rewards are capped.

The function describing those performance based rewards (actual vs. target capacity) expresses a decaying structure, where rewards halve as well, hence a KPI-driven and decaying emission schedule. The full math of that function is laid out here.

The other networks with KPI-driven and decaying emissions are:

• NYM: allocated a pool of 25% (250 M NYM) of total supply for mix-node rewards. Each 720 epochs (~1 month) a maximum of 2% is emitted (hence decaying, equivalent to halving every ~2.8 years). However, the actual amount depends on the number of active nodes and their performance. NYM also mentions that this reward pool is supposed to get refilled at a later stage with fees.

• Nucypher planned two phases with KPI-driven schedule, with phase 1 having constant and phase 2 decaying emissions: — Phase 1 planned constant emissions of ~25% of the maximum NU supply (~1 B) over ~5–8 years. This time range wasn’t fixed upfront as it depends on the share of circulating supply staked (stake rate)⁵ — Phase 2 planned exponentially decaying rewards, but the time for halving (between 2 and 4 years) depends on the time stakers lock their stake This approach was inspired by an analysis of staking behavior on four networks related to reward emissions (see here): data doesn’t show strong signs that stakers decrease stake when rewards decrease, rather the opposite

• Akash followed Nucypher’s phase 2 in their Whitepaper, i.e. exponentially decaying rewards with the halving period depending on the stake rate. Governance adjusted the halving period to 3.7 years early on and regularly adjusts the inflation targets².

Takeaway: Tying the decaying rewards to KPIs around network conditions can be a good middle-ground between being stuck with an upfront-fixed schedule and capricious governance, but comes at the cost of more complicated technical implementation, especially when it is built into the consensus algorithm. Additionally, if the demand side of the network isn’t part of the KPIs the network might run into the risk of over-incentivizing their supply-side nodes in the early stages of the network.

3. Fixed and constant emissions

Constant emissions refer to a constant amount or rate of rewards that the network distributes, e.g. 200 tokens per day or 3% inflation each year. The important difference to above quadrants is that emissions are not scheduled to decay to zero eventually.

It is also worth noting that constant emissions are only ‘flat’, i.e. constant over time if it is a constant amount that gets issued. If it is a constant rate, i.e. inflation, then the total supply grows and so does the issued amount as the following shows.

Example: The Graph

A 3% annual inflation (based on the full supply of GRT) is allocated to GRT stakers, which includes Delegators. This results in steadily increasing reward emissions as the total supply is also increasing (see dotted line below). GRT rewards claimed by indexers are a share of that (see here for details on the split).

Amongst our set of networks there are no other examples of a fixed schedule with constant emissions.

Takeaway: Formulating fixed and constant reward emissions is as easy and reliable as it gets. Especially with constant amounts they provide an equal playing field regardless of when nodes join the network. Though, they require either unlimited total supply or a separate burn mechanism. As with decaying fixed schedules it might be tough to calibrate the adequate emission rate upfront to achieve the right level of incentives and thus might be favorable when the network already has a lot of nodes onboarded and doesn’t require high incentives to bring in additional nodes.

4. KPI-driven and constant emissions

Constant emissions refer to a constant amount or rate over time (that is not decaying such that they approach zero). KPI-driven means that these emissions depend on some set KPI/variable and don’t depend (only) on time.

Example: Livepeer

There is a fixed rate at which staking rewards are emitted each round (5760 blocks), therefore a constant emission. This rate increases (every round) though if less than 50% of all LPT supply is staked and conversely decreases when over 50% are staked. Therefore the actual emission is dependent on this stake rate and not on time. The result is a token emission that doesn’t look very constant over time, only when the KPI (stake rate) is less volatile:

Example: Pocket

Another example is Pocket Network which has a RelaysToToken Multiplier that determines how much POKT is minted each day (and consequently paid as reward) for each relay a node services. Some share of those rewards go to validators of the Pocket-chain and to the DAO, but 85% go to the service nodes. As long as this multiplier stays the same this is a constant emission. It does not depend on time, but on relays serviced and hence follows a KPI-driven schedule.

The other networks with KPI-driven and decaying emissions are:

• Hopr follows a similar logic as NYM, but planned to allocate a constant amount per month for cover traffic, the actual emissions being subject to network conditions and governance⁶. The overall supply is still limited as those rewards are set to last only two years.

• Covalent is about to announce more details on their node rewards soon, but emission of constant amounts over time with a maximum of 2% of the total supply per year is planned. The actual amount depends on the amount and type of nodes that get rewarded. What you can read here and look into here is that currently node operators (and their delegates) get a constant emission of CQT based on the block specimen they produce.

• Nucypher: As mentioned earlier, phase 1 of Nucypher emissions was constant, yet the total time range for those are subject to the stake rate and hence monthly token rewards emitted are subject to that as well.

Takeaway: Constant emissions depending on KPIs are often as volatile as the KPI. They offer a high degree of flexibility, even more so when governance is able to adjust it. With great flexibility comes great complexity though — if one does not model and plan for the variety of potential scenarios one might run into situations which can put a lot of strain on the network participants.

Bringing it all together: the aggregated view on actual emission schedules

Let’s now take a look at how those emission-schedules look on a monthly basis. To make things comparable, we normalized token emissions by dividing token issuance by the maximum token supply the network aims to have. For networks with unlimited supply (SIA, Livepeer, Pocket, The Graph) we projected 10 years with current (net) inflation to get an estimate for the maximum token supply.

Decaying schedules start higher (0.5–1.5% of total token supply) whilst KPI-driven schedules are reactive to market environments affecting the underlying KPIs and therefore are hard to compare.

If we zoom out a bit further and look at all schedules, a common pattern is that peak of reward emissions (see the dots in the below graphic) is in the first year, Livepeer (~month 15) and Pocket (~month 19) - both in the KPI-driven, constant quadrant — are noteworthy exceptions (per its schedule designs The Graph and NuCypher don’t have a peak)⁸.

It is interesting to see that despite different schedule design and areas of infrastructure served (e.g. storage, compute, etc) the monthly issuance relative to total supply are in similar ranges initially at around 0.2% to 1.2%, before fading out beyond two years. Relative emissions for miner revenues of Bitcoin (dashed line, after 09/2010) and Ethereum (dotted line) are in similar ranges as well. This is also reflected in cumulative reward emissions:

“Dollar-emission” schedules

The last charts showed that token rewards are typically higher in the early phases of web3 infrastructure networks. One aspect of these rewards is to cover the investments that node operators made, which occur in fiat/dollars. When looking how the token emissions translate into ‘dollar-emission’ schedules, we see that they follow very different patterns:

The same divergence of emissions in token vs. dollar is visible for networks applying constant token emissions:

Outlook

While operating a variety of services, Web3 infrastructure networks follow a similar range of monthly reward emission (i.e. 0.2–1.2%), with decreasing emissions typically after 2 years. More recently launched networks seem to be on the lower spectrum of that range — this seems to be related to higher market capitalization of those networks when they start their rewards emission, but needs more research.

The dollar-values of those emissions are often quite different, impacted by price fluctuations. Those are relevant if we consider that part of the operating cost for service nodes need to cover the costs (sooner or later): excess emissions (in $-terms) as seen in the bull-markets are not a problem per se, but they can lead to excessive sell pressure (profit taking) of node operators. This in turn might lead to downward pressure on the token price triggering a downward spiral as operations become less profitable and force even more selling of tokens. In the worst case, node operators might even decide to shut down operations to the extend that it impacts the network supply capacity negatively.

To dig deeper, we need to consider both additional incomes (i.e. the fee side of networks) and a better understanding of the cost side — both subjects of future research.

If you are designing a token model for your web3 infrastructure project then please reach out @KoschigRobert on Twitter!

Appendix

This article is based on this paper, where more details e.g. on the networks and the data sources are presented .

Footnotes:

1. Note also that the presented data on reward emission is not limited to service nodes for all networks — see the paper for details on which roles of the supply-side are included in the data presented

2. Pocket regularly revisits and adjusts their monetary policy and parameters; Akash does so as well and just started a discussion around updating their economics; Helium changed the fundamentals of their mechanics early on: first to stop participants gaming the incentives and then to cap total supply; Render just introduced governance that decided to switch to a Burn and Mint model (see details)

3. Details are laid out in HIP 10

4. See here for details on the Filecoin Baseline crossing

5. Besides the stake amount users were able to increase their stake weight by locking their stake up to a year to get more rewards. The less stakers do so, the lower overall emissions and hence the longer phase 1 (see details in section III.)

6. Cover traffic is not live yet, but Hopr is using a staking program as placeholder currently to gradually work on implementing the envisioned mechanism of incentives via cover traffic.

7. Bitcoin miner revenues start in month 21, hence the halving at month 28 (corresponding to 4 year halving) — we couldn’t find miner revenues prior that

8. The peak of NuCypher is the last month of emissions before the merger into the Threshold network. The peak of The Graph shown is one of the last data points available.

9. Filecoin: incorporated the 180 days linear unvest of 75% of the emitted token rewards for the conversion to dollar values. Helium MOBILE, Pollen and NYM haven’t seen their emission reductions yet, hence no decline in the dashed lines yet

10. NuCypher shows emissions of phase 1 before merger into Threshold network, worklock token emission not included; Hopr: As mentioned earlier, cover traffic hasn’t launched where monthly token emissions are planned to be 1% of total supply until month 27; Covalent nodes couldn’t fully claim rewards between month 3 and 7 related to the Nomad hack on Moonbeam