Subgraph Showroom

Research & Development Protocol Economics
42

Assuming the showroom will be a pooled buy-in into the curation bonding curve, as initially presented in post #1, then this is not true.

As soon as “regular” curation launches, the curation shares will be subject to the bonding curve price variations. If other curators that participated in the showroom sell their curation shares, the GRT valuation of the remaining shares will decrease. There is no “max loss” for curators participating in the showroom. (5% max loss only holds if no curator sells their shares)

1 Like
43

Playing this out in an example:

If I currently signal 50,000 GRT on a subgraph with 0 signal, I will get roughtly 220 shares for an average share price of 227 GRT. If I then sell 110 of my shares then total signal goes down to 25,000 GRT.

If someone newly wants to mint 10,000 (bringing the total up to 35,000) they would be able to do so but the share price would be higher than 227 (avg price of their signal on the bonding curve).

If I sold 200 of my 220 shares the total signal would go down to 4,545 GRT at which point someone could signal 5,000 GRT for an avg price per share less than 227. So it seems that your risk is 5% tax, and if more than 50% of shares are burned before someone enters in the 2nd position your share value could go down.

Honestly I do not think this is a bad thing. Ceiling would help protect this situation, but the risk is much lower than the negative affects we’re currently experiencing.

44

Any amount of burned curation shares will decrease the GRT valuation of the remaining shares.

45

I took a second look at the showroom:

The first showroom curators to sell their curation shares would in fact do so at a profit. The showroom has the potential to drastically increase the issue of frontrunning bots;

  • Bots would no longer race to be the first to curate,

  • Bots would instead race to unsignal after participating in the showroom - at a massive profit. They would also be able to hold off on participating in a showroom unless they see other curators participate as well.


Math:
(Using similar numbers to the example found in the docs). For simplicity I’m not counting curation tax. Curator | Graph Docs

  • Two curators commit 240 000 GRT each to the showroom. (Total 480 000GRT) This would mint 4000 shares at an average share price of 120 GRT

  • Per the suggested implementation, both curators get 2000 shares

  • Since the bonding curve still is in place, the first curator to burn their 2000 shares would receive 360 000 GRT. The remaining 2000 shares would be valued at 120 000 GRT.

2 Likes
46

After looking at it deeper with @Slimchance , I was wrong with some assumptions (based on the current setup of the bonding curve). It would take a larger overhaul than just adding the showroom to achieve the desired effect as Slimchance points out just above. Would be curious to hear more input from E&N team, especially those who were part of designing/coding parts relevant to the curation curve.

2 Likes
47

A lot of really interesting ideas shared here. I think the showroom idea has merit, and there is some similar prior art: the hatching period designed in BlockScience’s Augmented Bonding Curves.

In general, bonding curves can yield perverse incentives when initialized or decommissioned. For example, a similar dynamic could play out when a subgraph developer decides to deprecate a subgraph–that everyone will race for the exits leaving the slowest movers holding the check, despite the fact that most rational Curators would likely want to exit as soon as the subgraph developer announced the deprecation.

I would reiterate @ari’s emphasis on defining simple mechanism, both for gas efficiency, better user experience, and implementation speed.

For that reason, I would not be in favor of a complicated bidding process involving a ceiling. To @Josh-StreamingFast’s point a simpler approach is to simply have a flat bonding curve during the hatching phase.

@Slimchance’s point about back-running is a good one, and is similar to this attack discovered by Peter Zeitz at 0x with regards to the Curve AMM. In general, you have to be very carefully suddenly changing the curvature of a bonding curve.

This can be mitigated by changing the bonding curve gradually after the hatching period ends. For example, a flat bonding curve has a reserve ratio of 1, while the bonding curves currently used in the network have a reserve ratio of 1/2. By gradually shifting from the former reserve ratio to the latter, you dramatically reduce any advantage to being the first to exit after the hatching period concludes. (Gradually shifting the bonding curve shape can be computed relatively efficiently as well, doesn’t actually require triggering a state change on-chain).

@Josh-StreamingFast’s proposal to always have flat bonding curve is also an interesting one, as is @chris’s well-articulated response. We refer to this tradeoff, which seems fundamental to bonding curves, as a tradeoff in allocative efficiency vs. investment efficiency (inspired by the discussion in this paper by Glen Weyl).

It’s worth noting that the delegation market effectively uses flat bonding curves and we received the exact negative feedback that @chris comment hinted at: that early delegators were having their rewards diluted by later delegators that came in after it became clear what Indexers were valuable to delegate to.

I’ll also add that most Curators in The Graph today are actually interacting with nested bonding curves: there are bonding curves in the core protocol with a reserve ratio of 1/2, which are then wrapped by (flat) bonding curves in the Graph Name Service (GNS) that have a reserve ratio of 1. So when we talk about changing the curation mechanism, the design space includes modifying the curvature and dynamics at the core protocol as well as at the GNS.

For example, one option we had previously discussed for reasons I won’t dive into here, was to have the subgraph bonding curve in the core protocol be flat, while making the bonding curve in the GNS have a reserve ratio of 1/2, resulting in the same total curvature when signaling through the GNS, but w/ different dynamics at the core protocol level.

7 Likes
48

Overview

I went ahead and coded up a prototype based on the ideas discussed in this thread. In particular, I sketched out what a bonding curve would look like with:

  • An initialization phase during which anyone can enter and exit the curve at a uniform price.
  • An initialization exit phase during which the bonding curve reserve changes linearly from 1 (a flat curve) to its target reserve ratio, currently set in the protocol at 1/2.

Rationale

