GIP-0025: Principal-Protected Bonding Curves

The following idea was initially put forward by @juanmardefago to address a number of challenges in the Curation Market that are described below. Juan is also currently working on the Solidity implementation of the proposal, the details of which will be added to the technical specification section of this proposal, when ready.

The proposal can be viewed on Radicle here. For convenience it is also pasted below:


Abstract

We introduce principal-protected bonding curves , a new bonding curve construction in which shares are minted proportional to reserves deposited, using the Bancor formula[1], but when burning shares, a user is guaranteed to be able to withdraw the amount they had deposited for those shares. In other words, the user of such a bonding curve incurs no principal risk.

We propose replacing the bonding curves currently used for subgraph deployments with principal-protected bonding curves. We additionally propose modifying the bonding curves in the Graph Name Service (GNS) , to compose with principial-protected bonding curves in a nested bonding curve design, without introducing adverse incentives. Minting shares at the GNS-level will continue to carry principal-risk.

Curation royalties will continue to be distributed proportional to ownership of curation shares, preserving the dynamic where being earlier to mint shares on a bonding curve, either at the GNS or subgraph deployment level, is still rewarded relative to minting later.

Background

The Graph’s curation market is designed to elicit a market signal that acts as a proxy for demand for Indexer services on subgraphs that have been deployed to the network. This signal is used to direct indexing rewards to the subgraphs where there is a greater demand for Indexer service.

The curation market consists of Curators minting shares, also known as signaling, on bonding curves of one or more subgraphs, which entitles them to a royalty on future query fees generated by the respective subgraphs. There are two primary reasons for signaling on a subgraph:

  1. A financially motivated Curator signals on a subgraph because they believe the present value (PV) of future curator royalties they will be entitled to is greater than the cost of minting shares.
  2. A decentralized application (dapp) developer signals on a subgraph in order to bootstrap Indexer services on the subgraph to power their application.

The Graph’s curation market uses a nested bonding curve design, as depicted above, where Curators may signal directly on an inner bonding curve representing a subgraph deployment or an outer bonding curve representing a subgraph that can have its version updated with new subgraph deployments while maintaining the same outer bonding curve state.

Motivation

The current bonding curve design presents a number of challenges to dapp developers acting as Curators:

First is that they lead to unpredictable costs for using The Graph as a subgraph developer. Signaling on a subgraph today carries principal risk, which means that the subgraph developer that is simply interested in having their subgraph indexed may be required to put capital at risk in order to use the network. Principal-protection makes the costs of using the network much more predictable and unaffected by volatile curation market dynamics.

Furthermore, signaling enough to attract Indexers to a subgraph often implies a large outlay of financial capital for developers, many of which are independent or members of startups that do not have large amounts of excess capital on hand. Principal-protection enables third parties to rent signal to a subgraph developer at a nominal rate, providing a more familiar billing experience similar to software-as-a-service (SaaS) monthly or annual subscriptions.

Additionally, the current protocol design presents a broader problem to all Curators, namely that bonding curves are sensitive to initialization and decomissioning conditions. This is specifically a detriment to subgraph deployment bonding curves as these are replaced each time a subgraph is upgraded, which could happen as frequently as once every few days or weeks.

For example, when a subgraph is upgraded, it is in the best interest of all Curators on the current subgraph deployment to exit the bonding curve as quickly as possible, securing a higher price than other Curators exiting the curve. Because bonding curves are typically specified with a reserve ratio less than one, the incentives are similar to a run on a bank that doesn’t have cash reserves backing all deposits.

Similarly, when a new subgraph deployment bonding curve is deployed, it is in the best interest of Curators to mint shares before all other Curators, so-called “apeing in”, in order to secure the lowest possible purchase price.

These problems are less pronounced for bonding curves at the GNS level becuse these are intended to be long-lived, on the order of years. For subgraph deployment bonding curves, principal-protection prevents perverse incentives from bonding curve initialization or decomissioning because there are no capital gains or losses possible at the expense of other Curators.

Prior Art

Shares in a principal-protected bonding curve bear similarities to principal-protected notes (PPNs)[2], which are investment contracts in which one is guaranteed to recover at least the amount invested plus fixed or variable gain.

High-Level Description

Principal-Protected Bonding Curves for Subgraph Deployments

Principcal-protected bonding curves mint shares according to the Bancor formula, which specifies an invariant that keeps the ratio \frac{reserves}{price \cdot shares} constant for the bonding curve, where reserves are the amount of GRT that have been deposited into the curve, shares are the amount of shares that have been minted, and price is the current price per share.

Principal-protected bonding curves compute reserves to withdraw based on the average cost basis of the shares being burned. This requires additional bookkeeping to track the average cost basis of any balance of shares that are minted by the bonding curve. When two balances are combined, for example, by transfering some amount of shares to an account that already has a balance of shares, the new balance must have an average cost basis that is a value-weighted average of the two previous balances.

