GIP-0063: Optimizing Query Fees sent to Indexers

[howard]

GIP-0063: Optimizing Query Fees sent to Indexers

Authors: Howard
Created: 2023-11-08
Updated: 2023-11-10
Stage: Draft
Category: Economic Parameters

Abstract

Today, at least 11% of query fees paid by data consumers do not ever make it to either the Gateway or the Indexers that provide the service to the data consumers. This GIP aims to reduce these transactional costs. This can be done without changing any smart contract code; instead, only two parameters need to be tweaked: removing the fees sent to curators and setting the protocol tax to zero. This will simplify how the protocol operates and potentially save GRT both for developers and Indexers.

Introduction and Motivation

Curation in The Graph is mostly used by dapp developers to incentivize Indexers to index subgraphs. This is a necessary step to take before Indexers serve queries for a subgraph. Today, much of the curation on The Graph Network running on Arbitrum is from dapp developers providing their GRT to buy curation shares, signaling to Indexers that they want a subgraph indexed. Once the developer begins paying for queries, 11% of the fees are directed to parties other than the Gateway or relevant Indexer. The protocol can be simplified by removing this 11% cut being redirected and save GRT for both developers and Indexers.

Prior Art

The existing smart contracts for The Graph route 10% of query fees to the curation pool and burn 1% of query fees. The proposal does not require any changes to the code/logic of the contracts; instead, it just requires changing the values of two parameters. Two related GIPs also aim to increase the efficiency of operations for participants in The Graph ecosystem. These include GIP-0051 that resulted in Indexers keeping a notably larger portion of query fees (by replacing Cobb-Douglas) and GIP-0059 about removing a tax on subgraph owners (to reduce the costs born when upgrading).

High Level Description

Of the total query fees generated, 1% are burnt, 10% are sent to curators on the relevant subgraph, and the remainder is sent to the Indexer (after going through the Exponential Rebate mechanism). This proposal is to set 0% of query fees to be burnt and 0% to be sent to curators on the relevant subgraph, with all of the remaining portion to be sent to Indexers via the Exponential Rebate mechanism. This change would only be applied to the protocol on Arbitrum.

Detailed Specification

To deploy this GIP, the Council would have to:

• Set the curation percentage to zero by calling L2Staking.setCurationPercentage(0)
• Set the protocol tax to zero by calling L2Staking.setProtocolPercentage(0)

These two can be executed in a single transaction batch.

Rationale

The rationale for this proposal is to reduce unnecessary frictional costs and simplify how the protocol operates. Below we expand upon two aspects of reasoning for this change, along with a note about the evolution of the curator role.

Elimination of Circular Flow of GRT for Developers

Consider a dapp developer that aims to have their subgraph indexed. On Arbitrum today, the developer can buy curation shares with GRT to provide “signal” to Indexers. Even after an Indexer decides to index the subgraph, the developer typically keeps their GRT deposited in the curation shares. When the developer then pays for queries, 10% of these are routed back to the subgraph’s holdings. If the developer is the only curator on the subgraph, this means 10% of the GRT they paid toward query fees goes back to themself, minus the transaction fees involved (e.g. in selling the curation shares). This circulating of query fees back to the developer can be completely avoided by implementing this proposal. This would save the developer GRT and remove an unnecessary but cognitively burdensome mechanism from the protocol.

Revenue to Indexers

Today Indexers get a portion of query fees. Of the total, 1% are burnt, 10% are sent to curators on the relevant subgraph, and the remainder is sent to the Indexer (after going through the Exponential Rebate mechanism). Thus, even with the improvements in the proportion of query fees collected by Indexers as a result of Exponential Rebates, Indexers can collect at most 89% of query fees. We can increase this by 11%.

What about Curators?

Curation was originally designed as a way to incentivize independent third parties to identify “valuable” subgraphs. Unfortunately, this has not come to fruition for one main reason: the party that is often best informed about the value of a subgraph is the dapp developer. As a result, a large amount of curation has simply been “self-signaling” and is functionally a mechanism for developers to pay (in terms of cost of capital) to have their subgraphs indexed. While providing incentives to identify useful information is a valid goal for a protocol (that is indeed the business model of journalism and news enterprises, among others), the current curation mechanism does not achieve this. So while core dev teams in The Graph will consider and research alternative curation mechanisms in the future, this proposal will remove the currently ineffective incentive for third-party curators.

Risks and Security Considerations

The removal of 10% of query fees going to curators eliminates direct financial gain as an incentive for curators. Consequently, curators that are not dapp developers (or another role in The Graph ecosystem) may be expected to sell their curation shares. Since this proposal will only affect query fees on Arbitrum, curators can sell their shares without any loss from their originally deposited GRT.

