GIP-0002: Rewards destination for indexer's indexing rewards

Hey, I’m posting this to shed some light about why thawing periods exist.

  • Indexer thawing period: This period avoids indexers to easily escape a dispute that will result in slashing them, they commit stake and even if they unstake they need to wait and funds are still slashable.

  • Delegator unbonding period: This was introduced to avoid a single delegator to use the capital multiple times across multiple indexers. If a delegator could re-delegate multiple times within the span of a single allocation, different indexers could be creating allocations with the same capital.

The feature was not designed to lock participants for the purpose of restricting liquidity but to avoid exploits in the protocol economics.

3 Likes

Yeah, in an ideal world, both indexers and delegators should be able to have the same treatment.
Currently anything staked or delegated is subject to a 28 day thawing period, and that won’t change.

What’s gonna change is that delegators rewards will be automatically restaked, while indexers can potentially declare a separate address to withdraw rewards instead of restaking automatically, or leave it as is and let it restake.

If it’s not restaked automatically, the current solution doesn’t make those rewards subject to a 28 day thawing period and, if this persists, it will not be really fair, and adding the option for delegators to also be able to have a separate address to withdraw their rewards without a thawing period would be really cool (since those rewards couldn’t possible be double delegated, which is what the thawing period for delegators tries to achieve).

Another option would be to make the indexer solution have a 28 day thawing period, and that would keep fairness overall.

The issue with delaying this implementation is that most of the indexers have been doing work for free for the past 7 months, paying every bill out of their pockets, and while some can bear this risk, it’s been at least 2 months since they should have been able to pay these things with the rewards, and that could potentially mean that some indexers might need to stop their operations altogether.

This is clearly not fair for indexers either, since if they would be in dire need to pay for the indexing operation, they would have to pack their bags and leave for a month, potentially ruining their reputation (since they would leave their delegators in limbo for a month), while also forfeiting their rewards for the whole month (opportunity cost)

If we need 1-2 months to release the perfect fix, it might be too late for some, which is bad for the network overall, even for delegators, since having indexers go out of business can’t be something good for them. (if the perfect fix is making sure a thawing period is applied to the indexer withdrawal, it also makes them wait for another month until they can start paying for the infrastructure with their own work)

So, overall, while I do agree that fairness is needed, from my understanding this is still an extraordinary fix that needed a quick release so people can pay for stuff to be able to keep their infrastructure running, and in doing so, providing a business for both indexers and delegators to profit.

Maybe a middle ground solution would be to go ahead with the fix while making sure that the second fix gets underway as soon as this one is released? (to either apply this to delegators too, or add a thawing period to the withdrawal of rewards by indexers).

3 Likes

I think at this point this is the makings of a way forward, however the reality is that these proposals won’t happen at the same time. I think it’s reasonable that Delegators request some assurance that when the Indexer proposal goes through, that the next proposal on the agenda is reward mechanism alignment between Delegators and Indexers. This of course assumes that there is consensus on this balancing of the scales. I will certainly be supporting this unless I read a technical counter that suggests the change would be problematic to the future of the network.

So maybe this change will mean just matching what Indexers will get - compound/nocompound option and no thaw, or maybe it means compound/nocompound and 28d thaw for everyone.

In an ideal world, we tackle it all in one go, but unless we hear otherwise from the engineers and the complexity of bundling this all together, I suspect this is likely how this will play out.

4 Likes

I think even the saltiest of delegators is sensitive to the notion that indexers need to start getting paid so they can survive. If the 28 day thaw MUST go out the window for the indexer’s unstaked rewards, and the proposal to do that MUST be separate from the proposal to dive delegators the same option (I am somewhat unconvinced about either of those imperatives, but I do admit I might not be seeing something here) then I think, at a minimum, I would like to see language attached to the proposal for indexer rewards that acknowledges that a compromise in principal has been reached with delegators to extend the same rights to them… eventually.

How that language gets… put in to language… is important, but I can imagine supporting the measure in good faith even if the language was less than binding.

Still, it is my personal preference to simply keep the 28 day periods in place, give indexers access to rewards in 28 days, and then put the entire notion of 28 day thawing periods for all stakeholder rewards to a separate vote. That seems like the cleanest process to me, and there’s no reason to think it will add much delay. Who is going to vote against removing 28 day thaws? Not many people if it’s for everyone. I imagine that proposal could be drafted and find immediate consensus tomorrow.

1 Like

