-
Remember that the tax starts at 100% when the subgraph is deployed. So the tax could not be the same, as developers would then get 0 shares.
-
A very high developer tax (90%+) would feel punitive for developers that are looking to migrate or deploy their subgraph to the decentralized network. If a developer is told they need to buy 100 000 GRT in order to secure a signal of 10 000 GRT on their subgraph, I believe many projects would stop using The Graph. This does not benefit anyone
- Developers would also be encouraged to find “smart” ways to avoid this tax. (Deploy 20 identical subgraph, but don’t tell the community which your are going to use before you signal on it 10 days later). etc.
-
With Batch GNS Transactions subgraph developers will be guaranteed the first spot on the bonding curve. I agree that this opens the protocol to malicious subgraph developers. This is one of the challenges we are adressing with the Reverse Auction:
-
Higher risk - With the current system, a malicious developer only risk the 2.5% curation tax. With Reverse Auction, they risk 20%.
-
With the current system, the highest potential rewards are found early on the bonding curve. Therefore, whenever new subgraphs are published, Curators make split-second decisions on whether or not to curate the subgraph. With a Reverse Auction, Curators are allowed more time to assess a subgraph. - They no longer need to be the first Curators on the bonding curve to get a sizeable amount of curation shares. This increases the chances of discovering a “malicious developer” before a decision has to be made.
-
- Frontrunning “Day 10” would not make any sense, as the tax is linearly decreasing, block by block.
Feel free to hit me up in Discord, and we can dive deeper into the numbers if you’d like 