We have received a lot of feedback from the Delegator community since mainnet launch in Dec last year that are reflecting on the Delegator experience at The Graph. A cross-network group consisting of Delegators, Core Devs and Indexers have worked together to consolidate all of the feedback we have received in many different Forum posts. I want to thank @ari , @Topher66 , @chris , @cryptovestor and @davekaj for your engagement in a number of workshops over the last few weeks that has produced this Forum post which presents Delegator feedback in one holistic view.
Goal
We are looking to achieve two main goals with this very Forum post:
Transparency – a number of Forum posts we reviewed are dormant at this point and did not conclude with specific proposals that received broad community support. The Prioritization List (below) keeps these discussions on the radar to ensure they are not being forgotten. However, many of those Forum posts still require deeper community discussions to gain consensus and better understanding of detailed requirements. Therefore, the list is not meant to communicate a commitment to implementing solutions to the listed items, but rather aims to capture those discussions for everyone’s visibility.
Alignment – the Prioritization List shown below aims to reflect broad community sentiment, sorted in the order of importance from top to bottom. That list is a product of many Forum post reviews and discussions within the workshop group. For the Core Dev teams, this list should inform their own roadmap around protocol experience enhancements for delegation and the opportunity to align their prioritizations with the views of the community.
Prioritization List
We have various data points included in the below table to create some clarity and common understanding. We have given each item a Name, which could be an issue or an idea, and we provide a brief Description of what it refers to. We have categorized items as overarching discussions that may have taken place across different Forum posts.
At a high level, we then directionally discussed what the community aimed to solve for by raising these items and we evaluated their Protocol Impact, meaning whether those requests have a general positive or negative effect on the protocol vis-Ă -vis its Design Intent. Our purpose was to provide some initial feedback to the question: will this result in a positive or negative outcome for all network participants as well as the integrity of the protocol itself? Naturally, these are rough assessments and should merely inform any deeper discussions the community may have on those items in the future.
In a similar approach, we also assessed Feasibility of each item. These too are rough assessments as we often did not have specific requirements to perform a detailed evaluation. We generally considered the impacted systems and also interdependencies to other codes and parameters in order to gauge anticipated complexity.
The Status column provides an update on where each item is today with regards to its progress:
Community Discussions – items with this status are still early on in the process. We were not able to confirm either community consensus, detailed requirements or both. It is generally fair to assume that there is currently no active IT development work around this item that aims to solve it. Should you feel strongly about an item with this status, then please create a new Forum post or resume discussions in an already existing thread in order to bring back attention to it (click Forum Link in the table).
Research – Items with this status currently have either technical or economical research being performed in order to assess feasibility or protocol impact. Feel free to raise follow-up questions in associated Forum posts if you would like to receive an update to the progress on any of these items.
GIP Development – items with this status are in active development for a protocol update. Progress on these items will generally be communicated in our monthly Core Devs Calls as well as Community Talk. Feel free to raise questions during these calls!
Polling/Voting – this status reflects the last major step in the governance process that typically concludes with a Council vote seeking to approve implementation.
Please note that you are able to scroll the table up/down and left/right to get visibility to all data points mentioned above.
What You can do next
There are a few things you can do now in response to this post:
Prioritization Feedback
The workshop group has attempted as best as possible to prioritize the items in the order we feel the community views them, mainly based on the activity levels we have seen in various Forum posts. We very much like to hear from the community if we got it right and everyone is welcome to provide feedback
Raise New Ideas
If you feel that there is a Delegation Experience item or issue missing from this list, please create a new Forum post and open up new discussions around it. The above prioritization list is not set in stone and our intention is to establish a living document. Which gets us to …
Own the Prioritization List
The workshop group has created the Prioritization List with the intent to implement a format and process that can be repeated in the future with more ease. This post is titled #1 and we plan on getting together again in about three months for a review: add new items, remove completed ones, change prioritization where necessary, provide updates in Notes and publish an updated version #2. This can flow into a regular cadence where we get together once a quarter in an effort to provide the community with the latest update on Delegator Experience Enhancement Prioritizations. The workshop group is not exclusive and everyone is invited to participate. It would be great to see the ownership of this list transitioning over to the Delegator community in the next couple of quarters. If you are interested in participating in that, please reach out to me via discord, or any other workshop group member.
Hi,
I am so glad that this is being taken up by the team. I really love The Graph but in my view, the complex rules at the moment is seriously hampering delegation of GRT. Speaking for myself, I can say that I only have about 25% of my GRT delegated atm, and I did this mostly to get a feel for how it works. On other networks, I have 100% as delegating/staking is the way forward.
a) In my view, there should be a way for delegators to rate indexers. This might already exist, but I have found no link to it.
b) Not sure why indexres can change the cut they give to delegators. This only adds extra anxiety for delegators as they can never be sure of the terms on which they hand over GRT.
c) Frankly, the cut for delegators is quite low. Generally, 10% is easy to find on others networks. While I love the idea of The Graph and the open community, many would just go somewhere else.
d) The delegating page explaining how the cut is derived has some formulas that honestly come of as quite the mumbo jumbo. There must be a simpler way to explain it. While the math checks out, many non techies’ eyes will just glaze over when they see those formulas and to become a mainstream network it needs to be explained much more succinctly.
d) I have been a delegator for about a year, and I still have the remaing 75% of my GRT to delegate, mainly because researching indexers is quite a big task. Having a central register where people can leave opinions about them would help out a lot.
I hope some of this is useful, otherwise just reach out :).
Thank you for the feedback, let me provide some answers to your questions
a) the Graphtronauts team has developed such a feature on their website where you are able to provide ratings to Indexers you are delegating to. You can find that here: Network - Graphtronauts
b+d) Indexers need to be able to change their rewards cut settings to respond to delegation changes and their operational cost model. We do currently have the exposure for what is called a sandwich attack where an Indexer can change the cut settings right before and after allocation close, which can be interpreted as a dishonest act towards delegators. I am only aware of one case thus far, so it’s a very rare event. However, this is being addressed with the Stable Delegation Rewards Yield proposal, which implements a reward cut settings lock at the time an allocation is opened. It also introduces a simpler method for rewards cut settings where it will be easier to interpret “indexer cost to delegators”: 10% will in fact mean an indexer retains 10% from delegations then, and there is essentially no more need to calculate an effective rewards cut.
The other d) We have a number dashboards (Graphscan, Graphtronauts, Stake-Machine, etc) that show different indexer analytics. We emphasize getting to know your indexer and we have a series on that here in the Forum where over 15 Indexers have been introduced in-depth thus far. Discord provides the opportunity to directly engage with Indexers. Building trust and relationships with Indexers is something we strongly recommend to Delegators.
Looking forward to your continued feedback to drive changes you would like to see happening around the delegation experience. A key message from this thread is that anyone is welcome and encouraged to engage in that, as we are a decentralized ecosystem that requires community members to actively voice what is important to them. Thank you for that!
Hi everyone, very happy to see this post. Regarding prioritization, the most important issues for me are:
Redelegation/Delegation Costs - I would very much appreciate a way to redelegate to another indexer without having to withdraw and then delegate again (similar to the Cosmos blockchain). This is important considering that indexers can change their reward cuts, so we need a way to respond accordingly and move our delegation, with less financial burden.
Clear APY for each indexer (not on list above…maybe related to Indexer Costs/Shifting APY Levels?) - Currently we need to go to Graphtronauts or Graphscan to get an idea of the rewards we can earn from delegating to each indexer. But Graphtronauts calculates rewards for delegators on a 28 day average and Graphscan calculates rewards on a shorter period (24 hours I believe?). It’s not clear if these two data points are just the same number calculated for 2 different time points, or if they are calculated in different ways. In addition, do they take into account that different indexers release rewards on different time frames? The “allocation closing interval” is reported on Graphtronauts, but I don’t think it’s reported on Graphscan. I believe the average time to close an allocation is very important in regards to compounding interest over the course of a year, but it’s not clear how, or if, this number is integrated into the APY-type numbers on Graphtronauts/Graphscan. The different reward cuts for indexers are already complex (and in my opinion hard to understand), so a great way to simplify things would be for The Graph to provide a clear current APY number for each indexer, along with a history of their APY as well. And importantly, this APY number should take into account the average time it takes the indexer to close their allocations, because if I understand correctly, the average time to close an allocation can impact APY through compounding. If delegators had this clear, improved APY metric, we could make much more educated delgating decisions.
28 day thawing period - I think the community would appreciate a shorter period (I’d prefer 14 days). Like my first point above, this is important considering that indexers can change their reward cuts. So we need a way to respond accordingly and move our delegation, with fewer negative effects.
Howdy everyone
I wasn’t really sure of the best way to format this response, but here goes nothin’…
I believe that several issues from the chart that @Oliver posted can first be consolidated, and then resolved/refined in a much more efficient manner.
Mobile Delegation - IMO this is the “low-hanging fruit”, if you will. The entire Cryptocurrency space relies heavily on a users’ ability to quickly, effectively, & securely access a dApp, DEX, Wallet, etc. One of The Graph’s main functions will be catering to the needs of dApps & mobile platforms; It only makes sense that The Graph’s own network participants have readily-available, reliable access to the protocol via cell phones & other connected devices.
28-day thawing period - I understand the intent of this 28-day period, as well as the frustration caused by it. I would suggest that this time period remain unchanged. However, allow for two “perks” to offered to Delegators who opt to use this 28-day period
Delegation rewards will still accrue during the undelegation period
These users will be given the option, as mentioned by @crickhitchens , to transfer their delegation to another Indexer rather than withdraw it.
14-day thawing period - Delegators, for whatever the reason, should have a faster option for withdrawing their funds. As a “penalty” for potentially causing Network instability and/or issues for Indexers, those who choose this withdrawal method would not accrue delegation rewards during undelegation, nor would they be given the option of transferring their delegation to another Indexer. The additional benefits offered to those who choose the 28-day method will further incentivize long-term delegation, as well as provide stability & consistency for other participants and the Network as a whole.
Over-delegation / Stake Centralization - Ahhh, yes. The hot topic, of late. I will make this brief, and would love to hear some constructive criticism and/or objective facts in response to this proposal. Please keep in mind that I am attempting to address several issues:
Indexer Overflow - When an indexer is deemed “over-delegated”, she or he may continue to accept delegations. However, the Indexer’s effective reward cut will be locked in place for the duration of the time spent “over-delegated”. Additionally, all over-delegated GRT must be reallocated (in the form of a Delegation) to a smaller Indexer. The Indexer chosen to receive this Delegation would be selected by way of a Snapshot vote, from a pool of candidates provided by the Graph Foundation. A system like this would ensure that every Indexer, regardless of size, is given ample opportunity to succeed. Additionally, it should raise self-awareness and help large Indexers to remain focused on all that is decentralization. Who better to raise up a fellow Indexer than another Indexer?
Mandatory Monthly Cooldown Periods - Consistency and security are essential for the sake of all Network Participants. Minimum, mandatory Cooldown Periods should be implemented. In my eyes, these would be aligned with the first day of each calendar month. 12 periods a year, with certain tolerances being permitted at each consecutive month. For example, lets say an Indexer wants to chop 15% off of their Query Fee Cut. To hinder this, let us assume a +/- 5% monthly tolerance. This way, it would take an Indexer 3 months to procure that 15%, rather than at the blink of an eye. It would force Indexers to display/offer more accurate/reliable/sustainable Effective Rewards Cuts/APYs to current and future Delegators, while also providing security and consistency.
“For every action, there is an equal and opposite reaction.” We all must be aware that our individual “wants” for The Graph will have the potential to negatively impact other members of this Community. Here’s to finding equilibrium
