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

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:


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 @ariel , @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.



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


Community poll is up on Snapshot →


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 |


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.


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).


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.


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

It would be interesting to have some kind of ETA, if possible, to have an idea of how long an implementation for Delegators would take, to allow them to work under the same rules for rewards withdrawal. Would it be weeks/months?

Everyone here could then take it on-board as part of the discussion being had here. And if it were a short timeframe, you may see positive feedback (re: waiting) even from some of those Indexers who have been vocally worried about covering their costs.

Having both proposals considered at the same time would be preferred by everyone and not make one group feel at a disadvantage. Just a thought. Of course Indexers want this one to go through, as do some Delegators from what i’ve seen.

But most also want equal considerations, and personally i’d also prefer to not see the divide between Indexers and Delegators widened by what can be perceived as unfair advantages, if we can do that without risking losing a large portion of the Indexer set.


Hi @Fattox, @Dave is currently doing some research on how that could be implemented.

For context, the contracts distribute delegation rewards by adding them to the delegation pool, as it is the only way to distribute tokens to many delegators delegating to an indexer efficiently. So when rewards are deposited, your “shares of the pool” are worth more.

As for the solution, we have some ideas. To separate profit from the rest of your delegated stake, we would probably need a different pool just for rewards and take some snapshots of your entry/exit points. Additionally, check for nasty edge cases and think about it from all angles.

The process is to write a draft describing how that could be implemented and publish it the same way I did last time with GIP-02. Then get feedback, work on a PR, run local tests, schedule an audit, deploy on testnet and finally upgrade with community support. We, as a community, are going through this process for the first time with GIP-02 and 03, learning the time it takes to go from proposal to mainnet.

I think that Dave can probably have a draft proposal by mid or late next week for potential implementation, but that’s just the starting point.


What business savvy indexer would invest the time in becoming a custodian/bank when they know it will be a temporary situation?

Have you thought of exchanges that most likely have such permissions?
They can potentialy take advantage of that situation. If staking to an exchange will give you liquid funds immediately, they will be able to attract a lot of delegators.


That’s fair, I had not considered exchanges. But I think the same point stands - if it’s a temporary situation, why invest the effort? Purely as a marketing effort to build a delegation? It seems unrealistic to me, but in honesty I don’t know how exchanges assess these opportunities.

‘Temporary’ is a very subjective term. What if due to unforseen conditions it won’t be possible to finish the feature or will take much longer or whatever reason. Basing reasoning on assumptions we rely on our subjective feelings instead of a protocol architecture.

Our voice is just one among many and doesn’t have a lot of power behind it, compared to some; but we think that it’s a significant opportunity for indexers to build staking audience using economic loophole as lever and we know a thing or two about that.

Legal side of it is also questionable, e.g. all Tezos bakers operate in a similar way and I didn’t hear about any of them being under persecution; and even if you’re right it can be circumvented by making a smart contract to accept and distribute rewards.

So we stand against unless it’s tied to stakers rewards liquidity or mitigated otherwise.


I think we can all agree that indexers being able to withdrawing rewards without unstaking is not the problem.
However, withdrawing rewards without a thawing period might create a correlation between “rewards remaining in the network” and “token price”. E.g. a surge in price might create a surge in withdrawals, while a decrease in price would keep the rewards in the network. Letting the market dictate actions taken on the network probably isn’t a good thing. A thawing period could prevent this.

1 Like

Indexers won’t be able to withdraw rewards that have been re-rolled back into the stake.

They’ll have a switch between keeping rewards in-protocol and locking them, or having the rewards sent straight into another wallet.

Meaning, if I make 1M GRT whilst having the option disabled, I won’t be able to take them out.
We’ll only be able to withdraw future rewards, with the option active. That option is completely up to me as an indexer, if I set it on or off.

But more often than not you’ll have to restake in order to maintain your network APY and not get outpaced by other indexers that have that option active and continuously compounding their rewards. :wink:

I don’t mind to have a thawing period, but I find it unnecessary, and Ariel also said the same.


Alright, that makes a lot of sense and makes thawing kind of stupid to have. I was under the impression the already compounded rewards would be withdrawable after the GIP execution. Thanks for clearing that up. I think a lot of people misunderstand this, judging by the heated discussions on 3rd party channels.