Motivation
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.
Effects
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
Pros
- 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.
Cons
- 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.
Risks
- 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.