Still, it is my personal preference to simply keep the 28 day periods in place, give indexers access to rewards in 28 days, and then put the entire notion of 28 day thawing periods for all stakeholder rewards to a separate vote. That seems like the cleanest process to me, and there’s no reason to think it will add much delay. Who is going to vote against removing 28 day thaws? Not many people if it’s for everyone. I imagine that proposal could be drafted and find immediate consensus tomorrow.

I agree, 28 days for already staked/delegated, and vote whether rewards should be subject to any kind of thawing period, and if so, how long.

What I don’t agree is that it’s not going to add any delays, even if we went with the current “indexer-only” solution right now but with an added 28 day thawing period for fairness, we would still need to:

  • Implement the thawing period
  • Test the implementation
  • Audit it?
  • Deploy it
  • Wait 28 days for rewards

If we think we could deploy it by the end of the week, indexers would still need at least a whole month to get any kind of money flow.

If instead we go for the hotfix (which I think it’s only waiting for approval?, correct me if I’m wrong) and start the whole process for the permanent fix, given it’s most likely to get full consensus quite fast, the team could potentially start implementing it after deployment of the hotfix is done, indexers that need to withdraw some rewards can start accruing said rewards (since it’s not retroactive), get the money flow needed, and in the meantime the permanent fix gets implemented.

Once the permanent fix launches (whichever solutions gets chosen) everyone will be on the same leveled playing field, and indexers in need would’ve gotten 1-2 weeks to stabilize their economies.

Having said that, I would’ve loved for a permanent fix from the get go, but it doesn’t seem that it’s quite possible right now, without a major (1 month+) delay to start the money flow for indexers.

It’s starting to feel like a broken record in here, I think we can all take some learnings from this whole experience and potentially look at ways that discussions can be moderated in a fair and effective manner going forward.

I don’t see why a fix similar to this cannot be implemented for delegators inline with this proposal, and would expect that it shouldn’t take too long to implement given we are mostly there with the fix here.

There is actually good reason for having rewards be made available for disposal upon minting, which you might have missed in the lengthy discussions here and that is for tax purposes. In my jurisdiction (and I’m sure others) the amount owed for tax is calculated at the point the tokens are generated, if the price of GRT dropped over the 28 days after minting and tokens were only able to be withdrawn with that delay then we would be paying additional tax out of our own pockets.

I can see you want equality for delegators @Derkhersh and I don’t blame you, but I think the best path forward for you to fight for this would be to try and push for a rewards destination address be implemented in a similar way for delegators via the thread linked above.

1 Like

I think it is good to try to achieve fairness in how delegators and indexers use their capital, but let’s remember that they play different roles in the network. Indexers can be slashed while delegators don’t; should we also have delegators be slashed to pursue fairness?

The reason I don’t like setting a thawing period for free rewards (the not staked ones) is that we are adding extra complexity to the protocol for no purpose other than fairness and not as a mechanism to prevent economic exploits.

In my opinion, it’s better to spend our energy on a proposal that would avoid re-delegation of the delegators’ rewards so they can be withdrawn. Technically it will require some time of research to see how to implement it, possibly taking a snapshot of the delegation pool when a delegator stakes to calculate profit at any time and provide an exit. It is a bit trickier as potentially hundreds of delegators can delegate to a single indexer, we can’t do for…loop in Solidity to process each individual indexer at close allocation time.

By acknowledging it and tackling these as two separate proposals we could move forward while we investigate solutions for delegation withdrawals.

5 Likes

What delegator misbehavior would this be intended to prevent? If you can come up with some examples, then sure, I’m all for it. Bad action is bad action, and it should be prevented.

See, this is what still needs some hammering home. Fairness, even just for the sake of fairness is in everyone’s best interest. If delegators do not feel they are being treated fairly, why wouldn’t they just stake some other token? Fairness is not a 2nd order concern, it is a first order concern. Once locked wallets become unlocked wallets, delegations could plummet if delegators’ interests are forgotten. In addition to the competitive environment between indexers, there is a highly competitive environment between different protocols/ chains.

What I am attempting to hammer home here is that indexers would be wise to give ample consideration to delegator’s interests whenever they are proposing changes. In addition to avoiding some of the rancor and broken record stuff, it’s just good governance. If you leave it up to delegators to fight tooth and nail for their interests and only concern yourself with indexer’s concerns, this cycle is bound to keep repeating, and many will just walk away from delegating and choose instead to hodl. 10% APY (and it keeps going down with every additional delegation) is not that great when the asset is so volatile and easily tradable. 10% is great if you feel your interests are being protected. If not though? Not nearly enough of a reason to have your tokens locked for 28 when 4 billion tokens are unlocked in a few months. VC pump and dumps happen, and so at a minimum indexers need to avoid looking like they are lining themselves up for an easy cash out in May, at the expense of their delegator’s ability to do the same.

