Implement a token burn on indexer rewards withdrawn to a separate address via GIP-0002

With the voting for GIP-0002 skewed heavily in favor of indexers, I’ve seen a lot of FUD being raised over the prospect of potentially hundreds of thousands of tokens per day being dumped into the open market. While I understand that indexers would like easier access to these funds to help cover operational expenses, I believe that their needs to be some effort taken to counterbalance the effect on the tokenomics.

How do we feel about a 0.5%-1% token burn on withdrawals make to separate addresses as per GIP-0002?

I run a windows PC and am not a solidity(?) developer, so I don’t think I can make a formal proposal on snapshot as I can’t link anything to code on radicle…I would like to push this forward though, so any input / advice / thoughts about the idea would be wonderful.

24 Likes

Also would like community thoughts on a cap on the amount of tokens which can be withdrawn? Possibly a percentage or hard cap, or both, based on expectations for reasonable operational expenses.

10 Likes

I am in favor of this. Too much control in the indexers hands. Voting is skewed to the highest group of bag holders.

Anything for indexers will be passed. Anything against indexers will have a much higher hurdle. If you say this is not true, 99% passing rate is pretty telling. I would like to see how an equal benefit for delegators would be voted on surely won’t be anywhere near 99%.

What is a business expense? How would that be determined? What are the guidelines and parameters? How will it be enforced? Who’s auditing? What’s the cap? Was this not vetted prior to launching?

Delegators are just as important to the health of the network but I don’t see much support in this area.

Anyways already voted. Good luck.

17 Likes

I like the idea of a cap or something that doesn’t allow them to turn it off and on at will.

10 Likes

I also like the idea of tracking, logging and reporting that is publicly available.

11 Likes

I would say 1% burn rate on withdrawals from the network is ok to prevent dumping and instability of the network. I’m also thinking someone should propose a way for indexers to stake up to 50% their rewards for community liquidity in something like Bancor to pay out a token pair to give indexers higher liquidity to cover operating cost and lessen the problem by giving them a way to receive limited payouts as operating cost increase and with curation coming. 48% or revenue operating cost is usually a good target in the business world for an efficient company. I would also say if a indexer chooses to cash out more that 50% of their rewards their delegators should be able to transfer indexers without thaw penalty. Staking in the liquidity pool would be the exemption for a way for indexers to still get access to faster funds in a separate coin while maintaining stability of the network and managing circulated supply. Indexers would be required to provide advanced notice of intentions by 10 days and discussion sheets to delegator on how the rewards pull will be used to the advantage of the index group to encourage delegators to remain with them similar to how companies provide guidance when they do a secondary listing and issue more shares of a company stock.

5 Likes

Also, something needs to be done about how the indexers change the % right before closing the allocation (was this called sandwich attack or something?), and those indexers that go mia after we spend our own money on the delegation fees. We already have so little power AND we gotta pay for the risk of getting burnt like this? I don’t see how this will attract any new ones to delegate their grts. I understand the importance of the indexer’s roles, but please remember that there are alot of us delegators that back up the project as well. We want our voices to be heard too, please! :pray:t2::pray:t2::pray:t2:

4 Likes

The highest groups of bag holders aren’t delegators nor indexers, as you can see by the staking metrics:

image
image

So, there’s more GRT unstaked/undelegated than staked/delegated.

The voting is normalized so that all three groups have equal voting power (33% each), the only difference right now is that indexers tend to be more engaged in the network, thus are more likely to vote, while delegators aren’t actively voting as much (or maybe they are but just are supporting GIP-0002 more often than not?), let alone the biggest group which is just token holders, most likely 0 participation in the voting process since they aren’t even delegating.

This is literally the first GIP, and probably is close to 99% approval since most active members agree that the solution is needed and is needed fast, because indexers haven’t been able to pay for anything (with their rewards) for up to 8 months and counting, and the only way the can do it right now would screw them and their delegators as well by stopping operations for 28 days, which isn’t good for anyone.

Also you are making assumptions on whether future improvement proposals would be approved or not based on whether they benefit delegators or indexers while we are just having our first voting phase and have no further objective evidence of that being true.

To give you an example, we have discussed another proposals which would greatly benefit delegators by heavily improving the cooldown system, so it’s more clear and beneficial for them. That proposal should be approved quite easily, unless there’s some technical limitation to the implementation that I don’t know about.

There are also some discussions to level the playing field for delegators going forward, so that they have the same access to rewards as indexers will with this proposal, the only reason that the two of them aren’t voted in the same proposal is that there are technical limitations on how to implement the same feature for delegators, which delays the delegator implementation.

Since the indexer solution is time sensitive (because it’s been already 8 months since most of them started working basically for free), I don’t see why this can’t be approved as quickly as possible, since it’s not a retroactive fix (meaning that all the rewards generated up to this point WON’T be accesible for indexers to withdraw), and most likely there won’t be a lot of GRT generated and withdrawn by indexers by the time delegators have an answer on how to level the playing field.

While I do agree that I would have liked for this GIP to go out with a 28 day thaw for indexers instead of instant withdrawal (so the GIP would pass without any kind of tensions because of misunderstandings), adding that feature would take valuable time in a time sensitive situation. (Re-implementation, testing phase, audit phase, proposal discussion again, proposal voting again, council meeting again).

Another thing to take into consideration is that everyone is just assuming that indexers will dump when the GIP is released, which makes no sense, since indexing is literally their business, if GRT goes down, so will their business…

Also while there’s no reason for indexers to dump GRT (they will use part of the rewards to pay for the infrastructure, so indexers selling GRT is of course intended, just as miners selling ETH or BTC to cover for their costs), you could also argue that they could technically do it anyways by stopping operations and withdrawing 28 days later, since the indexers will always be the first to withdraw if they indeed intended to be malicious, because they will be the first to know they stopped operations, and thus triggered the 28 day period.