Since the proposed update is merely a parameter change and does not require any changes to the code in smart contracts, minimal risk is expected with respect to introducing smart contract exploits. No external audits are planned; however, we recommend that the two transactions required for implementing this proposal are tested using simulation and on Testnet before executing in production.

Future Directions

Since this proposal removes direct incentives for third-party curators, future directions will include researching alternative curation incentives and consider whether such a mechanism is in scope for The Graph protocol.

Copyright Waiver

Copyright and related rights waived via CC0.

[That3Percent]

Nice work Howard.

I think this proposal is important because it makes the protocol more efficient. When the protocol directs fees toward users that aren’t providing value, this results in higher costs to consumers and/or lower profit for indexers.

To give a simple example - imagine an apple costs $1 to produce. If only 89% of the payment makes it from consumer to producer then the producer would have to charge at least $1.12 to break even ($1.12 * 89% ~= $1.00). Friction like this ultimately leads to a smaller addressable market for The Graph as consumers faced with unnecessarily high prices may seek to meet their data needs elsewhere. I say “unnecessarily” high prices intentionally - since as you argue the consumer / indexer aren’t directly benefiting by paying these taxes.

[That3Percent]

One thing to note is that one purpose of the 1% query fee tax is to deter query spoofing. That is, individuals paying themselves to create the impression of demand.

I think that removing this deterrent is the right trade-off. It’s better to allow query spoofing than to punish all users. Even using the tax as mitigation, we need to accept that in a permissionless protocol query spoofing can be expected to exist (Rationality is Self-Defeating in Permissionless Systems). We can’t rely on query volume metrics in a permissionless system with or without this tax, so if the tax isn’t buying us anything we may as well remove it for the benefit of actual users.

Another thing to note here is that with collateralized security there is an intrinsic cost of capital that acts as a deterrent to query spoofing already. The cost of capital for collateralized security is paying for something - unlike this tax. It’s a more natural mechanism.

[Oliver]

Thank you for this proposal and the effort to achieve improved overall economics and efficiencies in the protocol. I agree that the Curator role has not achieved fulfilling its desired purpose and I look forward to seeing the details of future proposals for a holistically improved economic design.

My first thought about this proposal were the potential unintended consequences and whether it is really true to say: if the Curator role (in this case meaning: 3rd party Curators) is not fully achieving its mission in the protocol, it is better to essentially remove it altogether WITHOUT changing anything else in the current design?

Subgraph signal by owners

Anecdotally speaking, I can recall a number of instances where dapp developers/owners are pinging Indexers in discord asking them to allocate to their subgraphs, which often has not happened yet due to no or too low signal after publishing it. How well do subgraph devs/owners understand the need to put a signal on their subgraph? Using data from GraphLooker, I have researched some data across all 476 subgraphs published on Arb. Here is some interesting data. First, I have looked at how often a subgraph was published with any signal on it:

The majority of subgraphs on Arb have been published without any signal, almost 75%. This was a surprisingly high number to me and I was wondering how many times do subgraph owners put any signal on their subgraphs (either when publishing or any time thereafter):

Currently, more than half of the subgraphs on Arb do NOT have any signal provided from the subgraph owner. Subgraph owners could certainly use a different address for curation, though I’m not sure how common such an approach is. I do think the data suggests that there is a significant risk for a relatively high number of subgraphs to end up with no signal if 3rd party Curators would remove their signal in response to this GIP.

Curation dynamics in practice

I have looked through a number of subgraphs trying to identify a trend, and one of the most important dynamics I thought of was the indexer-allocation-to-signal relationship. I have found a few subgraphs that follow some similar patterns to the subgraph below, which is dodoex-v2-arbitrum which has currently the 18th strongest signal amount on Arbitrum:

The subgraph was published on May 4th with no signal from the dev/owner. A few hours later a signal of 2.2K was placed by what looks to be a 3rd party Curator. For 12 days, that low signal only attracted an average of 2 Indexers with relatively low allocations. On May 16, the owner then put an 8K signal on it, possibly after having learned that a decent amount of signal is required to attract Indexers. That worked for about two weeks but then Indexer coverage dropped sharply. At that point, another 3rd party Curator steps in with an additional 20K signal. At that point, this subgraph has significant signal and from there on out it gets covered by an average of 7 Indexers: stability

Looking at this example (of which there are in fact many others as well), I was thinking: Yes, curation overall hasn’t worked out well, but that doesn’t mean it never works! There are in fact enough examples out there where the curation dynamics works for all parties involved (Curators receiving querying fees, dapp owners getting solid Indexer coverage, Indexers getting quality signal from Curators).

