Well its very simple.
The total value of curator share in grt is way way below the total amount of grt used to signal a subgraph.
They are planning to pull the rug and turn all impermanent loss into realised loss, the first to notice win and the last one is left with nothing.
Very happy to have some attention back in the curation system.
A few curators and I have talked at pretty great lengths for flattening the bonding curve. I’m definitely in favor of this in the short term as the incentive structure for ‘market curators’ is reviewed. This will allow developers and altruistic curators to maintain subgraph support while the next model of curation is put together.
This is also easy to implement with existing params which is why I would vote for flattening the curve versus some of the other considered alternatives mentioned.
The 1% signal tax would make this difficult to do at a profit. The front runner would need to ensure that their portion of 10% of the query fees outweigh the 1% tax. Since the front runner does not know ahead of time the query fees the indexer is going to collect, this becomes fairly risky.
@howard this is a very well-written proposal, good to see improvements in the direction of simplifying the UX for developers and reducing the mental friction when interacting with the economics. The Arbitrum deployment of the network is definitely a good opportunity to try this out.
Thank you for your comments. You raise great questions. First, I’ll second DataNexus in noting the 1% tax will make it difficult to profitably front-run, particularly if the query fees are collected more frequently than today. If query fees are substantial relative to signal, the story changes; however, my intuition is this attack is unlikely to overwhelm curation before we are able to deploy a longer-term solution. Let me explain.
Suppose a subgraph has signal s and fees f are about to be deposited into the curation pool. If a front-running curator signals x>0, then the net gain/loss they get by front-running is
(\text{gain})=(\text{query fee collected})-(\text{tax})= \dfrac{f\cdot x}{s+x} - \dfrac{x}{100}.
This implies an attack is only profitable (i.e gain is positive) provided 100f - s > x. Consequently, if the fees going to curation are less than 1% of current signal (i.e. f < 0.01s), then the attack is not profitable for any amount of signal x>0 by a front-running curator. For example, that would mean if query fees for a subgraph in a single window amount to 1,000 GRT (100 GRT of which go to curators), then having 10,000 GRT of signal would make the attack unprofitable. Lastly, since this is independent of the size of the curator, it also rules out the case of a whale ruining curation for everyone else. I hope that helps. Let me know if there’s anything here I can clarify further.
It would be helpful if someone could provide recent aggregate numbers so we can estimate whether the “no profit condition” (i.e. total query fees on subgraph per distribution to curators < 10% of subgraph signal) currently holds in practice.
Thanks @Pablo , though I can only take a small slice of the credit (e.g. much is due to Anirudh P, Sam G, Brandon K, and others protocol economics working group).
Continuing our offline conversation with @ari , it seems that we may be able to help subgraph owners broadcast when they plan to migrate. This could be viewed as encouraging runs on the bank since curators will explicitly know they can get more GRT back by burning shares today than holding through the migration. (Note some folks will immediately experience losses with the “flattening” on L2, and so the prior broadcast may help them mitigate some of their losses by burning shares on L1.) I can see reasonable arguments against this approach, but I ultimately favor transparency. Overall, I and others believe the matter is not black and white and that it will be much more manageable for our community to go through this painful transition now while total curation signal is relatively small rather than later when curation signal could be 100X larger.
To summarize the process of actions, I see curators having their same number of shares on L1 immediately before migration as they do on L2 immediately after migration. The total GRT signaled in the reserves will also stay constant during migration. However, the mint and burn rules will immediately change. Is this consistent with what you expect from the smart contracts?
Very helpful, thank you Howard!
Would the answer be any less elusive without bonding curves?
The example seems to be relevant before and after the GIP. Also, the example indicates an undersupply of indexers, not a difficulty for the mechanism to provision the supply.
Is the opportunity cost of inefficiently allocated capital a penalty? Also, I’m not sure that the penalty of getting rugpulled by previous curators has any relation to the query/signal ratio on the subgraph so I’m not sure this is a regression.
what do you think about leaving the bonding curve for the query fees?
that way curators would receive 99% of tokens that they’ve signaled
but at the same time there is an incentive for them to hold their position
because if they’ll try to switch between subgraphs at the times when indexers close their allocations (closer to 28th epoch), they would loose their better spot at the bottom of the curve
and when they come back, they may find themselves a lot higher at the curve and they receive less QF rewards
Great questions!
Without bonding curves, the answer could be less elusive. For example, one can remove consideration of downside exposure (e.g. from rugpulling) from the computation of how much signal is needed. Additionally, looking beyond Curation v1.x, if signal were somehow tied to a tangible cost (e.g. the cost to index a subgraph), then it may also become more tractable.
Indeed, the rate-to-the-top remains relevant. In general, I think indexer resources are limited (meaning that not all subgraphs can be indexed, at least long-term).
I have heard argument to say opportunity cost is a penalty, which I acknowledge. However, my concern with including opportunity cost in the consideration of incentives is that it fails to account for both how inefficient resource allocations are in The Graph and what to do if a participant stops participating (e.g. loses access to their wallet or dies). Perhaps, that is a long-winded way of saying that some participants seem to have such a low time preference that their opportunity costs are negligible.
Hi Anton, thanks for your comments. I’m not sure I understand your proposed idea. How is what you share different from what exists today?
Now the query fees are distributed by adding them to the reserve ratio and changing the slope of the bonding curve.
That way all curators benefit from QF the same way and it does not matter whether you were curating the subgraph for several months and attracted indexers all this time, or you’re just a newcomer that arrived for the QF distribution and going to leave right after you’d get some.
I just want to add to your proposal of flattening the bonding curve for the shares price (basically making it like a pie-chart), that would allow curators to perform “grab QF and run” tactics freely, some incentive to stay and hold.
Thus, by having greater amount of QF.
I agree, that current curation market is too stable and we are left with the fact that signals do not correlate with QF.
The reasons for this stability are bonding curve & relatively high gas costs.
By moving to Arbitrum and integrating this flat curve (or pie-chart, since it is no longer a curve) we will eliminate both of the causes for stability.
And I’m a bit afraid of possible chaos with the signals that is going to be due to the fact that curators would not have any incentive to stay and hold.
Indexers, must likely, would also follow the signals by reacting to changes, as the primary source of income for indexers is indexing rewards and the gas prices would be low, so they would do reallocations every epoch.
All these would lead to some tactics that indexers may use.
For example, an indexer allocates to the subgraph with the most signals.
But the curator was in fact another indexer that wanted his rival to stick with the wrong subgraph. This curator-indexer can now freely sell its curation shares (as there is no risk, only 1% loss), curate to another subgraph and allocate there.
And the first victim-indexer in these schema is now stuck with the initial 0-signal subgraph until the end of epoch.
Now such schemas are risky and relatively expensive.
But there were cases before when we’ve seen indexers manipulating curation market for their rewards.
And flattening the bonding curve without any incentive for curators to stay is potentially threatening.
As mentioned in the thread for GIP-0031, this has been voted by the Council on Snapshot; the implementation for the L2 bridge has passed all the audit rounds and we’re almost done with testing. So we’re now working to get the L2 protocol, that includes the change proposed in this GIP, deployed soon.
Worth noting that this initial L2 deployment won’t include indexer rewards yet, and that Howard and team are still working on a Curation v2.0 proposal that would solve the issues that persist in this v1.x.
@Pablo Is there any way you can possibly explain how further how this would affect current curators on L1? Using Polkabridge for example since only 2 curators. 1 self signal 52.34 shares and one that has 100k with 265.01 shares. If this project migrates to L2 - does the shares stay the same? If someone comes along and puts 100k GRT signal after migration - do they receive 52.34 shares? Trying to understand dynamics of the flattened bonding curve when migrating. Or would the existing deployed subgraphs keep the bonding curves? Sorry its a bit confusing when you take into account the migration piece as a curator
@PaulieB yeah the flattening makes the curation migration a bit confusing.
In the proposed approach, when the subgraph owner migrates the subgraph, the subgraph on L1 becomes disabled just like if the owner had deprecated it. From that moment, all the signal from that subgraph is burned and converted into GRT, and each curator is entitled to a portion of that GRT pool based on the shares that they own.
If the curator chooses to withdraw, they get that portion just like they currently would in a deprecated subgraph.
If they instead choose to migrate, what is sent to L2 is the GRT, not signal. Once the GRT is received in L2, it will be used in the L2GNS to mint new signal on the migrated subgraph. So the flat curve will then be used to convert those GRT into shares, at a constant rate between GRT and shares because the curve is flat.
@Pablo sorry for a follow up but to be clear. Just as example, If you signal 5k and on L1 due to bonding curve you have 10k value when migrated over from what you say the signal will be converted to GRT as 10k GRT and if choose to apply to newly minted L2 subgraph. Then you would then apply the 10k GRT using the flat bonding curve mechanism?
Yes, that’s correct, but note that the value of the shares might not match what currently appears as “Shares Value” in the Explorer UI. That value uses the current bonding curve price of shares, which would vary as individual curators mint or burn signal. Whereas the deprecation makes the full amount of signal be converted to GRT at once.
So the resulting value for each curator would be:
curator_GRT = total_curation_GRT * (curator_shares / total_curation_shares)
This is equivalent to what each curator can withdraw if a subgraph is deprecated.
This is what would be sent to L2 and used to mint signal with the flat curve there.
I know a complicated answer, but curious if keeping the bonding curve and migrating subgraphs from V1 to V2 was an option? Possibly utilizing flat bonding curve only on newly published subgraphs in the V2 environment. Depreciating the subgraphs prior to move is detrimental to the value and also not rewarding those who helped bootstrap curation. I know many parts to consider when making a decision and hard to please all parties.
It’s a fair question @PaulieB. To be clear, the GIP I posted (GIP-0046) for the migration helpers is still at Draft status- if there are any competing proposals there’s still time to present them and eventually the Council will choose a path forward.
That being said, I think keeping the L1 bonding curve for migrated subgraphs wouldn’t really work: subgraph owners can always deprecate the subgraph manually (they’ve always been able to do that) and create a new one with the new curve. And if flat curves are healthier and overall better, as I expect they would be, they have all the incentive to do it.
(Besides that, keeping two bonding curves in parallel will make the code more complex, make things harder to understand for all participants, and blocks future updates to curation that may rely on a flat curve to have an upgrade path)
imo deprecating a subgraph still rewards early curators: they will have more shares for every GRT they deposited. It just doesn’t reward being the first to exit after deprecation and makes it fairer for everyone to withdraw at their own pace.