Proposal to Reduce Curation Tax

It’s been discussed among Indexer and Subgraph Developers that perhaps the cost of the curation tax is too onerous, particularly in instances where the subgraph needs to be upgraded multiple times due to bugs in the subgraph or due to the subgraph being under active development.

I’ve written a proposal to reduce the curation tax to 1% from it’s current value of 2.5%.

You can find the proposal on the Radicle GIPS repo under zerim/reduce-curation-tax or for convenience read a copy of the proposal here.

As this touches on some core economic parameters, I look forward to hearing community input from a number of stakeholder groups on the proposed change.

5 Likes

Brandon, I like this proposal. Just to clarify this would change the developer’s side of the tax to 0.5% and the curators migrate tax to 0.5%, correct?

I’m in agreement with the GIP to reduce the curation tax

Thinking out loud here: This point stood out to me,

The attacker earns indexing rewards on the subgraph up until indexing rewards are disabled on the subgraph. Even though allocations are measured in epochs, indexing rewards accumulate continuously on a per block basis. Thus the revenue from an attack is determined by the number of blocks until a Subgraph Oracle detects the unavailable subgraph and disables indexing rewards.

Has changing the per-block rate to a per-epoch rate been considered? Why or why not is that a possible solution?

Secondly.
I also am struggling to see the direct tie in to lowering the curation tax rate. While I have looked through the maths, and understand the point that is being made, I still don’t see how it ties back directly to a “need” to lower the curation tax rate. You mentioned how this attack vector was one constraint from holding back the lowering of it, but that implies that it should be lowered.

As you wrote in the post “in instances where the subgraph needs to be upgraded multiple times due to bugs in the subgraph or due to the subgraph being under active development.”. In my mental model of a role of a Curator, these two things are paramountly their “responsibility” (for lack of a better term). They should be curating which subgraphs do/do not have bugs, and are suitable for production use (versus needing frequent updates).

I may be missing some context, or perhaps something isn’t “clicking” for me as of yet, and I would love to be pointed in that direction.

1 Like

Wouldn’t slashing a curator when they remove signal/ unsignal work better if you’re trying to mitigate Subgraph Witholding Attack? You could decide if the curator has actually attacked the network and slash them with a penalty at that time (when they withdraw). It would also motivate Curators to look more deeply into what they’re signaling on. Just an idea.