Discussing the impact

What happens to quality (i.e query generating) subgraphs that are currently experiencing healthy curation dynamics when the Curator role (again, meaning 3rd party Curator) gets eliminated in isolation (without any other protocol design changes)? The following chart shows how much signal subgraphs receive in total on Arb by either its owner or 3rd party Curators:

Most of the signal on Arbitrum does in fact come from their owners, good news. There is still an amount of 941K GRT of signal that would be at high risk of leaving the curation market since there is no longer an economic incentive associated with it, and that could result in no signal for a relatively high number of subgraphs.

I did not write this post to advocate against this GIP, but rather put some numbers out there to stimulate discussions on the potential impact this GIP might have on existing subgraph owners and Indexers. I would love to hear how other stakeholders interpret this data and if there are also other considerations to factor in.

[CryptoWing]

If you set the query fee tax to 0%, does that mean we are eventually going the route of inflationary only tokenomics? What deflationary pressures will there be for the GRT token?

Is it a wise thing to do this now? Why not just do away with they curation fees but keep the query fee tax intact?

[Hack1ge]

I agree - the burn fees are necessary to help offset emissions and aren’t in the best interest of token holders.

[CryptoWing]

I would further elaborate these “token holders” to also include indexers, delegators, and even consumers.

With an inflationary only mechanism and lackluster demand for GRT we will see a downward spiralling price of the token, like it has been doing since inception.

Delegation right now is barely worth it, and I think some delegators like me are banking on the query fee tax eventually being big enough to offset any inflationary pressures.

I would even further suggest that the query fee tax should be increased to 3% if curation fees are removed, to promote price stability.

I also think removing all curation fees should only be done after there is an alternative mechanism to signal which subgraphs should be indexed. Such as what is discussed in GIP-0058

[PaulieB]

Hi everyone,

After reading Howard’s post on fee distribution, I have a few questions:

@howard

Today Indexers get a portion of query fees. Of the total, 1% are burnt, 10% are sent to curators on the relevant subgraph, and the remainder is sent to the Indexer. We can increase this by 11%.

1. Indexers will now receive the 10% fee previously allocated to Curators? Just confirming since not 100% clear.
2. What’s the timeline for implementing these changes? It’s important for Curators and projects to have enough time adjust. Either removing 3rd party signal or adding sufficient self signal.
3. How will these changes impact Indexer rewards, especially if there’s a lower signal? How can we maintain same indexer support to subgraphs that may loose significant signal?

Thanks for shedding light on these points!

[DataNexus]

@howard

Today, at least 11% of query fees paid by data consumers do not ever make it to either the Gateway or the Indexers that provide the service to the data consumers.

When you say that it does not ever make it to the gateway, it sounds like this means the consumers query fees aren’t making it to the intermediary for indexers to receive a voucher to claim. Can you expand on this part or help correct my understanding?

@howard

As a result, a large amount of curation has simply been “self-signaling”

This may be true by total signal volume. But the subgraphs few that are actively generating query fees appear to have market curators signaling (non-self-signal).

If we look at the largest signal subgraphs without substantial query fees (less than 10 GRT), very few have other curators adding to the self-signal:

It seems that arbitrum is largely self-signal dominated due to a lack of query fees. But there are some curators who are still adding value.

I think the existing curators who are signaling to deployments should continue to be rewarded for their efforts. If/when signal is no longer driving indexer rewards, it makes sense to deprecate curator incentives.

[ari]

Hey PaulieB, thanks for your comments.

1. With this proposal, every time an indexer collects query fees, the 10% curation fee will go through the exponential rebate pool mechanism that will end up defining how much the indexer get and how much is burnt depending on the allocated amount, but in the end indexers should get more than they get today.

2. The timeline depends entirely on the Council as these changes are updates in the protocol parameters, but if governance decides to move forward with it, they should share a date to give enough time for participants to adjust. Sounds that 2 weeks might be enough.

3. Signal is a mechanism to distribute the rewards, it does not change the issuance rate. If we see a loss of signal across the board the proportion each subgraph receives won’t change much.

[ari]

@DataNexus

When you say that it does not ever make it to the gateway, it sounds like this means the consumers query fees aren’t making it to the intermediary for indexers to receive a voucher to claim. Can you expand on this part or help correct my understanding?

I think this part meant to say just reach the indexers, because the protocol distribution logic does not distinguish about the consumer paying for those fees, a gateway is just another consumer for the contracts. @howard I’d edit that part to avoid confusion.

