The Graph Indexer Office Hours #191

TL;DR: Rem from Edge & Node continues presenting GIP-0070, which proposes changes to The Graph's protocol economics. The proposal aims to address three main goals: maintaining network balance, enhancing incentive alignment, and sustaining continuous improvement. Key changes include introducing network payments and network rewards to replace indexing rewards, implementing dynamic query fee cuts, and establishing a new curation mechanism that allows for broader network activities.

Opening remarks

Hello everyone, and welcome to episode 191 of Indexer Office Hours!

GRTiQ 204

Catch the GRTiQ Podcast with Felix Xu, Co-founder of ARPA Network and Bella Protocol.

During the conversation, Felix shares insights on the evolution of crypto markets, the impact of AI on trading, and his perspective on market cycles since 2017. He discusses the future of decentralized finance, the rise of meme coins, and his team’s work on advanced AI models for crypto trading.

⬇️ Skip straight to the open discussion ⬇️

Repo watch

The latest updates to important repositories

Execution Layer Clients

• sfeth/fireeth: New releases:
  • v2.9.1 :
    • Date: 2025-01-20 19:14:45 UTC
    • This release reintroduces the grpc.health.v1.Health service for firehose and substreams-tier1, which was removed in version 2.9.0, addressing a regression issue.
    • Additionally, it prioritizes the use of the X-Cloud-Trace-Context tracing header to prevent trace ID leakage beyond GCP load balancers.
    • Urgency indicator: Yellow
    • Urgency reason: Important updates, but no immediate risk.
  • v2.9.0 :
    • Date: 2025-01-16 15:47:36 UTC
    • This release introduces several important updates and breaking changes.
    • New features include enhanced configuration options for substreams-tier1 to balance active requests across instances, new Prometheus metrics for tracking rejected requests, and improved HTTP compression support for browser clients.
    • Quality of life improvements were also added to fireeth tools and the Reader Node Manager API.
    • Breaking changes: Firehose now enforces GZIP or ZSTD compression for client connections by default, rejecting uncompressed requests unless –firehose-enforce-compression=false is used. Additionally, support for the legacy sf.firehose.v1 protocol has been removed.
    • Urgency indicator: Red
    • Urgency reason: High for users relying on uncompressed Firehose connections or the old protocol.

From the chat:

Matthew Darwin | Pinax: Pinax upgraded to the new Firehose 2.9.1 already.

Ana | GraphOps: Sounds like it went well.

Matthew Darwin | Pinax: What do people think about the current state of Erigon 3? The Erigon team wants us to move off Erigon 2 (see below).

Ana: GraphOps hasn’t yet tried Erigon 3, so I don’t have an opinion there, but I’m also interested in what people are thinking.

Graph Stack

• Indexer Service & Agent (TS): New release v0.22.0 :
  • Date: 2025-01-15 18:40:07 UTC
  • Version 0.22.0 enhances functionality with support for local querying of Epoch and TAP subgraphs, improves action state management, and addresses pending RAV handling. While these updates optimize performance and fix existing errors, they are not critical to operations.
  • Urgency indicator: Yellow
  • Urgency reason: Important updates, not immediately critical.
• Indexer Service & Tap Agent (RS): New release indexer-service-v1.4.1 :
  • Date: 2025-01-16 14:08:05 UTC
  • Version 1.4.1 addresses bugs related to CheckHealthError serialization and header retention in attestation middleware, ensuring improved system reliability. Operators should apply this update to maintain optimal performance.
  • Urgency indicator: Yellow
  • Urgency reason: Important fixes but no immediate threat.

From the chat:

Matthew Darwin | Pinax: Any updates from paka | E&N on graph-node releases? Don’t think so.

Mickey | The Graph (E&N): Coming very soon, per Marko this morning.

paka shared an update the next day (January 22) on Discord:

Protocol watch

The latest updates on important changes to the protocol

Forum Governance

All the resolutions have been executed for the following:

• Request for information about disputes #GDR-24
  • Draw (read the forum thread for discussion)
• Request for Information about Disputes #GDR-25
  • Slash (no response)
• Request for information about disputes #GDR-22
  • Slash (absence of conclusive data to support a draw)

Contracts Repository