This also implies that bonding curve shares are no longer completely fungible; while each share is entitled to an equal portion of Curator royalties, they are potentitally entitled to different amount of reserves to withdraw upon burning, due to differences in average cost basis.

Modified GNS-level Bonding Curves for Subgraphs

Average Cost-Basis Aware Bonding Curves

The non-fungibility of principal-protected bonding curve shares requires special considerations when designing any kind of secondary market, automated market maker (AMM) or pooled funds that accept such shares. To illustrate, consider two liquidity providers (LPs), Alice and Bob, depositing the same amount of shares, with cost bases of a and b, respectively, where a<b. The average cost basis of shares in the liquidity pool will be (a+b)/2. If Alice is allowed to immediately withdraw the same amount of shares that she put in, then she will inherit this new average cost basis. If she then burns these shares, then she will realize an immediate capital gain of (b-a)/2, at the expense of Bob, despite no material change in the underlying value of shares in the subgraph deployment bonding curve over that time.

The GNS-level bonding curves, which currently use shares of subgraph deployment bonding curves as reserves, would suffer from a similar problem where shares of different cost bases would be pooled together, benefiting Curators that had shares with lower cost basis and harming Curators that had higher cost basis and would have been entitled to greater levels of principal-protection.

Rather than using shares of subgraph deployment bonding curves, or inner shares , as reserves, GNS-level bonding curves must use the total cost basis of all inner shares as the reserve quantity to be used in the Bancor formula. Similarly, they should use the average cost basis of deposited reserves as the reserves deposited quantity in the Bancor formula.

With this new composition design, the reserve ratio of the GNS bonding curves should be changed from 1 (a flat curve) to 1/2 in order to the preserve the effective composed reserve ratio that currently exist in the protocol.

Pass-Through Principal-Protection

The design we have presented thus far would have little benefit to most dapp developers who signal via the GNS-level nested bonding curves, where shares issued are not principal-protected. Note that this is a feature, not a bug, as the lack of principal-protection at this layer allows the GNS-level bonding curves to act as secondary markets that allow financially motivated Curators to realize capital gains, which strengthens the incentive to signal towards subgraphs that they expect to exhibit high demand for queries in the future.

Subgraph developers, however, are primarily motivated by the ability to get their subgraphs indexed, and not realizing capital gains or receiving curation royalties. Therefore, the GNS must be modified such that each subgraph has an outer bonding curve, which is not principal-protected, and one or more separate balances intended for the subgraph developer to deposit and withdraw from, which are principal-protected. Note that this must be implemented such that any account may deposit a principal-protected balance on behalf of a subgraph at the GNS level and have those funds only be withdrawable to the same account. This will enable third party smart contracts to be implemented in the future which rent signal to subgraph developers without incurring any principal risk.

Only shares in the outer bonding curve will be entitled to curation royalties, while the principal-protected balance will neither be eligible for capital gains nor curator royalties. Importantly, both Graph Tokens (GRT) deposited into the outer bonding curve and into the principal-protected pool at the GNS level, will be signaled to the principal-protected bonding curve at the subgraph deployment level. It’s specifically the principal-protection at the subgraph deployment layer which enables the GNS to implement a principal-protected pool of GRT that can also be used productively for signaling.

Removing Subgraph Version Upgrade Restrictions

Currently, the GNS has a feature that prevents a subgraph being upgraded to a subgraph deployment whose bonding curve has already been initialized. This is a protection that helps to prevent front-running of a subgraph version upgrade. It also protects Curators on a GNS-level bonding curve from being rugpulled by the owner of a subgraph. The hypothetical attack goes as follows:

  1. Curators are signaled on a subgraph.
  2. Owner of the subgraph signals on a new subgraph deployment using their own tokens.
  3. Owner of the subgraph upgrades the new subgraph deployment, migrating Curators signanled tokens from the previous version’s subgraph deployment.
  4. Owner unsignals their own tokens from the subgraph deployment

Due to the bonding curve dynamics, this effectively steals tokens from the Curators on the subgraph because there would instantly be much fewer withdrawawble tokens in reserves than what the Curators initially signaled, while the subgraph owner realizes an immediate and sizable profit. With principal-protected bonding curves, this is no longer an issue, because the Curators of a subgraph deployment are guaranteed to receive at least their cost basis back upon unsignaling.

Therefore, the protection that limits what subgraph deployments a subgraph may be upgraded to must be removed. This will enable multiple GNS-level subgraphs to have the same subgraph deployment as their current version, which is important for the reuse and composability story of The Graph.

Technical Specification

TODO

Protoype and Simulation

A prototype of this proposal has been implemented alongside other bonding curve prototypes in this notebook. The notebook includes some basic scenarios highlighting how principal-protection would protect subgraph developers from behaviors like sandwich attacks at the subgraph deployment level.

The prototype also includes the modified outer curve design of a nested bonding curve where the inner curve is principal-protected.

