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.
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.
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.
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
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.
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.
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.
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.
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.
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.
@ari
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.
