Should Rewards be subject to the 28 Day Unthawing Period?

Governance & GIPs
1

Here is a topic we need to discuss as a Community before moving forward.
“Should Rewards be subject to a 28 day unthawing period?”

Right now we are about to allow indexers to send rewards to a separate address and withdraw immediately. But delegators still have to wait 28 days to withdraw their rewards, right? Of course there is another thread discussing letting delegators send rewards to a separate address to allow them to withdraw immediately… but what about this.
Why not just make All rewards subject to the 28 day unthaw period?
Leave delegators as they are, and make the rewards for indexers, that they send to the new address, subject to the 28 unthaw period?

My opinion:
Yes, indexers should be able to withdraw to a separate address, but those rewards should still be subject to the 28 day unthawing period, just like delegators.

Otherwise what is the point of having an unthawing period at all???
Delegators still have to wait 28 days for their rewards to unthaw, so then so should indexers.

It’s fair.

Yes, fix the issue of indexers not being able to withdraw without unstaking, of course.
Withdrawing to a separate address fixes this, and helps with taxes.
But those rewards should still be subject to the 28 day unthawing period at the new address they are withdrawn to.

That’s my opinion.
But it’s something we should definitely be talking about as a community.
And something we should probably put to a vote.
Because, as it is, allowing Indexers to withdraw rewards immediately, and leaving delegators to have to wait 28 days to withdraw rewards is absolutely completely unfair.
Plain and simple.

4 Likes
2

I think this is best as well. Indexers should have the right to draw an active income in order to pay their bills! This is something I can’t imagine anyone to really have an issue with.

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.

No one should really want network players to be incentivized to hop on and off network in order to chase the markets- as this would be a wildly destabilizing! Thawing periods ought to be required for any removal of GRT from the network, regardless of network role.

3 Likes
3

Any party should be able to direct their rewards to a separate address rather than being auto-opted into compounding, and any use of that function should be subject to the same unbonding/immediate liquidity process, irrespective of network role. I come to this conclusion mainly from my experience on layer one networks but also a general desire for a reasonable level of equality within the network.

On Polkadot everyone is subject to a 28 day unbonding from their bonded stash but have the choice to compound rewards into the stash or have rewards be liquid as they are earned. Similarly, on Cosmos rewards can be compounded or made available immediately.

I find it hard to understand why the dynamic should not be the same here unless there is a legitimate power dynamic that must be upheld that I do not see, or some second order issue I am missing due to Graph not being a base layer protocol. In my opinion “Indexers sacrifice more to the network, have greater costs etc” and arguments along that line are contrary to maintaining equality within the reward system. These are not reasons for one network role to have access to their rewards before another does.

It seems to me that we are going to have a lot of these conversations over time where one side believes that there should be a reasonable level of equality between all network participants and the other believes it’s more nuanced than that.

6 Likes
4

I completely agree with all of this and don’t think I can state it any better.

5

Thank you for this.

So then the choices on offer would be:
All funds removed from the network, be them by indexer or delegator, should remain subject to the 28 day thaw, and we simply fix the issue of the 1 year lock wallet for indexer rewards and do nothing else, for now

OR

Both Indexers and Delegators should be able to remove rewards immediately

Now, I tend to believe that while The Stated Mission of The Graph Foundation has nothing to do with encouraging the price of GRT to rise (and there are good reasons for this) if we are all holders of GRT engaging in self-governance it would be wise to keep the price effects of the actions we take in mind. To that end- if accrued rewards can be used to “time the market” so easily, this will could have a dampening effect on the price of GRT. With a 28 day unthaw you can still attempt to time the market… once you’ve waited at least 28 days. 28 days is not a very long time for anyone who plans to be with the project for multiple years.