10 Likes

I think you are making some of your own assumptions, here. It’s possible you are right, just as @kujiin could be right in his comments… but without some rules in place, anything could happen. Getting a token burn mechanic in place & setting some rules we can all agree on regarding how much can be withdrawn at once would restore some confidence which, if you look at CT, you’ll see has faded as people are learning more about GIP-0002.

5 Likes

I appreciate the thoughtful feedback.

Just as I am assuming, this is also an assumption as to why this is being passed with 99% efficiency.

My longest standing question regarding this is was this not known prior? Did the network costs sneak up on us? Why was this instituted in the first place and why the sudden change after launch and 28% staked in the network?

The way I read some of these posts, some indexers make it sound like they are ready to go out of business tomorrow if they don’t get these changes immediately. This needs to be properly vetted with better parameters in place for the overall health of the network. We cannot operate off of good faith.

I don’t believe (nor do I want to believe) that indexers will look to dump GRT but this is also an assumption. How will new bad acting indexers looking to exploit the network see this? I believe we need better parameters to ensure this doesn’t happen.

Looking at the previous posts, I just see many or the same few indexers attacking people who post in favor of delegators. Calling them “couch gods”.

We need our voices heard and we don’t need to be talked down to from indexers.

5 Likes

Ultimately the idea that the playing field should be fair for indexers and delegators is a good one.

Likely the simplest of solutions has a better chance to get accepted. To simply allow delegators to release rewards the same as indexers is pretty straightforward. I am working on something to allow the contracts to work like this. Hoping to post soon!

16 Likes

Hi @davekaj and thanks for the reply. It’s good to know that us delegators have support from Moderators & other folks close to the project.

That said, although I am not opposed to what you’ve suggested, I think allowing everyone to dump rewards would simply further compound the problem without some way to counterbalance (as you propose) EVEN MORE tokens being dumped on the open market. As I am not a solidity developer, I can’t be sure… but I am a software dev, and implementation of a token burn on rewards withdrawals not subject to a 28 day thawing period does not seem very complicated to me.

I would love to hear your thoughts on the token burn idea. Is it simple or not? Do you think allowing everyone to dump rewards would negatively affect the token price? Do you think a burn would help offset the sell pressure?

5 Likes

Love it, thanks @davekaj

3 Likes

In no particular order, ideas here:

  1. Token Burn
  2. Tracking, Parameters and Reporting
  3. Capping or something in place to prevent indexers to click on and off at will
  4. @BeagleKyle solution
  5. Delegators need better support from indexers

The overall network should be considered at all times.

4 Likes

When mainnet launched, already existing indexers that have participated in the network were going to be able to withdraw rewards generated, but because of an oversight on how the token lock contract works, the only current way for indexers to withdraw their rewards is for them to fully unstake.

This is because most indexers are using token lock contracts as their stake (since most indexers either use their testnet participation reward or early investor bags as their stake, and those are locked behind those contracts).

The token lock contracts themselves only allow for surplus to be withdrawn, what this means is that you need to unstake an amount of GRT greater than the amount of GRT locked that the contract has, and since all indexers have their GRT locked for 1-2 years, they have to unstake pretty much 100% of their GRT to be able to withdraw anything as surplus.

That wasn’t intended, rewards were intended to be withdrawable without the need to fully unstake.

So, to sum it up, yes, this wasn’t an already known rule that we had prior to the mainnet launch.

After indexers realized that, discussions for a fix begun, and the current GIP-0002 proposal and it’s implementation is what came up as a solution to the issue.

Indexer infrastructure isn’t cheap, and some indexers have been paying them with no income from their work for at least 8 months straight, that’s why it’s being discussed as a time sensitive release.

8 Likes

While we are all making assumptions (since we can’t know what will happen in the future), there is no real incentive for indexers to rush the market and “dump” GRT, since this proposal will only let them move really small amounts of GRT (compared to how much stake they have in the network as well as already settled rewards that won’t be accesible.

Why would an indexer dump GRT and lose money on the rest of their own stake?
Even if there aren’t any strict rules for indexers to not dump their GRT, there are a lot of economic incentives to prevent that.

First of all, they still have GRT locked, so dumping will probably impact them the most, since they are the ones with the longest lock periods.
Secondly, if they would consistently sell their rewards, they would start becoming overdelegated quite quickly, and even miss out on more rewards because of selling instead of compounding their rewards.

Also, as I stated earlier, if indexers were malicious and wanted to dump and sell the rewards, they could do so right now, they would just need to stop operations for 28 days and they can sell all surplus without any need for this GIP. They would still hit market before delegators, since they would be the ones to unstake and withdraw first…

I haven’t seen a huge amount of indexers doing this, as it’s a terrible business decision since you are forfeiting 99.9% of your long term money for a 0.1% quick cash grab (or even less than 0.1%), so this gives me a relatively educated guess on how the post GIP-0002 scenario might go. (Also, I don’t think a couple of bad indexers will be able to crash the market by dumping their rewards, and even if 100% of indexers would proceed to dump the rewards, it only accounts for a small fraction of the 24h trading volume that GRT has…)

6 Likes

As a delegator, I fully support implementing a 0.5%-1% token burn on withdrawals to seperate addresses by indexers. I am also for setting a percentage limit on the amount of tokens that can be withdrawn.

4 Likes

As a delegator I would be happy with a token burn on the way out for everyone.

4 Likes

…if that made it simpler & would get something passed.

3 Likes

As a delegator I am 100% for a token burn.

3 Likes