• fix: cleanup TAPCollectorAuthorizationAlreadyRevoked #1089 (open)
• chore: update ignition to v0.15.9 #1087 (open)

Open discussion [8:11]

Rem from Edge & Node to further discuss the future of The Graph’s protocol economics.

The selected screenshots below are taken from his presentation.

Rem introduced GIP-0070 and the different participant needs in The Graph Indexer Office Hours #187.

• Forum post and discussion: Evolving The Graph Protocol Economics
• GitHub formal proposal: GIP-0070: Evolving The Graph Protocol Economics

Rem: Today, I’m going to focus more on talking through the GIP (Graph Improvement Proposal) itself. GIP-0070 is an overarching GIP covering protocol improvements.

I’m going to talk a bit about how the protocol works currently. The protocol indexes data, serves data for consumers, and they pay query fees. We also have curators who curate on data [subgraphs] so that the indexers know what to index. The indexers allocate and index the data. We have delegators who delegate and help the indexers with their allocation. Finally, the protocol issues indexing rewards.

Collectively, this is an integrated, coherent set of mechanisms that were designed to work together and balance each other, and they’ve done a pretty good job of that in many ways. We have now found some areas where we want to improve things, but basically, overall, there is a good balance in the protocol. One of the key goals of the proposal is that we need to maintain this network balance.

Maintain network balance

Issuance distribution maintains indexing and network health

Indexing Rewards

The indexing rewards distribute issuance to ensure that indexing occurs and that the network remains healthy. We need to make sure this is maintained.

Integrated role incentives to holistically balance the network

Delegate, Allocate, Curate, Query Fees

There are integrated role incentives to holistically balance the network, so everything we do needs to have that design for balance across how the mechanisms work, not just thinking of mechanisms in isolation.

Enhance incentive alignment [13:45]

Another major goal of the proposal is to enhance incentive alignment.

If we look at what happens on the network, and this is an approximation, you can kind of see what’s happening in the whole indexing rewards and curation space isn’t as strongly connected to what’s happening in the consumer and query fees space as we would like.

You can play around with how much you curate and allocate to earn indexing rewards without necessarily ever serving any data and this is a problem for the network long term. As traffic ramps up, we need to make sure we have alignment here.

Currently, network rewards are not linked to the consumer value delivered.

Limited incentives for network contribution to consumer value

It’s not just these particular incentives that are not quite aligned. There are other things we want to do on the network.

Indexing Fees

Currently, there’s no link between indexing fees and the current query fees we have. Indexing fees themselves are disconnected. It’s like another area of incentives, and it’s one that we’ve introduced rather than one that existed.

Builder/Contributor Activity

There’s activity that we want to happen on the network. To some degree, it already does, but to some extent, it’s new activity. It’s not covered by the incentives we currently have.

Define, Build & Integrate

Builders defining, building, and integrating.

Space, Service, Module…

Developers creating a subgraph, Substreams, or new data services.

Contribute & Collaborate

People contribute to a space on the knowledge graph along with other places they can contribute.

It’s outside the scope of this proposal to talk about how all of that is going to happen, but we do need to make sure that we’re able to incentivize that and that it comes into the way the protocol evolution is being proposed.

Sustain continuous improvement [18:45]

The final big goal is sustaining continuous improvement.

Balance issuance allocation for expanded network activity

There are these different things that we want to incentivize and we need to somehow balance issuance to happen between those so that happens in a fair and reasonable way. We also need to make sure that everything we’re doing is setting us up for the long-term sustainability of The Graph, including for example, after our foundation listing ends.

Those are the major goals and the reasons why we’ve ended up with quite a few red boxes.

From the chat:

Pierre | Chain-Insights.eth: The indexing rewards are directly multiplied by the allocation. Will this be addressed with the indexing fees?

Rem: It’s not actually linked to indexing fees, so the indexing rewards are multiplied by the proportion of allocation versus total allocation, you’re correct and that will be addressed but indexing fees has a different mechanism. I’ll try and avoid going into it now because that will become a whole conversation of its own.

Proposed Mechanisms [21:20]

From the proposal side, how do we intend to address the issues?

Maintain network balance > Issuance distributed as network payments and network rewards

Indexing rewards do need to change. The proposal suggests we start distributing through a combination of two things:

