SPP-1: Separated Project Type Based Rewards Pool

SPP-1: Separated Project Type Based Rewards Pool

Author: Ian He
Created: 2024-09-30
Status: Draft
IPFS Link:

Motivation

There are two sources for rewards on the SubQuery Network:

  • Reward for productive work (query rewards): This is the existing reward structures with the project with the various payment methods that we have pioneered, e.g. serving requests in valid service agreements or flex plans.
  • Network inflation rewards: This is allocated to all Indexers for successfully running projects and serving requests.

In our vision, as the network matures, rewards for productive work will dominate network inflation rewards. However, we understand that in the early days, we are currently leveraging network inflation rewards to help bootstrap the network as applications get deployed and the end user base scales.

Network Inflation rewards are evenly split across projects based on the boost allocated to each project, and at the moment is largely on RPC projects. This is because with boosting a project, Consumers receive free queries to that project, something that this group finds useful with RPCs. You can read more about this here.

Today also, RPC projects are receiving a much larger volume of query rewards, and therefore, a much higher volume of total rewards on the network, than data indexing projects. For node operators who favour running data indexing projects, they are not receiving as much rewards as RPC node operators, even though they are still doing good work.

If we can not address this conflict, it is difficult to add more RPC projects to the network without detriment to the network inflation rewards that indexers receive.

Proposal

The current reward model is a single network inflation reward pool where an issuancePerBlock parameter is specified which determines the quantity of a global reward pool. This reward is then shared between all project types (SubQuery project, RPC endpoint, AI project, and Subgraphs ).

We propose to update the network inflation model to instead have a different reward pool based on the project type. With a project based reward pool, the different project types such as SubQuery project, RPC endpoint, AI project, and Subgraphs can have a different issuancePerBlock parameter which then contributes to each individual project type reward pool.

Additionally, high boost amounts on a RPC project will not affect how the network inflation rewards that are distributed amongst SubQuery or Subgraph projects.

Assume a situation where:

  • IssuancePerBlock is 4 SQT per block
  • For a given period of time, the accumulated total reward is 2.4M SQT
  • There are 6 projects:
    • Projects #1-3 are SubQuery Indexing Projects;
    • Projects #4-6 are RPC projects.
  • Node Operator C only run subquery projects
  • Their Boosted amounts are as follows:

Consider the following scenario:

Node Operator Project #1 (SQ) Project #2 (SQ) Project #3 (SQ) Project #4 (RPC) Project #5 (RPC) Project #6 (RPC)
A :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark:
B :white_check_mark: :white_check_mark: :white_check_mark:
C :white_check_mark: :white_check_mark: :white_check_mark:
D :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark:
E :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark:
Project Type Boost (SQT)
Project #1 SubQuery 1K
Project #2 SubQuery 2K
Project #3 SubQuery 1K
Project #4 RPC 8K
Project #5 RPC 6K
Project #6 RPC 6K

Other parameters are:

  • Network Inflation Reward Ratio for SubQuery is 70%
  • Network Inflation Reward Ratio for RPC is 30%

The following is how the reward distribution looks currently. Because RPC projects have more boost SQT than non-RPC projects, more rewards go to these projects.

Considering more boost is allocated to RPC projects, more rewards will be shifted to consumers and non-RPC node operators will suffer a loss. (especially those who don’t run rpc projects like Node Operator #3)

Implementation

After this proposal, while SQT IssuancePerBlock is still 4 per block, we can split it to

  • For SubQuery projects, IssuancePerBlock = 2.5
  • For RPC projects, IssuancePerBlock = 1.5

Then we will have more rewards towards Node Operators, and even if more boost is allocated to RPC Projects, Node Operator #3’s rewards won’t get affected.

2 Likes

This makes a lot of sense and seems aligned with the long-term health of the network. Can I assume that the implementation will allow further tuning of reward distribution if new project types are introduced? As in they can be balanced without additional contract changes?

2 Likes

Correct, it’s designed so we can easily update the parameters or add new pools as new project types are added to the network

2 Likes

WOW!
Impressive numbers for some Nodes!

Maybe SPP-1 should be applied soon!

Top 1 Run RPC only. And stake 200K, rewards 81K/week

1 Like