GIP-0039: Curation v1.x

[howard]

---

GIP: 0039
Title: Curation v1.x
Authors: Howard Heaton, Anirudh Patel
Created: 2022-09-29
Updated: 2022-09-29
Stage: Draft
Category: Protocol Economics

---

GIP-0039: Curation v1.x

Disclaimer: As indicated by the version name in the title, this GIP suggests a patch, not a long-term curation mechanism. Also, the proposed change is only for subgraphs deployed on L2.

Abstract

The Graph community has interest in moving many operations from Ethereum to Arbitrum One Layer 2 blockchain (L2). To aid developers in this transition, this GIP requests flattening curation bonding curves (i.e. making their slopes equal zero). This will result in a curation pool for each subgraph rather than a bonding curve, whereby curators will be rewarded exclusively by query fees. In particular, no curator will be able to realize gains at the expense of other curators’ signal. This change will apply only to subgraphs deployed on L2. This proposal serves as a curation patch, setting the stage for future updates to benefit developers and indexers.

Motivation

This GIP aims to improve the experience of subgraph and dapp developers (hereafter called “developers”). Developers want to ensure specific subgraphs are indexed, and they can do this by also acting as curators. That is, if a developer puts signal on a subgraph they create, then the signal guarantees indexers can obtain indexing rewards by indexing that subgraph (i.e. signal incentivizes indexers to index the subgraph). However, bonding curves make many developers find the signaling experience both expensive and unintuitive. For example, a common inquiry asks how much GRT a developer needs to signal on a subgraph to ensure their data will be served, the answer to which is often elusive with bonding curves.

A subgraph will typically be indexed only if indexers can profit from it. Today, indexing rewards far exceed collected query fees, which causes signal to strongly correlate with which subgraphs get indexed. In other words, more signal on a subgraph (roughly) means more indexers on that subgraph. Thus, signal presently provides a clear way for developers to get the data they care about indexed. Our patch provides a short-term solution for enabling developers to get indexed in a straightforward and principal-protected way.

Proposal Specification

The mechanism works as follows. Suppose a curator makes deposit d>0 into the curation pool (a.k.a. reserves) for a subgraph while there is currently signal s\geq 0, resulting ^\star in signal 0.99\cdot d+s. This new curator is minted shares equaling their proportion 0.99\cdot d/(0.99\cdot d+s) of the subgraph’s signal. That is, if there are currently \mathcal{S} shares, then the new curator will be minted \mathcal{S}\cdot 0.99\cdot d/(0.99\cdot d+s) new shares. So, each curator is entitled to the same proportion of reserves as their proportion of shares. This implies curators can also burn their shares to retrieve GRT from curation reserves in proportion to the shares burned. All incoming query fees to curation are added to the reserves held by the subgraph’s smart contract. For example, if there is 900 GRT of signal and a new curator adds ^{\star\star} 101.01 GRT, then the new curator will be entitled to about 10% of the incoming query fees (until a next time curator mints/burns shares).

{^\star} The reason 0.99\cdot d is listed rather than simply d is curators pay an upfront 1% “curation tax” to mint shares. See this prior GIP for more discussion.

^{\star\star} The number in this example is 101.01\approx 101.\overline{01} = \frac{100}{99}\cdot 100, which is the exact amount of GRT to obtain 10% of curation shares.

Backwards Compatibility

This upgrade will occur exclusively to subgraphs deployed on L2. For this reason, no backward compatibility issues are expected. Independently from this proposal, we anticipate some “run on the bank” phenomena when subgraphs migrate from Ethereum to L2.

Risks and Security Considerations

Note: Most of the considerations below concern long-term effects of implementing this GIP. These are included for completeness and as a record for considerations in the upcoming design of Curation v2.

1. Limited incentive to be early. Since curators are rewarded solely from query fees and are not incentivized to curate prior to the arrival of query fees, new curators can mint shares immediately prior to the arrival of query fees, thereby “stealing” the majority of query fees from early curators. These late curators can immediately burn their shares to retrieve their signal and query fee profits, and then repeat this behavior on another subgraph.
2. Increasingly expensive to get indexed. If implemented long-term, we expect this proposal to result in a “race-to-the-top”. Consider this example: Subgraph A has 1 GRT signal and is currently indexed by all indexers. Next subgraph B is created and receives 2 GRT of signal. As a result, A might no longer is indexed by all indexers as its relative amount of signal decreased from 100% to 33%, decreasing its quality of service (QoS). If the reduction in QoS is unacceptable, developers who rely on A must increase the signal on A, e.g. to be >2 GRT. As a result of this action, developers who rely on B having a certain QoS may need to increase the signal on B, and so on. This process continually increases the cost to get indexed via curation signal. Although this is a toy example, it illustrates a possible phenomenon that yields increasing barriers to entry.
3. Increasing centralization. If subgraphs have different amounts of query fees collected, then the relative amount of signal on the subgraph with the most query fees will increase over time, assuming at least one curator on that subgraph never burns shares. This implies, as time passes, the vast majority of indexing rewards will be distributed to the one subgraph with the most query fees.
4. Hinder adoption of queries. The proposed upgrade protects the principal of invested signal, which enables curators to, without penalty, put large signal on subgraphs without queries (e.g. “broken” subgraphs). Also, most indexers presently chase indexing rewards rather than seek query fees (as indexing rewards are currently more profitable). These two facts enable this curation upgrade to draw indexers away from indexing subgraphs that would entail many queries, i.e. hinder the generation of query fees in The Graph.
5. Limited value if query fees outpace indexing rewards. Most indexers follow rewards (not necessarily signal). If query fee profits greatly exceed indexing reward profits, then indexers may chase query fees rather than indexing rewards. If this happens, it may become increasingly difficult for developers to get subgraphs indexed via curation signal. In that case, this proposal may have limited value to both developers and indexers.