Why should a struggling small indexer care about price dampening? Because, an indexer with a $2m stake will accrue much less in rewards than an indexer with a $140m stake. A small indexer who is unsure of whether or not they will be able to stay afloat should be quite interested in maintaining a high price of GRT, as they may need to cash that stake out sooner than others. And if the whole point of indexers drawing rewards more actively is to help them pay their bills (which I support!) then the price of GRT being higher will mean these indexers can pay more bills on less GRT. Likewise, the largest indexers have shown the most willingness/ability to accumulate large amounts of GRT. We should be careful not to make it easier for them to also suppress the price of GRT in the short term if they still have a mind to keep accumulating more.

So- any proposal to eliminate 28 day thaws for indexers that does not also eliminate 28 day thaws for delegators is inherently unequitable. And removing the 28 day thaw for indexers may have ramifications that should worry small indexers and delegators alike (in the interest of brevity I limited myself to one potential issue. I could think of some more, if anyone needs me to).

Additionally- it seems wrong-headed to suggest that indexers need to be able to withdraw immediately or that a 28 day thaw adds un unreasonable burden. For anyone who is not familiar with “net 30 billing” it is incredibly common practice amongst real-world service providers, and it works. You simply need to be able to manage a budget that is based on revenue projections that are always a month out. In this scenario, since all economic activity gets filtered through GRT (which obviously wont pay your electric bill) you should think of it as net 30 selling.

All of this leads me to think we might not want to eliminate any of the 28 day thaws just yet, and need to come up with stronger justifications the next time we propose to do so.

I also will conclude with this:
The parties who wish to enact the most fundamental changes to the system have the burden of proof, not those who are seeking to maintain what they view as virtuous components of it.
We should all take a step back and acknowledge that we are walking into a brand new, but thoroughly designed ecosystem here, and remember also that it was designed to service queries. If we make any changes to the dynamics before queries start being served, we need to be very careful to fully account for all knock-on effects that may arise due to those changes, on top of the already stated imperative of balancing all stakeholder interests equitably.

6

I posted about this in a different thread and agree.

By the way, I keep seeing many of the same concepts come up between different proposals. I understand the desire (and perhaps even need) to separate out each proposal, but it seems to me that we can sometimes combine them for consideration.

I agree with this in principle, but perhaps not entirely in practice; a proposal or a change that benefits the network probably shouldn’t rely on its proponent’s ability to persuade or offer proof. But if something truly is a beneficial change, someone will be able to offer persuasive justification for making the change, so it’s probably not a practical issue.

7

Yes, perhaps I worded that poorly. What I really mean to say is that proposals for public review should include some robust economic and behavioral modelling, especially when their scope is to change incentive structures, otherwise it’s a bit of a dice roll. You can’t really say what is going to benefit the network if you can’t offer a whole lot of justification for how you know if will work as you intend it to.

Perhaps we want to start separating “soft measures” ie: changing what information is displayed and where on the network page into a fast-trackable category and silo fundamental, protocol level changes into a “rigorous review required” bucket.

8

It is completely unnecessary to add a thaw period for indexer rewards, since it does not introduce potential exploits in the protocol economics. Please read Ariel’s nice explanation here

If you want to get indexers support, I suggest rallying behind @Derkhersh’s proposal

Both Indexers and Delegators should be able to remove rewards immediately

9

Well, anyone with a shield by their name kind of has to say that nothing was designed to restrict liquidity, right, because that is explicitly not the stated goal of The Graph Foundation or Edge and Node, and there are legal reasons they should remain circumspect on anything that touches price protection.

As holders of GRT engaging in self governance, though, we CAN view the restriction of liquidity as something that we would like to maintain. I, for one, think it has a lot of benefit for literally everyone who holds a lot of GRT.

Unintended consequences can be beneficial just as often as they are detrimental.

10

Can you please explain in plain English? I dont understand what you’re trying to say

11

There are several indexers who have shown support for a thawing period for indexer rewards.
It is not one sided.
At this point, with support on both sides, it should go to a vote.

13

I think the thawing for delegators has a benefit to the protocol that I’m not sure if it applies equally to indexers.

