Publisher/Developer Incentives

A subgraph developer brought up an issue on twitter relating developer incentives vs developer costs.

If a portion of query fees generated by a subgraph were routed to a publisher, this could incentivize migration. Larger projects who have developed their own subgraphs would stand to have an additional revenue source by migrating 3rd party consumers to their mainnet subgraph.

For freelance subgraph developers, this offers a way to cover the cost of upgrades/tax and potentially build residual income streams (assuming the subgraph will see sufficient query traffic).

Well … isnt publisher already minting the cheapest share of curation ? You mean this isnt enough ?

If they have also taken the time to learn about curation, yes this is true. From my experience in talking to developers, this is an area that most are initially confused about.

The problem that I have with this is in order to realize any type of profit on the subgraphs I have published, I have to reduce the signal on my subgraphs and which in turn drops it’s support level.

A developer fee cut is something that would be very simple to understand. Our protocol has a lot of moving parts, the more aspects we can keep simple the better.

It doesn’t feel right, if a developper never update his subgraph and doesn’t self signal, how would you justify a developper cut ?

If the subgraph is consistently queried then the value they provided has a residual value to the protocol (and thus all stake holders).

If the developer does not maintain the subgraph when it’s needed, then it opens the door for another developer to iterate an improved version and capture the query traffic.

Idea: Take the subgraph deployment tax and put it straight into the curation bonding curve. But, do not allow the tax to be removed from the curve.

In this way the developer gets some “free” curation shares.

2 Likes