Validation

Audits

In addition to the prototyping and simulation described above, the implementation of this proposal should receive external audits, given the complexity of the design and the upgrade path, as well as the large sufrace area of the protocol that this proposal touches.

Signal Renting

We should validate that the interfaces introduced in this proposal make it possible to design an external contract that is locked down to only allow usage of methods of the bonding curves that offer principal protection. This will ensure the implementation is future-proofed for signal renting.

Upgrade Path and Backwards Compatibility

As noted elsewhere in this proposal, principal-protected bonding curves are not compatible with the current GNS-level bonding curves. Furtheremore, it is impossible to upgrade existing subgraph deployment bonding curves in-place, because they would have needed to have started tracking average cost basis for shares from the moment the curves were created.

Therefore, this proposal must be implemented in such a way that leaves existing subgraph deployment bonding curves unchanged, while changing all newly created subgraph deployment bonding curves to be principal-protected.

This complicates the upgrade strategy for the GNS-level bonding curves. This requires having both the legacy and new GNS bonding curve logic living side by side, and switching to the new logic as soon as the subgraph is upgraded to a subgraph deployment that has a principal-protected bonding curve.

Rationale and Alternatives

Full Principal-Protection

An alternative design that was considered was to offer principal-protection to all Curators in the protocol, including at the GNS level. A benefit of this is that approach is that it limits the downside risk of curating at the GNS level, and also mitigates certain behaviors like sandwich attachs at the GNS level.

This alternative has two major drawbacks:

  1. For Curators with a very low cost basis for shares on a subgraph that has increased in value, the rational incentive is to seek a secondary market where there is price discovery and the potential for capital gains, as opposed to simply burning shares in return for cost basis. As these secondary markets require careful understanding of principal-protected bonding curves, they are unlikely to emerge organically or possibly Curators might be encouraged to use less secure or well designed secondary markets.
  2. The possibility of principal loss also implies the possibility of capital gains, which is an important incentive for financially motivated Curators that want the possibility of realizing capital gains, rather than simply signaling on a subgraph indefinitely and collecting curation royalties. This ability to profitably exit a curve also frees up capital to be used for signaling in new subgraph bonding curves.

Future Work

Subgraph Developer Incentives

This proposal, for the first time, makes a formal separation in the protocol economics between the subgraph developer Curator and the financially-motivated Curator roles.

In the future, this distinction could be further emphasized with additional incentives tailored to the subgraph developer, for example like a mechanism to fairly determine the split of curation royalties between the financially motivated curators and subgraph developer, rather than simply setting the latter’s share of curation royalties to zero.

Front Running Prevention

This proposal mitigates many types of adverse behavior and incentives that exist in the protocol today, but does not address all harmful behaviors that we should expect to continue at the GNS layer, such as apeing in , sandiwch attacks , or other forms of front-running.

Signal Renting

This proposal lays the foundation for signal renting , the ability for subgraph developers to pay a nominal subscription fee to borrow signal for use in the protocol. The actual design and implementation of this feature is intentionally left out of scope, so that it may either be covered in a future GIP or possibly left as an exercise for third party ecosystem contributors and kept separate from the core protocol design.

Copyright Waiver

Copyright and related rights waived via CC0.

Notes


  1. Hertzog, E.H., & Benartzi, G. (2018). Bancor Protocol Continuous Liquidity for Cryptographic Tokens through their Smart Contracts. ↩︎

  2. Principal protected note. (2021, October 23). Retrieved March 03, 2022, from Principal protected note - Wikipedia ↩︎

15 Likes

Appreciate the hard work and thought to get the curation side functioning. Thanks

1 Like

@juanmardefago I updated the GIP with additional discussion around removing the protection in the GNS on subgraph upgrades.

Conclusion

This proposal is well-intentioned, but I think it misses some key points and does not go far enough to fix the problem.

I also think that this proposal makes strong assumptions about the value proposition of bonding curves. The assumed benefits are taken as constraints, which negatively impact the design as a whole. I believe these assumptions to be incorrect and, therefore, the tradeoff for naught.

Context

The problems facing curation are front-running and poor quality of service (QoS). As a motivating example, consider Eden Network. This subgraph recently migrated from the hosted service to The Graph Decentralized Network. The project put down 5k GRT curation to ensure a high QoS for their dApp, but frontrunners sandwiched their transaction and extracted nearly 80% of their deposit.

The negative outcome is two-fold. In the short term, the Eden Network project has been robbed of 3.9k GRT. Ongoing, the QoS available to consumers of the Eden Network is degraded due to having fewer Indexers available as a result of the lower curation signal. Semiotic has shown us that this attack repeated over many subgraphs has created a problem worthy of addressing.

Bonding Curves