As I have understood the incentive system, the idea is that customers send queries to an anonymous network of indexers, who can be trusted despite the permissionless, decentralized nature of the network due to the slashable stake they put up as collateral. Delegators contribute to this system of trust by adding to an indexer’s stake, thus making that indexer look more trustworthy to customers, thereby attracting more traffic and in return the indexer would share some of the profit from that extra traffic with the delegator.

For the delegator role to work here, it is vital that delegating with an indexer actually does give customers added reason to trust an indexer with their traffic. The customer must be able to trust that delegators have sufficient incentive to research what indexers they delegate with, and that the delegator interests in the indexers performance overlaps well enough with the customer’s, for delegator stake to give increased customer confidence in an indexer so the equation works out.

Without delegator slashing, there must still be some “punishment” for picking a bad indexer - and I’m mainly talking about “bad” from the protocol perspective here, as in not delivering reliable results to customers. So the mechanism, as far as I can see, is that an indexer that doesn’t give reliable results will be punished with bad rewards and query fees (in addition to potentially being slashed) which in turn punishes their delegators with poor shares of said fees and rewards for up to 28 days (plus the 0.5% burn) which gives delegators their incentive to research their indexer and make their delegated stake meaningful to the customer.

The downside to this mechanism it that it also burns delegators who get stuck for 28 days with an indexer who performs well enough from a protocol perspective but decides to “rugpull” their delegators by setting their cuts to 100% or something unreasonable from a delegator perspective. The protocol should see no incentive (afaics) to punish delegators for selecting such an indexer, so presumably this is a side effect from the mechanism described above. Thus my opinion is that if some solution could be thought of that solved the downside without also removing the upside it would be great, but any suggestion would have to take into account how it would affect the meaningfulness of delegator stake to the customers.

If delegator stake becomes meaningless to the customers, indexers won’t want to compete for delegations and being a delegator will become worthless.

14

Well- I would argue that indexers who rug pull are unscrupulous, and so there’s gonna be a lot of overlap on the Venn-Diagram with indexers who maliciously interfere with good and accurate query performance.

Putting that aside- I don’t think the customer truly cares, nor should they, about delegators. Instead, it is the indexers who should care about delegators. If we accept that it is fair and just for the indexers with the most stake at play to service the most queries, then we acknowledge what delegators are- an opportunity for indexers to leverage their trust with network participants into a sort of loan- an opportunity for them to increase their controlled-stake without drawing on their own existing capital to do so. In return- they pay delegators interest- again- much like a loan.

Unless we are proposing changing that fundamental dynamic of “total stake = traffic potential” then indexers would be quite foolish to not compete for delegators. An indexer with a delegation : selfstaked ratio of 10 to 1 could take a 10% cut from their delegators and double their earning potential! Now- why would you definitely NOT want to change that dynamic?

Because the more than delegators are incentivized to lockup their funds, and the more that indexers stake the less GRT there is free floating on exchanges. Once there is actual customer demand for GRT because the network is up and running, I think all network participants should see VERY CLEAR benefits (in terms of price of GRT) from this lack of freely available supply.

Without that incentive- you need some serious upticks in indexer self staking rates or else 10b tokens is probably WAY too many to support much further price appreciation.

Therefore- the simplest and most elegant solution is that ALL funds originating from network participation should be freely available for withdrawal but should be required to go through some kind of thaw. This should include indexer stake, indexer rewards, delegator stake, and delegator rewards.

Maybe 28 days isn’t the perfect number- but that’s the only debate I really feel is worth having here.

15

To the extent that’s true, delegations confer even greater trustworthiness to the customers, of course.

