Graph Explorer – Decentralization & Reputation UI Changes

[Oliver]

In this post we have received broad community support for improving network stake decentralization (80%+). The following post specifies details for implementing the most supported idea (75%+) to improve stake decentralization, which is to introduce UI changes in the Graph Explorer using a concept already implemented at Solana.

Core Idea

The main goal of this idea is to raise Delegator awareness to stake centralization at the point in time they make their next delegation and to thus meaningfully influence Delegators to contribute to stake decentralization. This can be accomplished by establishing and Indexer Decentralization Threshold (Upper Cut Line) where large Indexers above the threshold would be grouped in a collapsed view followed by a decentralization message below to encourage Delegators to choose an Indexer below the threshold. Solana hereby can be viewed as an example of that:

We have also heard valuable feedback from @KonstantinRM emphasizing that while stake decentralization aims to fend off delegation actions motivated by thoughts of “simply picking a large Indexer”, one should also be mindful about swinging the pendulum the other way to not end up incentivizing a motivation of “simply picking a small Indexer”. There is broad alignment to promote Indexers that are actively engaged in the community, who are positively contributing to the ecosystem and who are supporting other network members, regardless of their size in the network. Reflecting on Konstantin’s feedback, I hereby propose further amendments to the initial idea. In addition to the Upper Cut Line (Decentralization Threshold) I suggest to also introduce a Lower Cut Line which can be interpreted as a Reputation Threshold. More details on that below.

Important to note is that the suggested changes do not constitute protocol design changes and therefore are not presented here as a GIP. The scope for this proposal is isolated to UI changes on the Graph Explorer and should therefore inform the Core Devs team on what the community agrees to.

Detailed Specifications

Decentralization Threshold (Upper Cut Line)

This proposal suggests establishing an Indexer Decentralization Threshold of 2%. Any Indexer whose total staking value (self-staked & delegations) is above 2% of the total network stake would be considered a large Indexer (currently true for nine Indexers). That would be made visible to Delegators in the Graph Explorer in an effort to stimulate future Delegations to be made with smaller Indexers as follows:

• The threshold would appear as a line on the Graph Explorer where Delegators choose their Indexer, located at the top of the table. Above the line are Indexers above the threshold, below the line are Indexers below the threshold
• The line would be drawn with a message that states: “More delegations above this line can negatively impact network security. Consider delegating to an Indexer below this line”
• All Indexers above the line are shown in a collapsed view similar to the image shown in the Solana example

Reputation Threshold (Lower Cut Line)

In an effort to promote Indexers that demonstrate active intentions to being a valuable Indexers in the Graph network and community, this proposal introduces a Reputation Threshold for Indexers to meet the following minimum criteria:

• ENS Name
• Query Fee Cut and Indexer Rewards Cut below 95% (based on new logic described in Stable Reward Yield)
• Minimum one active subgraph allocation in prior 72 hrs
• Minimum 50% of total stake allocated to subgraphs at any point in last 72 hrs
• Minimum 50% of allocations on subgraphs other than PoolTogether in last 72 hrs
• Indexer generates >0 query fees in the last 60 epochs

Any Indexer that fails to meet the above criteria would be captured by the Reputation Threshold as follows:

• The threshold would appear as a line on the Graph Explorer where Delegators choose their Indexer, located at the bottom of the table. Below the line are Indexers not meeting the threshold, above the line are Indexers that meet the threshold.
• The line would be drawn with a message that states: “Indexers below this line are anonymous, not intending to accept new delegations or failing to meet minimum protocol activity criteria. Consider delegating to an Indexer above this line”
• All Indexers below the line are shown in a collapsed view similar to the image shown in the Solana example

Table Layout

One other aspect of the Solana Beach Validator table layout that seems effective is the streamlined design of the Validator table that draws a user’s attention to the most important data points. The Graph ecosystem has already a number of insightful dashboards (Graphscan, Graphtronauts, etc) that provide deeper information on Indexers. Therefore, one could argue that the Graph Explorer can in turn focus on the most critical pieces of information for Delegators at the time they make their delegation decision. This is the current design:

This proposal suggests a design update that moves a number of the above data points from the default view into the expanded view, in order to create a cleaner appearance. It should instead show only the below data points:

The remaining data point should still be accessible in the expanded view.

Looking forward to your feedback!

[Ohmyjog]

Simple, yet effective. I’m all for it

[NSun]

