ABIs are generated from the repo and placed in the /build folder when you do npm install && npm run build.
You can get it from this gist too Graph Protocol - StakingV2 ABI (indexer-rewards) · GitHub
I’m just playing around with developing golang cli tool to manage allocations to be free from all these npm stuff, so if there will be a chance to have up to date ABIs inside repo that would be nice.
Thank you for gist!
I have tested setting the rewards destination address to ‘0x0000000000000000000000000000000000000000’ via remix and it has indeed reverted the behaviour back to re-staking instead of distributing to the previously defined address. 
5 Likes
Worked for me as well, gas used 243,291
5 Likes
So,
Did we finally decide to go with Option 1 - direct tx to destination?
Are we planning to test Option 2 then?
Regards,
These are the mainnet addresses.
No, they’re not.
They’re Rinkeby.
EDIT: correction, they’re both mainnet AND rinkeby
Everything that’s under "1": { is chainID 1 which is mainnet.
Everything that’s under "4": { is chainID 4 which is Rinkeby
1 Like
Status update:
- Testing by the community of indexers on testnet so far has showed no errors. Everything looks good.
- Preliminary audit report from open zeppelin looks all good, only minor changes, mostly around documentation.
- On track to do a snapshot vote this week on this proposal.
- We are testing a safety script for updating on mainnet which is looking good.
- The GIP process was laid out in the Townhall today, so now everyone should be able to understand how we will get this proposal to the Council.
So in summary I would say all the heavy lifting is done. It is mostly just coordination of all these moving pieces, and then also being extra careful with the actual upgrade on mainnet.
It is kind of hard to provide a final date for any of this stuff. I personally don’t really have any say here - ultimately it comes down to the council passing the vote. Once that is done, Edge and Node can deploy the fix to mainnet.
But, as someone reading through this forum and understanding what all of the moving parts mean, if I had to guess, maybe end of week next week?
I think overall as more GIPs are passed, everyone will understand the timelines on these proposals better. Even from the councils perspective - this is their first proposal they must vote on. Some of them are very busy with their full time jobs and likely the coordination around the vote might take a few days longer than it will in the future when these processes are streamlined.
8 Likes
We went ahead with testing option 1 as it is a simpler implementation, it requires less interactions, one less state variable and the gas reduction was not that great with option 2. We could make it more complex on a new version if we all find it necessary.
1 Like
Hi Dave,
How is the snapshot coming along?
Will the council await to see the results of this before voting themselves? If so, will the snapshot need to be left open for a given window before they can use that data?
How is prep for the mainnet upgrade look? Did the safety script perform as expected in your tests?
Thanks,
Dan
Hi Dan,
Latest update:
- The audit went good no critical or high severity issues.
- We added a test to the repo using openzeppelin-upgrades that helps finding any issue with layout and storage updates, it is working. Set indexer rewards destination by abarmat · Pull Request #450 · graphprotocol/contracts · GitHub
- We are writing the proposal in GIP format to share today.
We are mostly on track with what Dave shared in a previous message, probably submitting the Snapshot proposal early next week. About the proposal window, I think that 3 days is more than enough, I’ve seen that as a typical duration used in most projects.
As for the Council decision, they would probably want to see: the motivation for the change (forum, GIP), technical solution (implementation contract deployed and verified), community support (snapshot, forum).
5 Likes
Thanks for the update Ariel, sounds good.
It does seem like we’ve skipped half the debate on this.
The first order concern is that indexers must shut down operations in order to draw on any of their GRT, as rewards are locked and it is not easy for them to unstake. This can be addressed before we get to the second order concern of whether or not indexer rewards should still be subject to a 28 day cool down.
We should really consider de-linking the two concepts before putting anything to a vote, as it is quite likely that many would agree with the first order who may not agree with the second order.
the following is mostly a repost of a comment in a separate post that is probably best served by being placed here instead
While most would agree that indexers should be able to draw a more active income from their operation, I’m not sure that there is consensus amongst all participants in the network that they should be able to do so without a 28 day lockup.
The rationale is this:
Indexers should not have the exclusive ability to “time the market” with in-network funds.
Yes, price volatility on the markets and variability of gas costs means that an indexer won’t always know exactly how much GRT they will need a month from now to meet their expenses. To mitigate this, indexers can choose to move more GRT out of network than they anticipate needing, and keep that surplus as a rainy day fund. The drawback, of course, is that these funds won’t be generating new rewards. But this GRT would essentially be “cash on hand” and “cash on hand” earns a maximum of, what, .5% APY in a traditional fiat bank account?
This seems fair and equitable for all parties.
If this were the system, I’m not really sure that any changes to delegator unstaking rules would be required. Delegators can already unstake a portion of their delegation without unstaking the rest, subject to the 28 day hold- so as it stands delegators can already choose to actively draw on rewards if they so choose and gas isn’t prohibitive.
No one should really want network players to be incentivized to hop on and off network in order to chase the markets- as this could be a wildly destabilizing! Thawing periods ought to be required for any removal of GRT from the network, regardless of network role.
While I understand there may be tax benefits for certain indexers to withdraw immediately, as a global, decentralized entity The Graph probably ought not concern itself too much with the implications of a near infinite amount of tax jurisdictions, and should instead focus on not promoting sudden swings in indexer/delegator capacity.
In other words:
Indexers having to stop allocating to realize any income = bath water
28 Day cooling periods to withdraw in-network funds = baby
Let’s throw out the bath water, sure, but only once we’ve done that should we think about what to do with the baby.
3 Likes
I wouldn’t recommend adding the 28 day thaw for indexer rewards to this proposal. It should be a separate proposal since its a separate topic, that needs to go through its own audit. We are past the audit/change point now for this proposal. We all must value the process.
Additionally, each indexer has been working since June 2020, putting up to 20+ hours a week, contributing to the protocol, and investing our own money in server fees, and writing code/applications. Each week we continue working many hours. We still haven’t seen a single penny back for all our time, energy, and funds.
Delegators have been able to take out their rewards. If Delegators want lots of indexers to stay around, then indexers should be paid for their work.
3 Likes
Yes, delegators have been able to, after a 28 day thaw.
Indexers could be paid for their work if a 28 day thaw was still a standard feature for all in-network funds being removed. This is not engaging with my concern at all
I agree we must value the process. What I am suggesting is that linking two separate concepts into one proposal is bad process. If both ideas are good and popular independent of each other, they can be voted on separately. Similar to how the proposals to remove the thawing period for indexers is not linked to the removal of thawing period for delegators.
If this was a big omnibus bill or some sort, that fixed 12 different things, sure. But this is not what this is.
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.