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 | ||||||
B | ||||||
C | ||||||
D | ||||||
E |
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.