The opportunity to front-run comes from the very nature of bonding curves. As long as bonding curves exist in the protocol, front-running will continue. Various modifications to bonding curve designs mitigate front-running, but they can only change the attack’s time horizon. The defining feature of a bonding curve is that by sandwiching transactions, you can gain collateral from the participants in-between. That’s what a bonding curve is . Mitigations, like batched bonding curves, principle protected bonding curves (this GIP), and others only remove some conditions when the bonding curve mechanics are applied rather than ask whether there is any scenario where bonding curves are acceptable. Above all, bonding curves are a reward mechanism for front running.

Given my negative opinion of bonding curves, is there some perceived benefit outweighing the clear drawbacks? From the GIP: “The possibility of principal loss also implies the possibility of capital gains, which is an important incentive for financially motivated Curators.”

This GIP is wrong or misleading on three points. The first error is the implication that the protocol would be devoid of critical incentives without bonding curves. The second is that bonding curves are a source of such incentives. The last error is that the actual front-running attacks we can see in the protocol today are an acceptable tradeoff for the illusory promise that we might see additional curation incentives someday. Let’s consider each in turn.

First, curation shares are already adequately incentivizing participants. Since shares represent the rights to a portion of a subgraph’s query fees, if queries on curated subgraphs increase over time and risk decreases, so will the incentive to curate. An exchange of those shares benefits everyone involved. These incentives are “natural” (instead of requiring explicit machinery), easily described, and not zero-sum.

Second, bonding curves will not result in additional incentives to curators. If an early buyer exits, it is in the best interest of every later buyer to exit before them by front-running. The amount one is willing to spend on gas to exit first should be as much as one would stand to lose by staying. So, the benefactors of the resulting gas war and run on the curve would be miners rather than protocol users.

Lastly, the negative effects of bonding curves are playing out here and now and affecting users of The Network in real ways. It would be a mis-prioritization to put these concerns below the potential for further incentivization for curators. Even if the proposal’s assumptions were correct, the concern of front-running for curators should outweigh it. And, the QoS concerns weigh heavier still.

Rewards and Signal

The theory of the curation market is this: by rewarding participants for accurately predicting query fees, we can extract a reliable signal of the expectation of future fees from the market. Curators compete for these rewards by acting as oracles taking off-chain information and distilling it on-chain. This signal is needed to help indexers decide what subgraphs to index, separating the role of “infrastructure provider” from “due diligence” and rewarding each separately. We believe in this proposition so strongly and value the signal so highly that we have dedicated a 10% share of query fees to curation.

This thesis depends on the relationship between the prediction and the reward for quality signals. (Since a bonding curve rewards front running above query fee prediction, that results in low signal quality, but I digress). This GIP proposes that “the principal-protected balance will neither be eligible for capital gains nor curator royalties.”

In this GIP, the relationship between curation shares and rewards has been broken. Therefore, the relationship between curation shares and signal quality has also been broken. One may even argue that the reward-free deposit is a bet against the profitability of indexing the subgraph. That would make the correlation between curation shares and query fees negative.

Instead of creating a healthy prediction market, we’ve created a means to manipulate the allocation of infrastructure worldwide without paying the cost. Signal renting may amplify the effects of this. For bootstrapping to be healthy, GRT needs to flow directly from the hands of the one doing the bootstrapping to the indexers paying the costs.

Inflation-funded indexing rewards were created to bootstrap The Network, not individual subgraphs. Unfortunately, when these rewards dominate an Indexer’s considerations, it creates perverse incentives resulting in less-than-ideal allocations and QoS. We must not forget that a more long-term sustainable solution is to have query fees or bootstrapping rewards that are paid by consumers dominate. I feel that the best path forward is to have each GIP move us closer to sustainable mechanisms that shift incentives toward higher QoS rather than further entrenching the existing mechanisms. As we transition over time, I expect the higher rewards for Indexers and higher QoS for Consumers to be self-reinforcing.

Ideas

I don’t want to put forward a strawman since attacking it could easily detract from pointing out areas for improvement. Even so, I think it would be helpful to point out some properties that I think would be beneficial; could a coherent design enable these properties. Some of these ideas may be mutually exclusive or incompatible with other parts of the protocol as-is, but for the moment, I’d prefer to dream to inspire the best design.

Rewarding subgraph authors and dApps

It would be nice if subgraph authors were rewarded instead of punished for their work. Right now, they have to pay an additional cost (such as signal renting) on top of the work of developing the subgraph. Instead, I would like to see something like subgraph authors owning 100% of the curation shares and be entitled to the query fees they enabled. Sure, they could sell those shares, especially if they want to cash out earlier for their upfront investment of time. This may be extended such that dApps own GNS curves and subgraph authors own inner curves.

Bootstrappers pay directly

Sometimes the value to a dApp of indexing is greater than the query fees. This is especially true when dApps no longer subsidize the query fees and they are paid by the consumer. In that case, there should be a direct bootstrapping mechanism by having dApps provide indexing rewards as a subsidy. Note that if it’s not worth it for the Indexer to accept the bounty, it would be a net negative to the economy to index the subgraph since nobody values it more than it costs.