[ari]

@DataNexus

Question about this chart: How is that the curator_signal_amount is higher than the total_signal_amount in the first row? Can you share a link to the dashboard you are using?

[howard]

Here’s a crude calculation for you. In the last 3 months, query fees were about 231.1K GRT (see here) and new GRT token issuance was about 79.3M (317.2M GRT annually divided by 4). For GRT token supply to become non-inflationary via only the 1% burn in query fees, query fees would need to increase by roughly 3,431,415%. I think it may be fair to say the query fee burn has a negligible effect on GRT token supply.

The calculation is 100% * (79,300,000 / (0.01 * 231,100)), where the 0.01 comes from the 1% burn of query fees.

[howard]

@Oliver

I was thinking: Yes, curation overall hasn’t worked out well, but that doesn’t mean it never works!

This GIP was not created to claim the curation mechanism cannot ever be used to communicate to indexers and get a subgraph indexed. Instead, the aim here is to iterate toward a mechanism that achieves desired outcomes in many (hopefully most) instances.

[howard]

@DataNexus

This may be true by total signal volume. But the subgraphs few that are actively generating query fees appear to have market curators signaling (non-self-signal).

If we look at the largest signal subgraphs without substantial query fees (less than 10 GRT), very few have other curators adding to the self-signal:

@DataNexus, this is an interesting point. Consider a 3rd-party curator that is trying to make as much from query fee royalties as possible per GRT signaled (i.e. maximize their “bang per buck”). For a 3rd-party curator “X” that decides to signal on a subgraph we have

\mathsf{(\text{rate of return for X}) = \dfrac{0.1 \cdot (\text{query fees})}{(\text{curator X signal})+(\text{current signal})}\cdot 100\%.}

Loosely speaking, to maximize the rate of return it seems justifiable (depending on one’s time horizon, transaction costs, and beliefs about others’ behaviors) to find a subgraph with a relatively low amount of current signal and a decent amount of query fees. So, it makes sense to me to see 3rd-party curators on subgraphs with query fees (and not a ton of signal) and not as often on subgraphs without query fees. In other words, your shared data together with reasoning about rate of return for 3rd-party curators may indicate that 3rd-party curators are actually not too incentivized to help identify new subgraphs that should be indexed, but instead to find subgraphs that are already indexed and take a cut of the query fees. This is a simplified line of reasoning, but hopefully illustrative.

As an example, suppose I were to deploy a subgraph for my dapp, provide signal, have query fees start flowing smoothly, and then see 3rd-party curators start signaling too and get a cut of my query fees. I may be a bit upset to be paying them. What value did they add to get a 10% cut of my query fees? (Recall I would have gotten all of that 10% before they showed up.) Unless the price of queries drops as a result (perhaps from indexers lowering costs due to increased indexing rewards) so that my overall payments decrease, it may be a disservice to have 3rd-party curators on my subgraph in this setting.

[DataNexus]

@howard

What value did they add to get a 10% cut of my query fees?

In the case of radiant, they supplied the total signal to the subgraph which has brought 20k GRT in query fees. The subsequent curators added signal to justify more indexers allocating to it which brought better better load balancing and geographic distribution. If this GIP passes and the two current curators on the top producing subgraph remove their signal, do we want to reach out to Radiant telling them they need to acquire more GRT to retain indexing support on top of their query fees?

Though it’d be a fair counter point that if the upgrade indexer provided the bootstrapping support, indexers are likely to reactively support high query volume subgraphs. Rather than the predictive support originally intended by curators (which is spotty, but sometimes effective). Now that Cobb Douglas is deprecated, we’re seeing more tiny allocations from indexers to achieve this already.

@howard

3rd-party curators are actually not too incentivized to help identify new subgraphs that should be indexed

I largely agree. The upgrade indexer will likely offer better bootstrapping efforts. Curators or indexers can monitor the query flow. If indexers don’t see it, curators can adjust indexing reward levers to ensure it gets sufficient support.

I do not think that ending curation incentives makes sense until we deprecate curation.

[DataNexus]

But I agree, that shouldn’t be able to happen. This was made on dapplooker using this query:

select s.display_name as subgraph_name
    ,sum(query_fees_amount) / pow(10,18) as query_fees_amount
    ,(s.signalled_tokens - s.unsignalled_tokens) / pow(10,18) as total_signal_amount
    ,a.curator_signal_amount
    ,coalesce(a.curator_count,0) as market_curator_count