Rationale

The curation patch must satisfy the following constraints:

• Simple to describe
• Simple to implement
• No ability for curators to take each other’s investment

These constraints arise from the need to both efficiently to deploy on L2 and improve developer experiences. Regarding the first constraint, this proposal is straighforward as each curator obtains curation shares in proportion to their GRT investment and is rewarded in proportion to their curation shares (i.e. no “rug pulling”). Implementation will require a single parameter change (i.e. possibly a “no code” update). As mentioned, this change also removes the potential for curators to exploit one another monetarily by preventing front-running and profit scalping attacks. Curators can still dilute one another, resulting in less rewards than expected; however, they can recover their investment (minus gas fees and curation tax). Lastly, despite the notable concerns listed above, we believe our proposed design is more compatible with potential long term solutions than bonding curves, making this an apt upgrade.

Considered Alternatives

Late Fees. It is possible to transfer a portion of newly added signal (i.e. GRT) to the holdings of existing curation shareholders. This one-time late fee (e.g. 2% of investment) can be known prior to providing signal, preventing the unknown downside exposure curators often experience today. This alternative gives explicit downside protection and rewards early curators.

Delayed Rewards. Another option considered is to delay distribution of curation rewards. Here curators provide signal, but do not start accumulating rewards for their signal until after a fixed amount of time passes. This delay prevents early curators from having their rewards “stolen” from late curators that hop in after query fees become substantial for a subgraph. This incentivizes early curation, but may require multiple transactions, complicating users’ experience.

Continuous Issuance. The third alternative is to continually issue new curation shares. Here curators place deposits and are issued shares in proportion to their deposited GRT (relative to other deposits), and rewards are distributed in proportion to shares held. This scheme is i) cognitively difficult to reason about, ii) potentially difficult to implement, and iii) potentially expensive with respect to gas costs (if tractable). Ongoing investigations are stress testing variations of this idea for future consideration in Curation v2.

Principal-Protected Bonding Curves. A prior proposal suggests keeping bonding curves, but also adding bookkeeping so that each curator’s investment is principal-protected. This is yet another scheme for incentivizing early curation. However, the skewed in perpetuity rewards from query fees are undesirable (e.g. a curator that is 1 minute earlier than another curator may pay the same to signal yet obtain notably larger query fee rewards forever).

Potential Future Work

Upcoming curation upgrades will strive to better serve developers’ ability to clearly and accurately communicate value to indexers so that valuable subgraphs can be efficiently indexed.

Copyright Waiver

Copyright and related rights waived via CC0.

[cryptovestor]

Thank you for you work on this proposal, @howard

I think it’s very healthy that we are stepping back, looking at the state of play with curation and accepting that there are significant improvement to be made and negative behaviors that need to be mitigated (rug pulling) before we move on to tackling the challenges of building a successful end to end curation system. There are tradeoffs, complexities but the foundation needs to be solid before we move on to more complex upgrades, so I am generally in support of this proposal.

A question/query I had regarding the allocation closure front-running that was brought up by a participant on the research call - if Indexers shorten their allocation lifecycle, which they will given that shorter allocations means a more agile indexer business, does that have an impact, positive or negative, on the potential allocation closure front running behavior?

Additionally, given the exceptionally small size of the curation pool of GRT today (compared to the pool on the delegation side), do we have any concerns that someone with a very large amount of liquid GRT could play this front-running game out to an extreme end, essentially breaking the role for all other curators and taking nearly all of the curators fee cut?

[Pablo]

Great proposal @howard, I think this’d be a great first step in the right direction.

One question:

@howard

we anticipate some “run on the bank” phenomena when subgraphs migrate from Ethereum to L2

Could you expand a bit more on how you think we should handle subgraphs migrating from L1 to L2, and how this could cause a run on the bank? How would we translate from each curator’s signal in L1 to their equivalent in L2 when the subgraph is migrated?

[SamH5]

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.

[DataNexus]

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.

[DataNexus]

@cryptovestor

A question/query I had regarding the allocation closure front-running that was brought up by a participant on the research call - if Indexers shorten their allocation lifecycle, which they will given that shorter allocations means a more agile indexer business, does that have an impact, positive or negative, on the potential allocation closure front running behavior?

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.

[ari]

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

[howard]

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.

[howard]

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?

[cryptovestor]

@howard

going to curation are less than 1% of current signal (i.e. f < 0.01s f<0.01sf < 0.01s ), then the attack is not profitable for any amoun

Very helpful, thank you Howard!

[That3Percent]

@howard

For example, a common inquiry asks how much GRT a developer needs to signal on a subgraph to ensure their data will be served, the answer to which is often elusive with bonding curves.

Would the answer be any less elusive without bonding curves?

@howard

race-to-the-top”

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.

@howard

enables curators to, without penalty, put large signal on subgraphs without queries

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.

[toxf1]

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

[howard]

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.

[howard]

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?

[toxf1]

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.

[Pablo]

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]

Hi all, this GIP has now been deployed! See the post on GIP-0040 for details.

[PaulieB]

@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

[Pablo]

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

[PaulieB]

@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?