All bonding curves are principal-protected

There is something interesting about having shares of revenue cost increasingly more and backed by an infinite supply if that is divorced from taking other people’s shares. This GIP could do that.

Tax curation shares to fund indexing rewards

This mechanism would make curation a radical bet on future profitability while also providing a sustainable source of indexing rewards. The proposition here is, “I’m so confident that this subgraph is profitable that I’ll front the cost of indexing for the expectation of that being paid back in query fees and then some.” This is the kind of change that would be needed to make The Network sustainable.

Make curation shares sellable

Enable natural capital allocation by allowing for a secondary market for shares. The argument against it in this GIP seems to be that “Curators might be encouraged to use less secure or well designed secondary markets.” Curation is the most savvy role in the protocol, requiring a marriage of technical ability and market valuation. So, I find this conclusion lacking in faith. If it is so hard, maybe we should build it ourselves.

3 Likes

I’ve actually been trying to come up with what I think is a more complete solution to the front running problems that we’ve been seeing regarding all Bonding Curves, and most of my lines of thought actually pointed me to a similar conclusion that the one you are presenting here. I’ll add a little bit more context so the line of thought makes sense though :sweat_smile:

My initial idea with Principal Protected Bonding Curves (PPBCs from now on) was to keep the discovery incentive characteristics of Bonding Curves, while completely eliminating the front running potential, by revamping the burning of shares to use a different logic (in this case, tracking deposits and returning the same amount always, plus royalties).

That idea is relatively simple to apply to Curation level BCs, since they are the first level (inner curve) and have no dependencies on how they would interact with other BCs, but applying it to the GNS level BCs requires some extra logic, since you start to have some nesting of BCs, which isn’t particularly intuitive to reason (although it should be possible to implement PPBCs to all levels, just harder).

After some brainstorming with the team, keeping the potential capital gains for curators seemed to be pretty important too, so we started thinking of ways to do so, and the most obvious one was just to have a PPBC on the inner curve (Curation level) and regular BC on the outer curve (GNS level), and treat subgraph developers as a “privileged role” so that Signal Renting could be implemented with no inherent risk.

As you mentioned here, I also personally I think it’s better to simply remove regular BCs everywhere, and replace them with PPBCs (considering them as royalties enabled ones, not exactly like they are depicted in the original GIP, so in this way they would behave exactly like you’d expect, enabling curve defined price characteristics of shares, and always allowing for redeem of the exact amount you deposited initially + all of your corresponding royalties).

And I also think that this is the way to go, create some sort of secondary market (as @That3Percent mentions here) that is aware of the peculiarities of the shares (semi-fungibility) to allow for some sort of capital gains that is not automatic and doesn’t affect any other user that’s currently signalling on any subgraph.

In that way, we wouldn’t require any sort of mitigation to the inherent risk of BCs (initialization phase and decaying capital gains tax are the two more important proposals on that front), you’d still have access to some possible capital gains (through the secondary market), while at the same time allowing for “discount” entry through the secondary market (you’d be able to buy shares at a lower price than defined by the minting through the PPBC by just buying through the secondary markets, allowing the capital gains profit for people wanting to exit, while getting a discount yourself, with some caveats).

We did discuss this possibility, and there are a few issues that we could imagine, mainly liquidity of the secondary markets, and the possible extra complexity of having the secondary market itself (engineering of them as well as extra parts on an already complex system), but I personally don’t think it would be that much more complex than having the original proposal and all the required mitigations on top.

The secondary market would have an important caveat, any person buying shares at a discount price would be doing so by acknowledging that the “discounted” share has less GRT deposited, and thus, if they would be redeeming instantly, they’d be instantly losing GRT (since they’d have payed a higher amount of GRT to buy those shares than those that would be redeemed by the underlying deposit, which is the actual capital gains profit that the curator exiting gets, basically speaking). I don’t think that’s a major issue, since buying the shares at a discounted price would offset that instant loss if your bet on query volume for those shares was correct.

Regarding the other ideas, I think some of them are quite novel, although I haven’t got my head around as to how they would work in practice and how we’d be able to implement them without making the UX extremely complex, but overall I do agree with the feedback provided here.

3 Likes

I forgot to add to this part, technically speaking, curation shares are sellable already, since they are ERC20 compliant, but the semi-fungibility of them require a specialized secondary market to be able to highlight them appropriately. That’s why I think an official secondary market with an auction-like system (since semi-fungibility sort of resembles NFTs) would probably be the best way to go. (you could also create partial fills for shares, to make it easier to exit at a profit if there’s low liquidity).