Like I said, at this point I think most delegators acknowledge that this train is mostly left from the station. What I think is still an open question is to what extent indexers will be supportive of delegator interests going forward, and whether they will start to anticipate these concerns as the prepare future proposals (as an aside, I’ve very much appreciated your willingness, specifically, to see try to see where delegators are coming from. Protofire is at the top of my list for my next delegation, if I decide to make one).

As is often pointed out, indexers “do the work” and delegators simply earn a “passive income.” From this delegator’s point of view, this last week has felt anything but passive, and I don’t want to continually feel exhausted from governance when delegating will only ever increase my holding marginally.

With all of this said, I feel the two sides are beginning to see each other’s concerns a bit more clearly, so as yucky as the last few days in governance have looked, this is a huge win. This is a political process, and occasionally you need a loud voice to pour cold water on things in order to break up tunnel vision. With my sunny disposition, I tend to gravitate to that role.

The more assurances delegators receive, and the more that future proposals pre-concede ground to the delegators, the faster things will move and the less back and forth we’ll need to get things done. Likewise, if delegators start making proposals more actively, it will be in our interests to attempt to consider the indexer’s side of things. We are all network participants until we decide to stop participating, so we want to be making it LESS scary for new and existing participants, and we want to build fewer things on a “trust us not to screw you” basis and more things on a “see, it’s fair, everyone is in the same boat here, here’s how we’re all exposed to risk and also protected from it” framework. New delegators almost always talk to one or two current delegators before committing. If the delegators they talk to have to mention that “yeah, i’m still delegating, but they’ve kind of made a bunch of changes that benefit the indexers but not me since my money got locked up… but do your own research and decide for yourself if you’re comfortable” that is decidedly NOT a good pitch. Let’s give delegators (read: lets give me) the ability to honestly say “The protocol is new, so some rules and regulations are in flux, but let me tell you what, they’ve done a great job balancing stakeholder concerns to promote a vibrant ecosystem.” That’s gonna sell a lot more tickets.

It may seem like a waste of time to consider the optics, politics or fairness of a proposal when you’re simply trying to pursue a technocratic fix, but if you hear nothing else from me please hear that it is actually a much bigger waste of time to NOT consider those details.

1 Like

The reason I don’t like setting a thawing period for free rewards (the not staked ones) is that we are adding extra complexity to the protocol for no purpose other than fairness and not as a mechanism to prevent economic exploits.

Totally agree, if they aren’t automatically re-staked, they might as well be completely free from thawing periods!

In my opinion, it’s better to spend our energy on a proposal that would avoid re-delegation of the delegators’ rewards so they can be withdrawn. Technically it will require some time of research to see how to implement it, possibly taking a snapshot of the delegation pool when a delegator stakes to calculate profit at any time and provide an exit. It is a bit trickier as potentially hundreds of delegators can delegate to a single indexer, we can’t do for…loop in Solidity to process each individual indexer at close allocation time.

I wasn’t aware of how difficult it might be to implement, that’s really insightful. Although if it does end up taking a long time to implement, or ends up being unfeasible, it might be worth considering putting the indexers hotfix under a thawing period, so that all ways for GRT to exit the protocol are lined up in a clear and transparent manner, and subject to the same restrictions.

I do understand that there isn’t a specific purpose in which rewards need to go through a thawing period, but if rewards for both parts of the current system can’t be treated 100% equally, the best way to handle that is to line them up as closely as possible so that nobody gets a big advantage, and thus, we avoid any unnecessary tensions.

I think most have been quite supportive, but just have a different lens through which they see things, and thus, have different concerns regarding proposals, which is expected when you have different points of view over the same subject.

Hopefully these kind of discussions allow us to both technically improve the protocol, as well as grow as a community.

Thanks for the kind words, really appreciate it!

Regarding this, I totally agree that those aspects need to be taken into consideration, and believe me, it’s not like they have been completely avoided, but sometimes you end up in situations that require to “rip the bandaid off”, so to speak.

That’s why the forum is incredibly important for the discussion and approval process of proposals, and why we all need to strive to make this an awesome place to participate :slight_smile:

4 Likes

To this end- couldn’t the date of a delegator’s last allocation received be timestamped to their contract, in one shape or another? If that was possible, couldn’t those funds be free to delegate to any indexer that has closed an allocation past that date? If they tried to redelegate to an indexer with an open allocation prior to their last received date, they would simply need to wait for their indexer of choice to close an allocation and then be allowed to hop on board.