Sensible changes. I especially like the idea of the lower cut line. As more indexers onboard, the ability to sort out the active, beneficial ones from the inactive ones will become all the more important. Great ideas all around.

[airtrax]

I love these general ideas but there’s two changes I would personally make around details.

1. I think there should be some actual incentive to decentralize across indexers. Incentives always help direct people toward goals and we’ve seen a lot in the crypto space how true that becomes. If one indexer offers better rewards, people will most likely dump into that indexer, whether or not they’re highlighted. I think that especially becomes true if the graph grows a lot and users move from the core group now to the broader community.

2. For the new simplified view, is there still going to be an option to expand and get more info? I like the simplicity for scanning through but would also like to see more about the indexers easily.

[Oliver]

Thank you for your feedback @Ohmyjog @NSun and @airtrax. Great catch on the specification details around the expanded view which I missed in my OP. I have updated the OP with language around that and agree with your suggestion to keep these data points in the table, but just move them into the expanded view instead.

[chris]

Thanks for this excellent proposal @Oliver! I propose that we also add query-fee requirements to the Reputation Zone.

Even collecting 0.01 GRT in query fees validates that an Indexer has done a lot of work beyond just allocating, including:

• their query endpoint is accessible by the gateway
• they have set competitive cost models
• their performance is adequate to receive queries from the gateway (as determined by the broad array of utility functions implemented in the Indexer Selection Algo in the gateways)

Perhaps the requirement could be that query fees exceed some amount within a rolling window, ensuring that all Indexers within the Reputation Zone are actively providing utility to the network by serving demand.

[Oliver]

I like that idea @chris. Let me propose a specific requirement based on your suggestions:

Indexer claims at least 0.1% in Query Fee Rebates on it’s self-stake within the last 60 epochs

---

Reasoning:

• Delegators would be mostly interested in earned income, hence requirement is specified on claimed rebates vs. generated query fees
• A % puts a relational component into the proposal, so that smaller Indexers are not disadvantaged with this requirement
• 0.1% number over 60 epochs equates to about 0.6% annually. Goal is to define a number that can be reasonably achieved by an Indexer that is considered actively optimizing for query fees
• 60 epochs is meant to provide reasonable timeframe of reference. 28 epochs seems to be the minimum, since allocations can stay open that long. 60 epochs would cover just over two full allocation cycles, enough time to demonstrate being active and not too much time where the most recent past becomes diluted.

Interested in your thoughts on the above, especially if the proposed numbers seem reasonable

[KonstantinRM]

We can’t guarantee this number, that’s why Chris told about just “not null”.

[chris]

Thanks @Oliver!

• 60 epochs seems reasonable to me
• The query fee rebate for a given allocation may only be claimed 7 epochs after the allocation is closed, so the data underlying the Reputation Zone would be delayed by the same amount of time
• Rebates need to be claimed on-chain separately. Given that query fees (and therefore query fee rebates) are so low, many Indexers (including myself) are not claiming query fees or query fee rebates because the ETH gas costs make the claim a net-loss in USD terms. This means that some Indexers may be generating GRT income for serving queries, but this is not reflected on-chain because the fees aren’t claimed.
• Introducing a requirement that query fees must be some % of indexer self-stake (rather than a non-zero number) is definitely a step up in requirement. This effectively means the Indexer must hit a performance threshold (i.e. they must generate a minimum level of query business proportionate to their self-stake). On the one hand, I like this because it raises the bar for indexers. On the other, if this level were set too high, it may be unrealistic for indexers to meet given that the demand for queries is an exogenous factor.

[Topher66]

It’s imperative that Indexers serve queries, but with the limited query fees at this point in our evolution I’m not sure there’s an equitable way to include that metric in the Reputation Zone.
Since this is essentially a UI adjustment, we can come back to this in a few months when query fees have established some kind of baseline.

[chris]

At the very least, having a requirement for non-zero query fees (rather than a %-of-self-stake requirement) makes sense to me. This does not require any level of “query volume performance” from an indexer, but rather just validates that they have done the work beyond allocating to actually serve a query and get paid.

[Oliver]

Thanks @chris. I have updated the OP with an added requirement of “Indexer generates >0 query fees in the last 60 epochs” for the Reputation Threshold criteria.

[Ricky]

Just wanted to resurface this now that there are more query fees flowing through the network. The UI changes discussed in this thread seem like reasonable low hanging fruit, and would be good to get some alignment around a path forward for a UI change so we don’t sort indexers by largest stake owned. From there we should keep thinking critically about stake decentralization, but this seems like a good first step.