Flatten curation market bonding curve AND steepen Graph Name Service bonding curve


A number of issues have been raised related to how Curation works in the protocol today. See threads on Dynamic Curation Tax and Curator Impressions for a good exposition on these issues.

Additionally, a flaw in the current curation mechanism that has not received as much discussion is the effect on N-1 support for subgraphs during upgrades: because Curation in the core protocol is susceptible to front-running, the Graph Name Service requires that signal be migrated from a previous version to a new version in a single step. This leads to a situation where Indexers may stop indexing the previous version of a subgraph before the new version is fully indexed, which can cause an interruption in service for a Dapp Using the network. This is extremely problematic for subgraph developers currently looking to migrate queries to the network.

This proposal seeks to mitigate the worst of these problems without requiring a protocol upgrade.

This is in direct contrast to the Decaying Capital Gains Tax, and Showroom mechanisms, which are more sophisticated perhaps, but introduce more gas fees, carry greater execution risk, will likely delay the protocol’s migration to L2, and will perhaps be superseded by a more complete redesign of curation that has been dubbed “Curation V2”.

How it Works

The design of this proposal is very simple: swap the reserve ratios of the bonding curves at the core protocol and GNS levels. Specifically:

  • Change the reserve ratio of curation market bonding curve in the core protocol from \frac{1}{2} to 1, which corresponds to a flat bonding curve with a uniform price.
  • Change the reserve ratio of bonding curves in the GNS from a flat bonding curve of 1 to a steeper bonding curve of \frac{1}{2}.

Note: The GNS bonding curves use a nested bonding curve design, where there reserve tokens of the GNS curves are actually shares of the bonding curve corresponding to the current subgraph version in the core protocol.


Given that GNS bonding curves are nested with core protocol bonding curves, and the effective reserve ratio of the combined curves is left unchanged, we wouldn’t expect the dynamics of curating at the GNS level to change much (i.e. when using the “auto-migrate” feature of the Graph Explorer):

  • Curating on a quality subgraph earlier will still be rewarded more heavily than curating later.

However, the incentives for curating a subgraph deployment at the core protocol level will be substantially changed:

  • Price will always be uniform, so there is no incentive to curate early.
  • There is no incentive to front-run, pump-and-dump, or sandwich attack.

Cost/Benefit Discussion


  • The major benefit of this approach is in its simplicity.
  • It could be implemented without a protocol upgrade, just a parameter change.*
  • It addresses most major issues Curators and subgraph developers are experiencing in the curation market today.


  • It may reduce the quality of signal at the core protocol level, since flat bonding curves provide less of an incentive to predict future usage of a subgraph.
  • Deploying a subgraph for the first time is expensive (i.e., around ~$400 USD in gas), and removing the incentive to be first to curate a subgraph deployment, removes one of the sources of income that mitigates these costs.


  • May increase the incentive to fork or create “follower” subgraphs at the GNS level that always follow the same upgrade path as some target subgraph in the GNS, to benefit from their query fees, without having to participate in the curve dynamics at the GNS level.
    • Worth noting that the owners of these follower subgraphs would incur a larger share of the curation tax if you assume that they are both the owners and primary curators of these follower subgraphs (because subgraph owners in the protocol today cover 50% of the 2.5% curation tax on upgrade).
  • Changing curve shapes over too short a time period opens up room for economic attacks.
    • This can be mitigated by upgrading the protocol to change reserve ratios gradually over some period of time anytime a change to a bonding curve reserve ratio parameter is implemented. However, this diminishes one of the benefits of this proposal, which is not requiring a contract upgrade.
    • Alternatively, the upgrade could be implemented as a series of smaller upgrades. A downside of this approach is that it is untenable to make the change to the reserve ratio as smooth as would be enabled via a contract upgrade.

Next Steps

The primary benefit of this proposal is as a simpler alternative to the Decaying Capital Gains Tax and Showroom proposals. Once those proposals are fully evaluated, it will be up to the community to decide how the cost-benefit analysis pans out. In particular, it will important to get the input of Curators and Subgraph Developers.

If this approach ends up looking more appealing in the short term, then this thread could be followed up by a formal GIP and a snapshot vote.


Hey Brandon, I appreciate your time and attention on this topic.

One aspect that I’m not understanding is if there is a means to prevent someone from signaling directly to version N at a deployment level and benefiting from minting shares cheaper then they would at a GNS level. Is there a way to prevent signal transactions at a deployment level if it’s the active deployment for a GNS?

If only historical versions have a flat bonding curve then it would be fairly easy for a subgraph developer to signal on N-1 until their production version of the dApp is ready to use version N (or leave it there in perpetuity should they decide N-1 is necessary for specific segments of their dApp).

As long as this can be done I think it’s a great solution for curation V1.


One aspect that I’m not understanding is if there is a means to prevent someone from signaling directly to version N at a deployment level and benefiting from minting shares cheaper then they would at a GNS level.

The answer is a bit subtle. Technically, they would not be able to mint shares “cheaper” by signaling at the core protocol level. This is because the reserve tokens at the GNS level are actually shares of the base layer bonding curve. So the Curator is minting shares at the base layer at the same price regardless of whether they then go onto deposit these as reserves into the GNS bonding curve.

