Good summary Juan!
The implementation being tested is one that avoids re-staking and sends rewards to a destination address defined by the indexer.
Why do we want to add a feature that let indexers avoid restaking?
Because by default, reward tokens are put back to the stake, usable for allocations, under slashing risk and subject to thawing period.
Isn’t that good? What is the issue with having them restaked?
That if the indexer wants to take some of those rewards back to pay operations they will need to unstake, and after thawing then withdraw, those funds are sent to the TockenLock contract. This contract will only see surplus tokens to release when it has enough balance in them (meaning unstaking too much).
Why aren’t the reward tokens under a thawing period in this proposal?
Because if the indexer sets to not stake, it means these tokens are not usable for allocations, thus not slashable, meaning we don’t need a protection for the indexer escaping with these funds commited for security (thawing period).
Can’t we add a thawing period for indexer rewards so that it works the same way as delegators’?
The difference is that delegators rewards are re-delegated so they are available for use in allocations, that’s why they have thawing period.
Anyways, we could add a thawing period to indexer rewards. It would possibly mean using the alternative implementation that has a separate rewards pool and on top of that add all the thawing logic. https://github.com/graphprotocol/contracts/pull/451
Could we also make that delegators take their rewards out without redelegating them?
Possibly yes, it needs some research time on how to implement it. Potentially having a different state variable to account rewards so they are not used by indexers on their allocations and taking a snapshot of the delegation pool when you enter it so that new delegators don’t take your rewards share.
In summary, I think that for equality it is technically better to explore how delegators rewards could be free too as the thawing period was meant for a different purpose. If we were to add a lockup to rewards it will be a separate testing branch and means leaving unused state variables and logic if we know we are changing it later.