1. Network Payments are direct payments for indexing and query services.
2. Network Rewards provide rewards for indexers similar in nature to indexing rewards but will incorporate qualifying criteria based on service quality to improve incentive alignment.

Network rewards still maintain a baseline function of network health, making sure indexers can join the network and we can see the quality of service being offered. Network payments will be paid directly to the indexers by a mechanism from issuance, using the same mechanisms that anyone else could, like a sponsor doing indexing payments, paying indexing fees, etc. and a consumer issuing queries. This is because it makes sure the right data is indexed, and it also means that we can actively monitor the quality of service. We can change the dynamics of the market slightly so that indexers don’t need to try and predict where they will be useful; instead, the network asks the indexers to do the work that is predicted to be necessary.

Maintain network balance > Efficiently balanced fee cuts that incentivize network value creation

The second big change is to the query fees. The way cuts work on query fees would change. The original protocol had fixed cuts, which is almost like expecting a clock that is stopped to be correct. A stopped clock is correct twice per day. Fixed query fee cuts are only occasionally at the right level. The query fees will be dynamically determined by the participants, and they’ll be a little broader in scope in what they can cover. This change will contribute to being able to incentivize contribution and collaboration by contributors. I’m not going to cover the actual mechanism as it’s not in the scope of this proposal.

Enhance incentive alignment > Sponsor incentive that optimally matches indexing with demand

We more formally define sponsor as a role, giving the sponsor an incentive that optimally matches indexing with demand. This looks a little bit like curation, except you’re directly paying for the indexing, so whoever pays for the indexing, over time can get repaid and a return for doing so. It allows the network to self-balance. The cut that goes to this self-balance is according to market demand.

Enhance incentive alignment > Curation as indirect sponsor using issuance (and providing signal)

In the original protocol, curation was something that people recognized as not functioning the way it should. I’ve kept the name of curation, but the mechanism is a little different. In the new curation mechanism, the curators are still locking their GRT, but what they’re locking that GRT for and how it flows becomes a bit more specific. They look for what they want, a certain amount of issuance becomes available, and that issuance effectively is used to sponsor indexing or do some other activity that curation can perform.

All of these mechanisms are designed to be open and synergistic so that they have more than one application. The original network was focused on indexing and indexing fees. We’re now thinking more broadly about other activities on the network, like what will happen in knowledge graph spaces so curation becomes an activity that can be performed not just to get data indexed but also to get content written for the knowledge graph or potentially other tasks happening on the network.

So that represents curation being fixed, but also note that we now have the incentive mechanisms to cover Space, Service, Module… and Define, Build & Integrate.

Again, everything in this Contributor column is not in the scope of this proposal, but we are proposing a baseline protocol that can support a variety of different activities.

Sustain continuous improvement > Self-balancing issuance allocation based on locked GRT proportions

We’ve got quite a few different mechanisms at play here, and it’s very important that they are balanced. As with my comment on query fee cuts, if you set a fixed fee cut, it’s only going to be an appropriate cut for a small proportion of the time. If we hard-code any particular balance of issuance, I think that would be a mistake. The protocol needs to self-balance through how people are locking their GRT.

Sustain continuous improvement > Taper subsidy based on external income to match network needs

Currently, it’s indexing rewards—it’s going to be called network rewards, and their issuance is used as a subsidy to sustain and build the network. We’re dependent on it and we can’t stop that at this stage. It is, however, a subsidy, so we need to plan in a transparent way that everyone understands how the mechanism is going to work and how it’s going to predictably change over time from being a subsidy purely for indexing to a more general subsidy.

As the external income grows, it makes sense that the dependency on issuance to subsidize the network decreases over time. I haven’t fixed exact parameters yet; I think this is a discussion where a lot of people can contribute. Probably a reasonable middle ground is if there’s an extra, I don’t know, 10 million of external income flowing into the network, so with external income, we might mean query fees (query fees are probably the largest source of it) that is paid by people, so it’s not issuance paying this 10 million in query fees, it’s coming from elsewhere, but if the external income grows by 10 million, we can probably decrease the subsidy by a bit and I think a reasonable proportion is probably half. So, the external income increased by 10 million, so the amount of the subsidy decreases by 5 million, the indexer network is still earning more than it was previously. It’s still earning 5 million more but we’re also gradually and transparently weaning ourselves off that being a subsidy just for indexing and being able to use it for other purposes.

