I personally like the idea of capturing this metric as it would provide some sort of Gross APY (an Indexer level performance ratio prior to the distribution with delegators). In that context, we can look at existing dashboards how delegator APYs are tracked today since such an Indexer performance ratio would be related to that. What we currently find are figures that are often close, but not always the same. This is how the APY shows across three different dashboards for this Indexer:
Those of us approaching APY like a game horseshoe (close is good enough), might be perfectly fine knowing the expected APY is likely to be somewhere in the range of numbers shown in the three dashboards. The problem enters by defining what should be added in the Explorer. None of the three dashboards is necessarily more right or wrong, it’s just that APYs (future and historic) can be calculated in a number of different ways and hence lead to different results. Today, we don’t have a standard algorithm defined for that and maybe it is worth starting these discussions within the community which certainly is a larger topic in scope. In order to keep this Forum post focused on the new rewards cut settings mechanism, I would recommend not adding new scope that is not directly related to it, but rather cover it in a separate proposal.
With regards to the proposed UI changes, we have another Forum post open that discusses Explorer UI design to improve stake decentralization (Graph Explorer – Decentralization & Reputation UI Changes). In there, we are looking to streamline the data points shown in the Explorer to focus delegators on the most critical data points. Feel free to add to the suggestions made there.
This is a very astute observation that I myself had not interpreted that way, and which I’m not sure many others in the community have either. I did verify with @ari that the current design does in fact put a floor of 0% on the cut settings mechanism. Thank you @Mike-LunaNova for both identifying that as well as providing your feedback on the positive impacts such a change could create from an Indexer’s point of view.
Adverse Effects
In addition to Mike’s positive reflection, it is also worth discussing possible adverse affects of such a change to provide a comprehensive view. Implementing a floor to the cut % could be interpreted as interfering with principles of a free market.
While we may find today that small Indexers are challenged in bootstrapping their operations in this early stage after protocol birth, that situation may change (maybe even drastically) as the ecosystem matures in the future, as a result from growth in query volumes and possible GRT price appreciation. The effects of those scenarios could lead to overall protocol vulnerabilities. If rewards rise to higher levels, as a reflection of growth in the entire web3 ecosystem, then Indexers could in fact perceive fair compensation to occur even at negative cut % settings. If they no longer have the opportunity to lower the cut % they are willing to share past the floor, then other web3 protocols can gain competitive staking rewards advantages over the Graph. If staking attractiveness at the Graph diminishes vis-à-vis other web3 protocols, then that could lead to protocol delegation decreases as the upside for Delegator APY is suppressed by the 0% floor.
Protocol Analysis
On the practical side, I agree with the intuition that larger Indexers are in a better position to capitalize on the current mechanism if their goal was to follow a scorched earth strategy. The data in our network provides an alternative viewpoint on that. A correlation analysis between Effective Indexer Rewards Cut (EIRC) % to Indexer Self-Stake amounts returns a value of 0.004. In other words: an Indexer’s Self-Stake size provides no immediate hint what the EIRC% may be, there is no direct correlation.
Zooming in further, we currently have 11 active Indexers in the network with a negative EIRC%. Every one of them is in the small Indexer segment with an average self-stake of less than 1M GRT and all of them with a self-stake below 2M GRT. An interesting method to evaluate their success is to compare them to their peers of a similar level of self-stake who have a positive EIRC%. One effective way to define “success” is to compare the actual Delegator count of these two groups with one another, as it better reflects how broadly negative EIRC % may resonate with Delegators.
The 11 negative EIRC% group has a combined total of 444 Delegators, while the 11 positive EIRC% control group has a combined total of 273. How much of that difference can be attributed to a more competitive EIRC% remains open, however, the difference would seem significant enough to state it does have some degree of noticeable impact. Below I have attached the data pulled from Graphscan. The file has been cleaned up to remove inactive Indexers as well as those with a 100% EIRC% settings to focus the analysis on competitive Indexers.
Summed up, implementing a 0% floor at this point would not stop larger Indexers gaining new Delegators via negative EIRC% (this is not happening), but it would result in 11 smaller Indexers being forced to increase their cut% from negative EIRC% to at least 0% and thus risk losing Delegators due to reduced APYs.
Provide Feedback
I would like to invite everyone to provide feedback on these new findings presented by Mike as it may change your opinion based on what we have shared. Implementing a floor of 0% would certainly necessitate broader evaluation. Instead of just streamlining the way to administer the cut % settings, we would also be implementing an actual protocol change. That may trigger the need to engage in a broader risk analysis and economic assessment exercise. This itself should not deter from proceeding, but it is something to keep in mind from an execution timeline perspective.
Following up on the prior discussions on what Mike had discovered along with my remarks on that. Given that we had broad agreement on the principle proposal, it would be good to know how everyone interpreted what Mike and I have discussed. In essence, it boils down to: should the range of possible entries for future cut% be: 0% to +100%, or should it be -100% to +100%.
Since this is a fairly binary question, I have put together the below poll where you can give your opinion on that question, which will subsequently be factored into what will be included in the Snapshot community voting for this proposal.
What range of values should the future cut % entry fields allow?
0% to +100% (introduce new floor of 0% for effective cut%)
-100% to +100% (keep ability to set negative value for effective cut %)
0voters
The voting will stay open for 5 days until 9/27 / 1pm PST
@Mike-LunaNova made some excellent points. Maintaining some of the features that the incumbent cut mechanism provides is a good idea in my mind, especially features that allow Indexers to have more flexibility in their commission models.
Furthermore, following on from some conversations on the 0% floor with @chris , setting this floor at what feels like a neutral point (zero), but is actually consciously interfering with market dynamics, goes against the spirit of what we want to achieve.
I have voted for -100:+100 in the poll below but interested to hear if there are any counterpoint on the matter.
The Graph is the first protocol we’ve encountered where it is possible for a node operator to give away some of their own stake’s earnings in return for delegations. This is particularly surprising given the undoubtedly difficult challenge of performing as a Graph Indexer compared with the role of Validators on other networks.
Every other protocol we’ve seen has a floor price of either 0%, or in the case of newer chains that have been learning the lessons from older networks, enforcing a minimum such as 2% in the case of Avalanche (AVAX). Source: Staking - Avalanche
I understand some may be concerned that adjusting the reward floor higher than 0% is interfering with the market; it very much is, just as a 0% floor is and just as about every other aspect of tokenomics such as delegation caps, stake cooldown periods etc. are. Indeed the whole purpose of tokenomics and adjusting these economic parameters is to shape the market with the aim of improving the long-term overall health of the ecosystem. Therefore I cannot see this as a valid argument on its own for not wanting to set a minimum indexing fee for delegations.
What the floor level should be at any point in time is a subject for governance control. All of the Graph stakeholders should be able to decide and vote on this in the same way they should exercise decentralised control over all the parameters we are discussing. There should be regular review points to ensure all such parameters are still working sensibly.
In a hypothetical scenario where only negative reward cuts are viable it would then only be rational for an Indexer to stop indexing and switch to delegating because it would require significantly less effort whilst generating more returns for them.
Initially I thought setting it at anything above 0% would be interfering however I am now of the opinion that setting any floor is prohibitive and Indexers should be free to do what they want with their commission. I don’t see loss-leading as a threat, based on the enthusiastic discussions we see around Stake Decentralisation - I think any business should be free to run as a loss-leader if they want to, to whatever their ultimate goal might be. I think the most effective shaping of the network parameters (See Stake Decentralisation proposal discussion) is where we influence the distribution of stake via self stake and delegation, rather than by limiting the commission models an Indexer can apply.
Maybe I’m wrong, I would be happy to be proven wrong on this, but the free market capitalist in me doesn’t like to be limited in this area of the business.
I would like to clarify what a negative cut means. If by analogy with the positive cut, it means that the indexer gives the amount from his rewards equal to the percentage of delegators rewards. But in this case, we have a strange situation - the indexer may not have enough rewards to give to the delegators. For example, at a ratio of 1 to 16 (100k indexer stake and 1.6m delegation pool), the indexer gets 1/17 of the rewards pool and 16/17 get the delegators. If the indexer set his cut to -10%, that means he has to give delegators 1/10 * 16/17 ~= 0.094 of the rewards pool, but he got only 1/17 ~= 0.0588 i.e. will he have to give all his rewards + some more from his stake? or how will that work?
Or negative cut implies that he gives a percent of his rewards? in this case we have that one parameter, depending on the sign of its value will mean different things. Positive cut means a percent of delegators rewards, negative cut - a percent of indexer rewards.
Thanks @warfollowsme. Correct that we will need to specify exactly how it works, such as the example you describe above. We would look for the Core Dev team to also provide us with design constraints and proposals of their own. I would recommend to defer that part of the discussion until after the vote which will determine if we need to go deeper into it at all.
For the purposes of the vote, however, it is worth emphasizing that “-100%” refers to the Indexer’s part of the pie and not the delegator side, meaning that the lowest theoretically possible value in that setting would mean that the Indexer gets zero.
I am just clarifying that a -100% setting would not mean that an Indexer would be at risk of having to pay anything out-of-pocket on top of getting nothing. I suggest discussing details around the design after the vote, if it becomes necessary. One of the key stated goals for Indexers is to simplify setting a stable effective cut %, which doesn’t change with either option.
This is an excellent point @warfollowsme! UX improvement is a significant motivator behind this proposal, and the implication of allowing negative cuts would be a significantly confused UX:
When positive, the cut refers to the proportion of rewards generated on delegated stake that the indexer takes as a fee.
When negative, the cut refers to the proportion of rewards generated on indexer stake that the indexer gifts to delegators to subsidise their APR.
Unlike positive cuts, that makes negative cuts completely incomparable across indexers, since depending on the size of an indexer’s stake, the impact of a proportionate negative cut on delegator APR could vary wildly.
To add some perspective to the points made on loss-leading:
I don’t see loss leading being a widely used strategy for large indexers. Large indexers already have benefits for delegators over smaller indexers, like less variance and a higher frequency in reward payouts for instance.
On the other hand, I think loss leading can be a very sound strategy for smaller indexers, especially for those smaller indexers focused on serving queries, because serving queries is creating value while indexing rewards are set globally and shared proportionally. So, by getting more delegation, you have the potential to create more value, and with that the potential to capture more value than you could have with your self-stake alone.
As a minimum stake indexer myself, I am currently aiming to give away ~50% of my indexing rewards to incentivize delegation so that when query fees pick up I am ready to serve as many as I can. I am also contemplating the idea of giving away all of my indexing rewards in the future and taking a higher than market rate query fee cut.
I think the ability for indexers to be able to come up with and execute strategies like these is integral to a healthy free market, so I would definitely want to see the range be -100%/100%.
As for the UX issue surrounding negative percentages, I think that is definitely something that we should put effort into simplifying for the average user, but I also think the average user would find this setup to be much simpler to understand than the current setup, so I wouldn’t let that be the only thing that holds back implementation if everything else is good to go.
I recognize the veracity of comparing The Graph protocol to other projects and utilizing industry benchmarks. However, each project has unique goals and operations that can skew the validity of some some benchmarks. We can use them as templates, but we need to make our own decisions based on what is best for The Graph protocol.
I agree with Jim that in keeping with the spirit of freedom we should allow indexers the option of offering negative cuts (Clarifying the “negative cut” wording would be beneficial).
All decision-making matrix discussions aside, Oliver’s data appears to indicate that we aren’t seeing an additional malicious actions from indexers offering negative cuts. To me, that renders its own verdict. If there is no evidence that something creates a problem, then we cannot logically assume that it will create a problem in the future. Also, we are addressing our current standing, and should future evidence reveal a correlation between negative cuts and malicious behavior we can address it at that point.
Forum polling is now closed and 67% are in favor of keeping the ability to set a negative value as the effective cut%. That means we need to revisit the algorithm which was initially proposed in the GIP draft. I have created a short video explaining the reasons why and also introduce some thoughts for both the new algorithm and UI design. Provide feedback and also share your own thoughts on this topic.
Thanks for the record. This is an excellent demonstration. My personal opinion is that we need to leave a negative option and not create another parameter but just change the meaning of the parameter when its value goes a negative to “give rewards from indexer self-stake”
Very much in favour. The current way it’s presented makes it quite tricky to evaluate delegation. A much simplified UX would make it friendlier to interact with.
