There has been a fair amount of discussion around the imbalance of early bonding curve positions vs the query fee portion of the curator incentives.
While we have started discussion on how to ensure there is a fair launch for a subgraph (and a group of curators are working on a GIP for this side), I wanted to start the discussion on how to best address the query fee side of our incentive structure.
Curators are currently solely reliant upon query fees as the positive factor to our leg of the network. With the economics of the network, I think we should remain query fee focused.
There has been 9m GRT used for signal transactions and roughly 23,700 GRT that has been added as curation rewards. This means that curators have paid roughly 225,000 in tax (excluding the tax paid from auto-migrate).
Idea #1
The 3% inflationary rewards granted to indexers (and their delegators) has been utilized as a stipend while the network bootstraps to steady state. As the mainnet builds more query fees the indexing rewards become a smaller percent of an indexer’s income.
A similar system could be set up for curators without removing our attention off of query fees.
By adjusting the inflationary rewards from 3% to 2.9% for indexer rewards and utilizing the other 0.1% to amplify the GRT brought into the State Channel Settlement. 10% of this would be go to the curator reserve for the subgraph and 89% would move to the rebate pool.
This has the added benefit that indexers who are serving queries on the network are going to be largely unaffected and those who are ‘rent seeking’ will become less profitable.
TLDR: Opening discussion about changing the 3% indexer rewards to 2.9% indexer rewards and 0.1% query fee amplification.
9 Likes
I think this is a great idea and should be considered further… in my opinion the only question is whether that .1% will be enough to fix the issue. With curation being an essential role in the decentralized protocol I believe it could merit a proportionally higher percentage than what we see in this proposal (96.67% of inflationary rewards are still being seen by indexers and not curators)
4 Likes
My calculation for this number was primarily based off the concept that a curator should receive a higher reward if they are actively spending time evaluating subgraphs and thus providing value to the network by filtering out the bad subgraphs.
Since 90% of the query fees go to indexers and their delegators this would would mean roughly 2760 GRT is added to the curator reserves though an amplification of query fees.
The other 90 would then benefit indexers and the delegators who those who are actively serving queries (the final product of the network). As these indexers become more profitable comparatively, delegators are incentivized to flock behind those that are doing good work.
Based on the GRT added into the curation market, this gives room for a ‘bootstrapping crew’ to grow and the mainnet’s production will outproduce this incentive as we reach steady state.
2 Likes
As an idea, it will be better to provide free queries to all subgraphs in the decentralized network for 30M queries per month per subgraph. With paid queries after this limit monthly. It will be easily covered by the same 0.1% inflation.
For now, we don’t have any subgraph that will be even close to this number of queries per month.
It will also give more to Curators and Indexers, who work with queries.
If 0.1% will be not enough, it could be donated by Foundation instead of spending $ on hosted service.
A lot of services work like this and it helps them to increase their userbase.
@adamfuller
4 Likes
One knock-on effect of this approach though would be that we would lose the the price discovery dynamic that is sought between consumers and Indexers. Indexers would in fact just become incentivized to increase their per-query pricing to extract what they could (I’m over simplifying, but I think the point still stands)
2 Likes
If someone will increase price per query, others will get more queries if they don’t change their prices, isn’t?
On the indexer side it would have to amplify their query fees redemption by the same factor.
It seems like indexers would work to try to be the one who serves the queries (thus incentivizing better configurations). If an indexer set a price of 0.000001 DAI attempting to get all of the queries they should only be able to redeem their price * the amplification factor. They would essentially be cutting their rewards short while still trying to do all the work.
I support this proposal. Looking forward to hearing others’ input!
I’ve been thinking about this over the past week, it seems more and more to me like it will actually expedite the price discovery aspect.
Current scene is indexers do not rely on query fees, thus the attention put into price negotiation through the market is minimal.
Through this bootstrapping activity, it will start putting indexer attention on producing queries and maintaining their configuration as well as their pricing to fight to serve queries.
This is an interesting thread: by subsidising query rewards, this encourages the core action in the protocol (users querying indexed subgraphs). It incentivises those who have signalled on a subgraph to keep signalling (rather than the bulk of their reward being the sale value back into the bonding curve), and it encourages indexers to seek query rewards, as well as indexing rewards (which are currently the bulk of an indexer’s return). Would be keen to hear @Brandon and @ari’s take.
@KonstantinRM I think your suggestion around free queries up until a point is a separate (also interesting) angle - discussed in some detail in this thread.
2 Likes
Thank you, Adam. I missed this thread, quite interesting, but the topic starter had totally different idea 
I’m more with you regarding this topic and add some colors and details.
I think here should be highlighted 2 points:
- Transfer some value from Indexing rewards to support queries. Some kind of accumulative fund for covering the first X queries monthly, or just for the first X queries.
- Incentives Subgraph developers to host on Decentralized Network instead of hosted service. For now we provide 2 alternatives:
a) use hosted service for free; It’s quite good, resistant, but not for 100%.
b) use the decentralized network for money from the beginning and pat for every update; It’s better, more resistant.
I think it will be nice if Foundation (or E&N, idk) will incentivize to use decentralized version, not hosted service. It’s just an additional idea, that can help to boost the speed of migration, especially if hosted service will be more restricted in free service.
1 Like