See this old proposal on GNS signaling for more info on how this works. Note that the terminology used here is now deprecated (“vSignal” are shares in the base protocol bonding curve and “nSignal” are shares in the GNS layer bonding curves)

While the Curator does not mint shares more cheaply by signaling directly on the subgraph deployment, they do avoid the principle risk entailed by depositing those shares as reserve into a bonding curve with a reserve ratio less than one.

Signaling directly on the subgraph deployment, however, trades off the convenience of having your signal auto-migrated as well as the fact that the subgraph owner in the GNS shares the cost of upgrading, whereas signaling directly you incur the entire curation tax.

Even so, some Curators may choose to signal directly on subgraph deployments, and I think that’s perfectly acceptable in this bootstrapping phase where the core priority should be to get hosted service subgraphs migrated to the network w/ a predictable cost structure and user experience.

If only historical versions have a flat bonding curve then it would be fairly easy for a subgraph developer to signal on N-1 until their production version of the dApp is ready to use version N (or leave it there in perpetuity should they decide N-1 is necessary for specific segments of their dApp).

Not entire sure what it would mean for only historical subgraphs to have a flat bonding curve.

As long as this can be done I think it’s a great solution for curation V1.

I’m glad you’re on board with this proposal! This is currently my preferred route, as it poses the least execution risk, and enables the core developers to focus on getting to L2 scaling as quickly as possible, which dramatically improves the protocol experience across a number of dimensions.

1 Like

Bumping this one as it seems like our cleanest path to resolving subgraph versioning related issues.

Also, it seems like the explorer may need an update so that the N - 1 version has an query url that can be easily founded and utilized.

I am quite in favor of this change, however as a curator with skin in game what are the implication in this change ?

I mean its just a parameter change for you but for most of curator with non realised profit or non realised loss removing the bounding curve will probably hurt a lot.

For exemple, sushi swap subgraph (i am not signaling it but this a good exemple) with 384k grt used by curator to signal and 150k left but at current point their share are valuated at 240k until no one is selling buying.

Can you detail a scenario of “financial” impact for curator ?

Please correct me if i am missunderstanding this proposal, but you are basically creating at worse version of a delegator and destroying the current curator role. the curator you sugest will have at most the same amount of reward than a delegator, and a higher oportunity cost. At least the indexer will be able to switch allocations for the delegator every 28 days to adjust for subgraphs that earn more query fees, while the curator would have to pay taxes and gas fees to make those adjustments, not to mention this would require much more work than that of the delegator.

Being a good curator will be at most as rewarding as being a good delegator, but with much more work involved. if this change were to pass i would move all my curation signal to delegation and the indexers can have fun figuring out what subgraphs are the best ones. A curator than only earn query fees, has no incentive to put the work in. Not to mention that currently most if not all honest curator are not in profit, but most of them understand that onece the migration occurs new signals will come in and new oportunities to recoup those loses will arise. I can forsee many of this early curators and supporters of the graph leaving and taking the loss if this change were to go through.

I am happy to discuss more in case there is something i am missing.

Hey Steven, I think there was a slight misinterpretation on this one.

The key datums are that currently the pitch of the bonding curve is determined at a version (deployment level) - e.g. ArtBlocks V0.0.1.

When you signal with auto-migrate, you are signaling to the Graph Name Service (GNS). This starts with placing signal on the current version (ArtBlocks V0.0.1) and then stakes it to the named subgraph.

When ArtBlocks upgrades to V0.0.2 (new deployment) the GNS will move the signal to the new version and a bonding curve will be created.

This suggestion is adjusting it so that the pitch is determined at the GNS level rather than at the deployment level. Thus after upgrading, ArtBlocks could then go place risk-free signal on V0.0.1 to ensure it had signal and maintained support while indexers are syncing V0.0.2. Otherwise the consumer experiences downtime on each upgrade.

This proposal is solely to address the versioning issues that consumers have had (which in turn will assist with migration).

Thank you for the clarification, i was surprised something like this was propossed and thus why I thought I had to be missing something. So the v1 signal can then be removed once v2 is fully sync and operational? Right now is it not possible to signal on the previous version? or is it just not risk free?

It is not risk free.

If a publisher signals to a version, then upgrades, the auto migrate signal will burn shares (and move to the new version) and destroy the publishers signal value.

@MrStevenStiffler this is exactly right. You can think of nested bonding curves as having a “composed curvature” that is a functional composition of the two constituent bonding curves. By swapping the curvatures in this case, the composed curvature is unaffected.

Note that not all nested bonding curve designs compose in this way. For example in this proposal, it’s only the curvature of the outer curve that determines the “overall” curvature.

To close the loop on this, the economics working group decided not to pursue this proposal, for the reasons I believe you are referring to. Ultimately, any Curator that had signaled immediately before the curve flattening would see an immediate unrealized loss. Also, even announcing the flattening of the bonding curve at the subgraph deployment level had the potential to trigger a “run on the bank” at the subgraph deployment level because the incentive would be to exit immediately to lock in the highest price.

The favored solution to avoid some of the harmful dynamics at the subgraph deployment level among the economics working group, at the moment is: GIP-0026: Principal-Protected Bonding Curves