from graph_network_arbitrum.subgraphs s
join graph_network_arbitrum.subgraph_versions sv on sv.subgraph = s.id
join graph_network_arbitrum.subgraph_deployments sd on sd.id = sv.subgraph_deployment
left join (select su.id as subgraph, count(*) curator_count, sum(s.signalled_tokens - s.unsignalled_tokens) / pow(10,18) as curator_signal_amount
      from graph_network_arbitrum.name_signals s 
      join graph_network_arbitrum.subgraphs su on s.subgraph = su.id
      where 1=1 
      and su.owner != left(s.id,42)
      and s.signal > 0
      group by su.id
) a on a.subgraph = s.id
group by s.display_name, s.name_signal_count, s.signalled_tokens - s.unsignalled_tokens, s.name_signal_amount, curator_count, curator_signal_amount
order by "query_fees_amount" desc

[CryptoWing]

Thanks for the crude calculation that you thought I wasn’t aware of.

So to put it crudely, you think that query fees will not be increasing exponentially in the future, hence there is no point to burn query fees because the current amount of query fees is as much queries we will be getting anyways? Cause your logic seems to argue for that.

I never did say it should become non-inflationary via ONLY the 1% burn in query fees, I say that it is a deflationary pressure for the tokenomics. And I specifically thought of this part because it will become more significant as queries increase in the protocol. If you think 1% is too small to matter, then that supports my point that it should be increased instead, and not changed to 0%. Not exactly rocket science.

[howard]

@CryptoWing

So to put it crudely, you think that query fees will not be increasing exponentially in the future, hence there is no point to burn query fees

No, that is not what I am saying. I merely gave numbers to put your concerns in context and noted the burn presently “has a negligible effect on GRT token supply.” (Note the usage of the present tense “has”, not future tense.) Furthermore, even if GRT supply were always increasing and no tokens were burnt, it is quite possible to bound the total supply (e.g. by way of “halvings” of token issuance).

@CryptoWing

Not exactly rocket science.

Correct. The tools I encourage folks to bring to the table in these conversations are typically from game theory and mechanism design, not rocket science. Yet, even some basic arithmetic will often be sufficient to make forward progress. With that said, can you help me understand why increasing the burn rate could be beneficial? (referenced below) To be clear, I do think 1% can matter to data consumers and indexers, which is why this GIP proposes removing that frictional cost.

@CryptoWing

If you think 1% is too small to matter, then that supports my point that it should be increased instead, and not changed to 0%.

[CryptoWing]

put your concerns in context and noted the burn presently “has a negligible effect on GRT token supply.”

Of course the current burn has negligible effect on supply, we don’t even have any significant queries in the decentralized network yet. I am more confused to why this have to be brought up, Why are we not considering the context regarding how this GIP will affect the burn in the future when query fees goes up significantly?

Furthermore, even if GRT supply were always increasing and no tokens were burnt, it is quite possible to bound the total supply (e.g. by way of “halvings” of token issuance).

Bounding supply is not the same as the deflationary pressure from query fee burn, it is still going to be a total change of tokenomics.

To be clear, I do think 1% can matter to data consumers and indexers, which is why this GIP proposes removing that frictional cost.

Then again, are The Graph’s only stakeholders at this point only data consumers and indexers? What about curators and delegators?

I view the query fee tax as a payment that is made to all GRT token holders, whether actively participating in the protocol, or just holding the tokens. Those holding the tokens and actively participating with a stake in The Graph has helped contribute to price stability, giving a demand side to all the tokens printed by the protocol for the past 3 years.

With that said, can you help me understand why increasing the burn rate could be beneficial?

Beneficial to what aspect is what we need to align on. If you are only thinking in the silo of fractional cost and not caring about other aspects such as tokenomics and concerns of other stakeholders, then I guess I can’t say much. As indeed changing frictional cost from 11% to 0% would definitely reduce inefficiencies. (simple arithmetics).

As a delegator increasing the burn rate would give me more confidence in delegating and holding my stake.

I believed in the long term success of the graph, in which eventually the burn rate would be significant enough, and that the indexing fees will be eventually reduced as query fees increase. By reducing this to 0, it signals the uncertainty of the whole graph protocol to me, that what I used to believe in are no longer valid. Even if what I believed in was based on my own misunderstanding.

I am a fan of a deflationary tokenomics more than a bound supply/slow inflationary tokenomics, as I believe this will contribute more towards price stability and appreciation. I believe Ethereum has also conducted a research with the benefits of EIP-1559, though not sure how much of that applies to the situation with the Graph.

Currently even after years waiting for the hosted service sunset, cancelled then turned into sunrise, with no clear ETA, I still try to believe on the core protocol tokenomics. So this GIP is a bit of a slap in the face to be honest.