Q&A [35:26]

NSun | Graphtronauts: What might other purposes be?

Rem: One is content on the knowledge graph, and that’s probably the obvious one we know about right now, but when it comes to the long-term sustainability of the network, we can’t necessarily predict all the future things we’re going to do. If we commit to using the network just for one purpose, then we don’t really have flexibility. Having flexibility and being able to invest in other areas of the network is in all our best interests.

---

Marc-André | Ellipfra: On self-balancing issuance based on staking size. Can you share some figures of what you have in mind so we can understand the direction and the impact you are looking for?

Rem: There was about 2.5 billion locked GRT the last time I looked, for a combination of self-stake and delegation, and what’s currently 2.5 billion can largely be regarded as being one bucket that determines what should be going to network rewards and network payments. The last time I looked, curation was 7 or 8 million (as opposed to billion), so the amount of curation is currently tiny. It’s probably partly because the amount of external queries is tiny as well.

But if we say for the self-balancing issuance, the proportion based on stake including delegation is one bucket versus the proportion of the new curation mechanism, which can direct things towards the knowledge graph or indexing and other places potentially in the future, but let’s use the knowledge graph as an interesting case because that’s a bucket that’s not going to indexers, much less than 1% of the issuance would now start to be redirected to other purposes. Now, if a lot of people become interested in this and start curating, then that share would grow.

Interesting scenarios to think about

If that extra demand for curating on the knowledge graph is net new demand, then it has no negative impact on indexers in effect because the demand is going up if the supply is fixed, right, a marginal demand versus marginal supply. Actually, the proportion that goes to indexers keeps the same value—it’s less GRT, but that GRT is worth more and has the same value.

Another scenario to consider is if it’s not net new demand, it’s actually existing delegators, so you’re not changing the amount, it’s existing delegators saying I’ll draw as a curator and delegate. This is a risk factor that I’ll design the initial way the protocol works to mitigate against because if 90% of delegators decide they want to curate instead, the indexer income drops and that’s not the intent.

---

Vince | Nodeify: Have there been any hard numbers done that if we flipped a magic switch today, what would the net negative be to indexers’ income with current query volume & stake, if any? Ignoring the positive aspects of changes proposed.

Rem: Based on current numbers, it’s less than 1%. What I can never predict completely is other changes in network demand, but if we took the way people have locked GRT currently and changed it to these new mechanisms, there would be a less than 1% drop in terms of how much of the total issuance pool is going to indexers. Note that even less than 1% enables us to start prototyping new mechanisms and piloting how things work, so that’s actually useful for the network overall.

Putting It Together [44:41]

Below is a diagram from the proposal itself. You can see how the protocol aspects we’ve been discussing are related to the main goals or themes of the proposal: maintain network balance, enhance incentive alignment, and sustain continuous improvement.

On the design side, there are three principles. The design principles are highly interconnected and central to everything that’s happening.

1. Everything should be synergistic open primitives. This is inspired a bit by the changes that Horizon made versus the original protocol. The original protocol was quite fixed in this design, and Horizon, along with the world of data services, started opening that up and saying we create these contracts, etc., that can be used in multiple ways. We don’t dictate or try and predict all of the ways that they will be used. All the mechanisms are designed to work together but to be quite versatile.
2. We need to be really focused on consumer value alignment. We need to design the network to deliver value to consumers because that is what will make the network successful in the long term.
3. We need to allow the ecosystem to adjust itself (self-balance) over time to where the demand is, to satisfy that demand, and to make sure there’s the right balance. We can’t predict and set fixed cuts.

Also shown in the diagram below, there’s intended to be a Graph Improvement Proposal (GIP) associated with each of the proposed mechanisms.

This is why I couldn’t answer the question earlier. As you can see, the GIP that fully answers that question hasn’t been written yet. As these develop, each of them will deserve a conversation in Indexer Office Hours and I’d love your input into these.

Do participate in the forum post if you have any ideas. I would love more contributions. Many aspects of the design have changed a few times as things I try don’t work, and I expect some aspects will still change in the future.