I don’t know how this network will turn out to run long term, so it’s hard to speculate on exactly how customer preference will form. When there is a gateway with a secret formula routing queries, how will it weigh delegator stake? When/if customers are able to use their own agents and heuristics for picking service providers, and they can pick between two indexers with the same total stake but one has a larger portion of it being delegations, which one will they tend to prefer? On one hand, delegator stake can’t be slashed, and if it’s seen as mostly parasitic (by the delegators on the indexer) they should pick the indexer with more slashable stake. But on the other hand, if delegations are seen as representing market confidence in the indexer, that could count for more than slashability, and the indexer with more delegations might win out. My big assumption is that the tokenomics are meant to be geared towards this second case.
But whatever weight a free market ends up valuing delegator stake at relative to indexer stake, as far as I can see that weight can only be above zero if customers have a reason to believe that delegation can be interpreted as representative of market trust that the indexer can do a good job serving queries.

When it comes to possible effects on price points by reducing available float, I’m not sure if that might be the kind of price talk we’re supposed to refrain from in these forums. At any rate I am not the right person to make useful points on that topic.

16

I mean- I think you’re overrating customer choice. The customer is gonna “pick” whoever is servicing the subgraphs they’re interested in at the best price. It’s like- do you pick which Ethereum node processes your Ethereum transactions? Not really! You just set your gas limits and let the platform do that for you.

Not all indexers are going to be servicing all the subgraphs. The number of subgraphs is, potentially, infinite. The number of indexers is not. For the very niche, less used data sets there’s likely to be only a handful of indexers to choose from at all. Customer choice isn’t really a big piece of the puzzle. Customer satisfaction is but that’s a different discussion.

We, as holders of GRT and participants in the ecosystem, are engaging in self governance. It would be preposterous for us to NOT consider price. Those sort of no-price talk rules are intended for social media platforms like reddit, and exist to serve a very different purpose, as far as I know. If we can’t consider price of GRT while making decisions that impact the financial incentives of the protocol, then what are we doing here? We’re all here to build this network, sure, but the financial incentives inherent in doing so cannot be kept in a vacuum. The price implications for GRT are a central piece of the financial incentives at play. We can consider them explicitly.

The explicitly not-for-profit Graph Foundation may not be advised to publicly address such concerns, but we absolutely ought to keep them front-of-mind when deciding what we put in front of it.

17

I don’t mean end users, I mean dApp writers.

18

I get that. We’re talking about the same people. Again- basically an infinite amount of potential data sets. There’s only so many indexers. Indexers won’t each be supporting every single subgraph. Indexers will choose which subgraphs they want to support.

The big choice for customers is less about which indexer to choose and much more what data to query to accomplish their goals. Beyond that, the way that query traffic gets routed to indexers renders indexer specific customer choice pretty moot.

Customers can choose, first, to use The Graph at all, and, second, which subgraphs to query. Customers aren’t really choosing which indexer services those queries though.

19

Great discussion and one that naturally arises when both protocol stake,inflation as well as protocol fees are paid in the same native token.

I come from the Livepeer ecosystem where protocol fees are in a different currency than staking/inflation. This gives node operators the option whether they want add their earned fees to their stake (would have to swap ETH for LPT on uniswap) or whether they want to withdraw them.

The earned fees are thus not instantly subject to an unthawing period. The flip side of the coin is that your protocol fees start to automatically compound with the inflation rate which could also be nice.
But this seems a personal choice and therefore should, in my opinion, be optional.

While of course for the Graph, a separate token for protocol fees would be too drastic of a change there is the alternative of doing something such as.

  1. Protocol fees are added to a pending fee pool per indexer automatically when being received
  2. In the fee pool the commission is assigned to the indexer, the remainder assigned to its delegator set
  3. User can claim the available funds anytime and withdraw to wallet , or user can execute an ‘addToStake’ function to add the funds to its stake.

That being said maybe there is a non-technical middleground possible as well, whereby managing your operational costs, protocol income and unthawing period becomes more of an operational process. In traditional business you often get your invoices paid only after 30 or 60 days, so you have to bridge those gaps as well. Perhaps node operators are still in the process of figuring out their best operational practices and any technical decision should not be taken too lightly.

1 Like
20

Oh ok, cool. I think dApp writers might well be interested in controlling such parameters, but I guess time will tell.