The primary rationale for this design, as articulated above, is to provide honest Curators ample time to evaluate a subgraph by removing the overwhelming incentive to be first into the curve when a subgraph is deployed, as exists in the protocol today.

A secondary benefit of this design, not discussed yet, is to lay the ground work for better N-1 support for subgraph developers. Currently, there is a strong incentive for a subgraph developer to migrate all their signal from a previous subgraph version to a new version in one go, so as to avoid being front-run on their own subgraph. The Graph Name Service (GNS) actually enforces such a one-step signal migration.

This is bad for subgraph developers, because the previous version may stop being indexed by Indexers as soon as it is unsignaled, but the new version may not have had time to sync w/ Indexers after deployment. If new subgraph deployments kept a flat curve for a longer period of time, then subgraph developers could incrementally migrate signal from a previous version to a new version, ensuring better continuity of Indexer availability during the upgrade, without getting front-run on their own subgraphs.

Protoype Walkthrough

Because the notebook is large (and only lightly commented), I recorded these quick loom videos:

  • Notebook Overview - Provides an overview of the structure of the notebook and how to run simulations.
  • Initialization Phase Prototype - Goes into the specifics of how the initialization phase prototype is set up and the scenario in the notebook that highlights the capabilities of the mechanism.

I highly encourage you to fork the notebook and add your own scenarios or present the data from the simulations in more approachable ways.

Open Questions

This design introduces some additional questions:

  • What is the ideal initialization phase duration?
  • Should we also introduce initialization phases at the GNS level or only the base protocol layer? (Recall that curation in The Graph today uses nested bonding curves)

Next Steps

Here are some suggested next steps for this proposal:

  • @ari has agreed to use the prototypes as a starting point for evaluating gas costs and feasibility of implementation on L1.
  • Describe this idea more formally in a GIP.

Asks

I’m going to be traveling starting next Wednesday, and may not have time to put together a more formal GIP before I’m offline. Given that this is an idea that came from the community, would be great if someone from the community felt compelled to write the GIP. Folks at The Foundation and other core devs can provide input on how to put together a good GIP.

13 Likes
49

Hey, to continue the discussion about this proposal.

A potential implementation would look like:

  • Having a function to calculate the effective reserve ratio based on when the first mint on a subgraph deployment happened. This function can be used in any place where we currently use the fixed reserve ratio.
  • We could have some additional governance parameters to set the initializationPeriod and the initializationExitPeriod, both used to adjust the bonding curve as time passes.
  • Store the time when the first mint happened on the subgraph deployment.

From a quick review it doesn’t seem to add excessive gas cost, but we need to be special careful in studying all the edge cases. Some that I can think of:

  • What if at the GNS level a subgraph is upgraded? are we good if the new subgraph deployment goes to initialization mode for X days? It would be great to keep the GNS and Curation contract independent like they are today.
  • Properly handle old subgraph deployment that doesn’t have the creation time set.

@jona has been working on a candidate implementation here that can help as a base to study this mechanism effective reserve ratio for mint by jona · Pull Request #1 · jona/contracts · GitHub

2 Likes
50

Hi, wanted to update everyone on the progress we are making with this proposal.

I’ve been building a proof of concept for the initialization phase proposal and after several discussions with @ari here are our findings:

Pros

  • Bots can no longer front run when subgraph is first published
  • Provides time for curators to research the subgraph

Cons

  • GNS and Curation functionality become intertwined
  • Increases likelihood of edge cases/attack vectors

How is it intertwined?

Whenever the Subgraph owner upgrades, all the signal is moved to a new deployment and that resets the initialization period. To avoid that, the GNS contract needs to pass data to the Curation contract.

Conclusions

GNS was designed to be independent from the Curation contract. If this change is implemented, it would move away from the original implementation and would require engineering time and auditor time to avoid unforeseen side effects.

How to avoid this complexity

If we flatten the curve in Curation and steepen it in the GNS(outlined in this proposal), we could implement this change without the added complexity on the GNS contract.

It lowers complexity for these reasons:

  • GNS solely handles the shape of the bonding curve
  • Curation contract no longer depends on GNS-specific data

Next steps

Get input from the community on our findings and also provide feedback on flattening curation bonding curve proposal.

Thanks!

2 Likes
51

Thanks for the update Jona!

I’m trying to better understand the ramifications of when a curator signals directly to a version (VSignal), if we flatten the curation bonding curve and implement the 1/2 reserve wouldn’t a curator be able to mint ‘no loss signal’ on a version and take advantage of the query fees?

Would the share price at the version level also change or could shares be minted at a static amount?

I’m assuming the 10% query fee incentive is added to the deployment level, would flattening the deployment curve require a change to add it to the GNS reserve?

52

No problem :slight_smile:

Yes but there are trade offs. As Brandon stated in his post, they would have to incur the entire curation tax upon upgrading. Additionally, they would need to become an active participant by manually updating their signal if the deployment becomes deprecated.

Shares minted at the version level would be minted 1:1, if that’s what you’re asking.

No, query fees will still be added at the deployment level.

Just to clarify on terminology, in case someone not familiar with these terms is reading this, version and deployment level are the same thing.

Version/Deployment/Curation/Core level = same thing
Name/GNS level = same thing

3 Likes
54

@jona is there any update you can share on this or that I can highlight to the curator community?

1 Like
55

hey @DataNexus

We been working towards several possible solution this month. Its a process of vetting the idea through research and implementations in order see the benefits and trade-offs that would effect the whole ecosystem.

We’ve got a couple of candidates we are looking at and will update you and coordinate with Oliver once we have something to share with the community.

I’ll set up a reminder to keep this thread up to date so that the community knows how things are progressing. Thanks for checking in! :slight_smile:

2 Likes