I agree with some of this, but there are a few things I’d like to point out.
While BCs reward front running (or apeing in), some mitigations make it unfeasible to do so, because of the way they modify the already existing nature of BCs. Principal Protected Bonding Curves completely eliminate the possibility of a rug-pull, so the front running potential only affects the royalties part of the shares. In this way, even if bots were to front run every single curator, while the royalties of the curator itself would be hurt (since he might’ve been able to get more if the bot wouldn’t have front run), it would still be a valid signal to indexers, so the main purpose of Curation would still be respected, while also making it so that the front-running would be profitable only if the curators bet on that subgraph was correct. (If we want to incentivize discovery characteristics, I don’t think we can get a more reasonable mechanism than this)

This is the top reason why I actually though of PPBCs in the first place, and I still think it’s one of the most important things I can think of when brainstorming possible improvements for Curation.

I wouldn’t want to come up with a solution that would still enable strategies where some curators gain at the expense of another, given that it would mean enabling (in a more mitigated way, but still enabling) the same bad behavior that we saw in the initial version of Curation, which also leads to quite volatile and not totally relevant signal for indexers, or just a stale market due to fears of going into it due to the related risks (and possible bad risk/reward ratio).

Fully replacing BCs with PPBCs that do enable royalties and are tradeable on a specialized secondary market would lower the risk part almost completely (you always have some risk due to taxing, which there’s another GIP for improvements there, and the usual opportunity cost, but that’s it), while making the reward part be almost exclusively query fee driven, with a little bit of potential capital gains through a secondary market, but not guaranteed (currently it’s really low reward, could potentially be quite important, and we always have ways of balancing that through global parameters like the global curation royalties split). The main issue would be then that you are removing the guarantee for capital gains, and making it a free-market type situation, which seems totally reasonable from my point of view, given that you almost completely remove risk from the equation.

3 Likes

Thanks for the input @juanmardefago and @That3Percent

I agree with most of Juan’s responses to Zac’s comments, with some additional thoughts below:

Front-Running Example

This example would be completely addressed by the current proposal, thanks to the pass-through principal protection for the subgraph owner at the GNS level. Thus, the proposed changes in response to this example feel like non-sequiturs.

PPBC All The Things!

I actually think there are very good reasons to consider making both levels of the curation market, subgraphs and subgraph deployments, use PPBCs. @juanmardefago does a good job of explaining some of the technical considerations of doing so.

One that hasn’t been noted is that migrating the inner bonding curve of the curation market to PPBCs offers a natural upgrade path, as these are replaced all the time in version upgrades. Upgrading the outer, subgraph bonding curves to PPBCs offers no such natural upgrade path and would likely lead to “runs on the bank” at the outer bonding curve level as Curators seeking to lock in unrealized gains would be incentivized to exit before the opportunity to realize such gains is lost.

I’ll note that designing a secondary market suitable for the partially fungible PPBC shares is an open research question, and would add a third level of nesting to our curation market. This is both a technical challenge and perhaps more importantly, a significant UX challenge.

All of the above isn’t to say that we shouldn’t explore PPBCs at both levels. I think we should. It is just to say that it turns this proposal into a way bigger proposal than it already stands.

It’s worth reiterating that this proposal was intended to address very specific issues for subgraph developers trying to migrate to the decentralized network, which it does. Implementing PPBCs at the outer curve of the curation market primarily benefits financially-motivated curators, not subgraph developers, and thus is beyond the scope of what this proposal is trying to achieve. There is no inherent reason that both PPBC-related ideas need to be bundled together into a single mega proposal that is likely to introduce added execution risk and delayed value to subgraph developers.

Eliminating indexing rewards through token issuance

I disagree with the premises and the conclusions stated above.

Both economic analysis (see Prysm Group studies), agent-based models (see Semiotic studies), and empirical observations (from the E&N data science team) are all mutually consistent and support the notion that more indexing rewards on a subgraph lead to more unique indexers on that subgraph, which we expect in turn to correlate to a higher quality of service.

Reducing indexing rewards to what a subgraph developer was willing to pay directly would increase the costs to subgraph developers of using the network and decrease the overall quality of service.

The instances in which more unique Indexers do not translate to higher quality of service are idiosyncratic and largely addressed by other proposals that have either been discussed in this forum or as GIPs. For example:

  • Requiring a recent PoI to be submitted before opening an allocation makes collecting indexing rewards conditional on stricter data freshness requirements, which has been a detractor for QoS.
  • Subsidized query fee settlement Makes Indexers more responsive to query fee incentives, because it reduces the additional fixed cost of serving queries to nearly zero, such that it is theoretically profitable to collect even a single query’s worth of query fees (ignoring mental transaction costs and slightly more dev-ops overhead).
  • Indexer infrastructure automation (being worked on by @Ford @chris and the indexer experience WG) also reduced the fixed costs of serving queries and has a benefit similar to the above.
  • Stake Rebates also make Indexers more responsive to the incentives of query fees, relative to indexing rewards.

