What if we replace the bonding curve with what I would call a timed-released curve.
If you signal 1k, that’s the share you get. The longer you leave it in, the more that share increases.
So curators that signal early get a higher rate of increase as it compounds. As the subgraph matures, the rate of compounding decreases for those that signal after but doesn’t decrease for those that are already signaling. Basically it locks that rate once you signal. This would keep the incentive of wanting to signal early to get the better rate but the maturity of that rate would happen right away.
This would incentivize curators to think long term and signal subgraphs that will last(causing curators to do more research before signaling).
I think it would also disincentivize over signaling since the more mature the subgraph got, they less incentive in signaling.
You could possibly even tie it to the allocation an indexer has given it so that if allocation was high it might mean there’s high demand therefore more signal could be warranted and so the curve would slightly increase to incentivize more curation.
Each curator’s addition to the subgraph would not directly affect other curators, basically sandboxing the experience for each curator, disincentivizing bots and bad actors from rug pulls.
Questions posed to me:
| How do you think this will effect the relationship between signal and query fee’s?
Bottom line is query fees are king. The share value is only relevant in the context of curating. The moment the curator want to exit they would take their original 1k + any query fees they received based on the share value. The share value is based on: - when they started to signal - the amount they signaled - the total amount of signal on the subgraph As more people begin to signal existing curators share value goes up but they also have to share the query fees. A curator the signals later has to put more GRT upfront in order to match the first curator’s shares. Mutual interests with a separation in value.
——————————
| Would this make it possible to farm APY on a subgraph without it ever getting query’s?
In this scenario no but maybe there’s a way to accommodate for that idea if it creates value for the long term vision of the ecosystem.
———————
Because this model relies heavily on query fees two things should be considered:
-
Long term - fees need to be lucrative enough for curators to stick around and offset any expenses incurred during the process
-
Short term - the Hosted service becomes a crutch that teams can continue to use for the foreseeable future. One idea could be to create a grants program that provides initial GRT funds to teams that migrate over to the mainnet. If we are here to make The Graph ecosystem grow into a force that truly enables and empowers teams into a Web3 world then we should invest in that future by providing some stepping stones out of a centralized system. Probably lots to consider here as I’m sure there are complexities that I might be aware of.
It would be a considerable shift in what it is now so not sure how feasible it would be but maybe there’s some ideas here that could be cherry picked or polished to be better suited for where the system is now. Just some of my thoughts at early morning cause I couldn’t sleep and stop thinking about it lol.
Would love to hear opinions, thoughts, things I didn’t think about or know about.