This would also allow re-delegation of entire stakes, if we ever wanted to go down that road-- although I’m aware of some APY chasing concerns, and this could exacerbate the problem. On the other hand, it could fix that problem in the sense that delegations wouldn’t be as sticky, and so it would be easier for indexers to pry delegations away from another if that indexer’s rates start stagnating. (there is another issue, as I see it, though, of indexers not really being able to forecast their capacity if delegations were moving around so much. It’d be a bit like a a restaurant not knowing how many waiters they would have on any given night.

Hi @ari , @Brandon ,

It has been almost a week since this update and still no GIP nor snapshot vote has been published.

How soon can we expect this? I have set up a company structure and started expending from this in advance of rewards being extractable from the network and am hoping this can happen soon. Can you please update us.

Thanks,
Dan

3 Likes

This week I believe the GIP will be published . the vote will follow right after

5 Likes

Community poll is up on Snapshot →
https://snapshot.page/#/graphprotocol.eth/proposal/QmNTUFcx5SGt3Jd1heDmKa6Lh8WGmJnqKiii7H91RUAbKW

2 Likes

We are strongly in favor of the idea that indexers should be able to cover their operation costs using rewards but implementing GIP-0002 without a similar feature for delegators opens a possibility for economical exploit incentivizing and making off-chain reward distribution process more beneficial for delegators than on-chain. It can lead to transitioning towards indexers providing 100% reward payouts off-chain, which is not positive for the protocol.

Big indexers will be able to use it as a sale point to attract more delegators offering periodic liquid reward distribution, while small indexers won’t be able to provide such services due to complexity and high costs of manual distribution.

We would vote for the proposal if both features are implemented simultaneously or if there is another way to mitigate the economic exploit, but currently we plan to vote against, as even a temporary possibility of such behavior provides a competitive advantage and influence centralization in a negative way, should be prohibited.

Alex | p2p.org

4 Likes

Isn’t it a bit hypocritical for you, out of all the entities on the network, to talk about centralization whilst having 40% of the delegators on the network along with 20%+ of the network stake?

Also, if anyone plans on having your cuts set to 100% and distribute off chain, I wish you good luck with the custodial service you’ll have and the banking license that will be required for such service, otherwise it’s jail time more often than not, in most jurisdictions.

2 Likes

Thanks for sharing your thoughts.
Being a relatively big indexer doesn’t mean we don’t care about decentralization. Staking ratio is still relatively low (~25%) to draw conclusions. As the ratio will go up situation will change as we have reached max capacity and have limited capability to grow further.

The question is not about legal issues that might prevent such behavior, but about the protocol consistency that should not allow even a possibility of such an activity by design. There might be indexers that remain private, those can avoid legal pursuit.

1 Like

Implying that 25% of the network stake is low, makes me wonder what would you consider as high, lol.

Also, if you want to go deeper into the technicals, reaching max capacity today doesn’t mean your balance won’t go higher.

In fact, your capacity, at your current cut rate and network APY, grows up by 2.6M every week (~10.6M every month).

2 Likes

Here are some examples of current staking ratios in various networks:
Cosmos Hub [~67%], Kava [~50%], Tezos [~78%], Polkadot [~51%]

Overdelegation is a separate topic, I think It is worth discussing if it is reasonable to make it impossible by design or not.

Getting back to the GIP-0002, from the perspective of protocol efficiency I still think it is better to implement both features simultaneously or suggest another mechanism to prevent such behavior.

1 Like

I wasn’t referring to overdelegation. I was referring to your stake increasing due to your positive effective cuts. :slightly_smiling_face:

The family of economic attack you mention is already well known by the community and discussed at length. Reverse sandwich attacks have been detected as indexers, desperate to maintain indexing operations but also claim rewards, have used a reverse sandwich attack on reward cuts to siphon indexer rewards through delegators, avoiding the need to cease indexer operations for 28 days in order to reap indexer rewards.

The state you describe around big indexers doing offchain payouts would at best be a temporary state as most agree that delegator rewards should also get the same treatment as this proposal. What business savvy indexer would invest the time in becoming a custodian/bank when they know it will be a temporary situation? There is nuance here and we do a disservice to ourselves if we ignore it.

So the question really becomes this: which is more dangerous for the network - the most knowledgeable indexers with large opex and tax bills having to cease operations and leave the network due to nearly a year of zero revenue, or a period of time where indexers that wish to become custodians of customer funds take that risk in order to grab more delegations until delegator reward fix is also in place.

edit: i should also add that i agree that simultane
ous implementation is absolutely the ideal solution. I just don’t think it’s realistic in terms of timescales.

6 Likes