Additionally, from Prysm’s analysis relating unique indexers on a subgraph to indexing rewards and Indexers costs, we should expect proposals that increase the total amount of indexing rewards, such as @Sam’s proposal for closing stale allocations, or proposals that reduce the fixed costs, such as L2 scaling (being worked on by @ari and @Pablo) and Graph Node indexing performance improvements to both increases the number of unique Indexers on a subgraph and thus further drive up QoS.

In short, there are many solutions being worked on to improve QoS in the network today, but the indexing reward mechanism from token issuance is largely working as intended, if requiring some tweaks, and eliminating it altogether would make QoS in the network worse, not better.

For more context on some of the above proposals, stake rebates, subsidized query fee settlement, and stale allocations were discussed at the most recent core devs call.

Bonding Curve Critiques

Bonding curves are used as a prediction market to elicit information about the future demand for subgraphs. Without some form of price discovery, no such information would be elicited. Curation as a mechanism for coordinating resources for data sets acting as public goods is also intrinsic to @yaniv’s initial vision for the protocol.

Simply giving Curators 100% of the shares would not elicit any information until those shares were put into some form of a secondary market, at which point we’re back in the realm of using some form of bonding curve and all the issues around slippage, MEV, etc. that that implies.

I don’t think anyone is saying that the front-running we see in the protocol today is necessary or acceptable. This proposal addresses one large category of front-running that has impacted users. Past protocol upgrades, such as batching publish and signal also addressed some gaps. And as @juanmardefago noted, there are several other proposals that have been prototyped and discussed in the forums that address other forms of front-running and MEV. There is a large design space to improve bonding curves, but I haven’t yet seen any good arguments for abandoning them entirely.

This presupposes that all the later buyers don’t value the shares at the current market price. If they do, then their incentive would actually be to curate more after the first Curator exits, until the market price reflects their private valuation. They could try and sandwich attack, with a Burn followed by a Mint to return the bonding curve to their private valuation, but this could be mitigated, if not perfectly, with slippage protection. In general, these types of issues have not stopped other bonding curve AMMs from being very successful.

Other Proposal Critiques

Only for subgraph developers, which are primarily motivated by the intrinsic utility of having their subgraph indexed. The connection between shares and royalties is maintained for financially motivated Curators.

Fin

That was a lot to respond to, but hopefully, that helped clear things up!

2 Likes

I believe it is a good exercise to challenge the use of bonding curves in the curation market to see where that discussion leads us.

The path we are taking is to mitigate (but not entirely remove) the effects that having a bonding curve at the core of the curation market creates. So for a series of effects, we have several new proposed mechanisms:

  • dapp-developer risk of losing capital → PPBC, maintain curator
  • exposure to price discovery → capital gain at GNS level
  • front-running → decaying capital gain tax / initialization period
  • capital-constrained indexers → signal renting

My main worry is that adding all these mechanisms makes curation much more complex to reason and use while still being at risk of not solving the base friction. I’d like to hear some feedback about the final form this will take from the curation community. @Slimchance

The principles outlined by Zac under the Ideas section are interesting to consider.

Some thoughts:

  • Bootstrappers pay directly : I was thinking something along this line. We could have some way to inject extra-protocol rewards for indexers from other pools. Curve is doing that, offering LPs some AAVE, Polygon, etc. token rewards on top of what they make from trading fees. Also, Signal Renting in a way provides an avenue to influence indexer attention by paying some incentive to the liquidity provider, particularly good for smaller projects without their own token.

  • Make curation shares sellable: They are currently sellable, but the item under discussion would be if this should work like an AMM with a bonding curve or a seconday market with price discovery working in a different way (auction, etc.). Juan shared a similar idea.

  • All bonding curves are principal-protected: This is tied to the previous item. Some curators were burned from the frontrunning nature of the AMM and that is a strong argument to make it just all principal protected to remove any fear from participating. This will work as long as the curation royalties are a good enough motivator.

1 Like

There seems to be an emerging consensus that this is an idea worth pursuing, though unless someone is making the argument that it MUST be bundled with this proposal, I would prefer that we start a separate thread to discuss, as there is a deep design space here, in particular with respect to the secondary market, order routing, and the upgrade path.

Given how many subgraphs we expect to have and how little liquidity (relatively) we would expect to be in the secondary market, I’m very skeptical of an on-chain auction-based approach. I believe this would run into a form of coincidence of wants problem and have very poor price discovery. As it is, I suspect that any bonding curve-based secondary market would need to have something akin to Uniswap V3 concentrated liquidity to be practical at all.

As you noted, signal renting provides a UX similar to bootstrappers paying directly, but as I noted above if this is seen as a replacement for the Indexer subsidy, we would see the costs of using the network go up, while the quality of service or subgraphs would go down.

1 Like

I have meditated on bonding curves and finally figured out how they may provide benefit. It took an embarrassingly long time.

Even so, there is a lot of truth in the original post that shouldn’t be ignored. The design lacks cohesion.

Sometimes we must plow forward on the best path we can see. But I hope we can revisit this with a more comprehensive design overhaul someday. An ideal design would be self-consistent, understandable, and sustainable. Most importantly, it would incentivize behaviors to affect real-world change.

3 Likes

By way of a long conversation with Brandon I have learned that this design is much better than my original valuation. I feel positively overall about this design as-is.

Thanks @Brandon for taking the time to explain the underlying assumptions and motivations that lead to this GIP.

3 Likes

Any recent update on this topic? Among curators, if I try to capture what is discussed in the Curation Station group, here are the main observations:

Pros (assuming PPBC is effective at both deployment and GNS levels)

  • PPBC would make curation more focused on actual expected query fees VS short term capital gain.
  • PPBC would attract more curators who today fear capital loss.
  • You still need to pay curation tax and transaction fees which lower the risk of eratic behaviour.

Cons

  • Without capital gain and with current 10%, it is less clear if curation will be more profitable than delegation. Curation is a significant effort compare to delegation and even with PPBC you still take the risk to loose an opportunity to earn from your tokens. Therefore, if potential gains on successful curation are not obvious, people may revert to delegation (will also massively benefit from increasing query fees, require minimal effort and with garanteed gains).

For the later concern, should we study the possibility to have the equivalent of indexing/delegating reward for curation. Today, indexing and delegating earn you both query fees and reward paid with inflation. The target being to lower inflationary rewards and rely more and more on query fees alone. Why cannot we align on this strategy for curation as well? Of course, those rewards should also depend on how successfull you are with curation. A really simple implementation would be to apply a multiplying factor on the actual query fees you have earned.

It was also mentioned the possibility to have curation as a follow-up of delegation (you would curate with the token you are first delegating) but it seems a much complex refactor of curation. You would also need to deal with lower quality signals from delegators who signal randomly to try to get a bonus without effort (except if it is also possible to loose rewards with bad signal but “bad signal” may be hard to actually compute).

1 Like

Hey there!

There haven’t been many updates to this thread in particular, since we are exploring other ways of improving curation that would potentially be more attractive than PPBCs (which, as you mentioned, really flatten the revenue streams of curators).

Without going into them, since we are still fleshing them out, I’d like to address a few things from your comment, since they’ve also been discussed internally, and there are reasons as to why why haven’t addressed them:

Creating an equivalent to indexing rewards for curators is something we’ve discussed (basically a bootstrapping mechanism for curation), but it’s hard to really gauge how successful someone is in regards to their curation, which isn’t something that’s required for indexing rewards, as they are not distributed based on how “successful” indexers are.

The distribution of indexing rewards is based on a proportional distribution that originates from curation, basically the more signalled a subgraph is, the more slice of the pie of indexing rewards it gets, and the more incentive indexers have to index that subgraph, to be able to get a piece of the “slice of the pie” that the subgraph has available to distribute.

On the other hand, the curation market doesn’t/wouldn’t have any metric that can be used to properly distribute the pie of rewards assigned to it in the same way that the indexing market does, at least not one that is trivially aligned with the core incentives of the protocol (like the one described above for indexing rewards, where the curation market itself determines which subgraphs get more indexing rewards assigned, ensuring indexers have incentives to index the better or most demanded subgraphs).

That’s not to say that this would be impossible, but it’s extremely complex to come up with another mechanism that won’t produce perverse incentives in the curation market. Which leads me to the second thing:

This would create perverse incentives to spoof query fees in order to (potentially) be able to “mint” GRT with almost no cost.

For example, you could create a really obscure subgraph that only you would be able to sync properly in time, curate it, and then start throwing a lot of query volume to it. If you manage to be the only one indexing it by the time you close your allocations and start collecting the query fees, you would only lose 1% of the GRT as protocol tax, 10% would go to your curator, and then amplified by a certain multiplier, and the rest would go to your indexer.

This does require a certain investment (having enough GRT to run an indexer, knowing how to run the infrastructure, etc), but as long as the extra GRT coming from the multiplier is bigger than 10% (to match the 1% burn), you’d be effectively minting extra GRT. Also considering that, in order for this mechanism to be reasonable able to bootstrap the curation market, you’d have to have a decent multiplier (2x, 3x, or whatever the magic number would be), the incentive to game the mechanism become greater and greater.

This has the side effect of not only creating potential attack vectors, but also making the quality of signal on the curation market go down, as more and more people try to game those rewards.

Regarding this, it is indeed quite a complex system.
Unfortunately it’s really hard to balance the profitability of all participants, but we are working hard on new proposals to target most (if not all) of the problems we’ve been seeing in curation.

Hopefully once we publish those proposals here we’ll be able to transmit more clarity on those points. :pray:

7 Likes

Thank you @juanmardefago for taking the time to provide some news and helping me understand the security gaps I had missed with my proposal. Someone playing multiple roles to trick the system is definitely something to consider! Looking forward to know more about the new mechanisms.

5 Likes