# Dynamic Curation Tax **URL:** \ **Category:** Research & Development\ **Created:** [July 24, 2021, 7:33pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292 "2021-07-24T19:33:21Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Slimchance](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/slimchance/32/409_2.png) [@Slimchance](https://forum.thegraph.com/u/Slimchance)\ **Post date:** [July 24, 2021, 7:33pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/1 "2021-07-24T19:33:21Z")
With curation launch several challenges have been seen; # **Challenges** - **Frontrunning bots** - Due to the nature of the bonding curve, being the first to curate on a subgraph carries the least amount of risk, while also having a large upside potential. The first curator takes the following risks: - **High volatility** - With the bonding curve starting at “0”, there is a great deal of volatility on subgraph launch. This encourages curator behavior that might be less than ideal; - **Developers switching subgraphs -** This is not a huge issue as of now. However, I think this should be addressed; - Subgraph developers that wish to upgrade their subgraph pays the full 2.5% curation tax on their own shares, and a further 1.25% curation tax for all other curators that have signalled on the same subgraph (and subscribed to the newest version.) With the current system, a subgraph developer can, instead of upgrading, choose to “bait and switch” their curators, and publish an entirely new subgraph. They are economically incentivized to do so: # **Solutions** Several solutions have been proposed. In this thread, I wish to look at two of them, as well as discuss a third one: - [https://forum.thegraph.com/t/batch-gns-transactions/2285](https://forum.thegraph.com/t/batch-gns-transactions/2285). Batch GNS Transactions. This proposal would allow subgraph developers to curate on their own subgraph in the same transaction the subgraph is published. - [https://forum.thegraph.com/t/subgraph-showroom/2202](https://forum.thegraph.com/t/subgraph-showroom/2202) Showroom. I believe the showroom approach does have merit. But I also think it has some significant drawbacks: I think it is worthwhile to fully explore simpler solutions as well. I want to propose another solution; # **Dynamic curation tax.** A simpler solution could be to have a very high curation tax for curators that signal when the subgraph is first published, then reduce the curation tax over time, until it hits the “target” tax of 2.5%. Two examples are provided below. Both the timespan and the starting curation tax are just examples. Example A ![image](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/795db6aafd12cff8dfd07f095a7bbeb146e4bd37.png) Example B ![image](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/0772022479c572b1f62c2a1547fad4f71c211c02.png) A few points on why I think this solution have merit; - **Detering frontrunning bots :** A high curation tax on “block 1” significantly increases the risk for bots that curate indiscriminately. Especially combined with the ability for developers to “Deploy and Curate”. - **Lower volatility:** Due to a higher curation tax around subgraph publication, it is no longer just about being “early”. Instead, this encourages curators to assess each subgraph and to choose the time of entry. - **Higher Quality signal:** With a showroom-type solution, I fear some curators might just “follow the masses”. They would curate with the same amount and “ceiling” as other, successful curators. With a decreasing curation tax, curators are rewarded for analyzing the subgraph, and entering the curve at “the right moment”. - **Less Unknowns:** With a “showroom” approach, (especially one without a “ceiling”), the final outcome would be subject to other curators’ behavior. With this solution, curators would know the exact amount of shares they will receive, before depositing their GRT. - **Trustlessness between developers and curators.** Developers that “publishAndCurate()” are deterred from creating a new subgraph instead of upgrading the previous one. - **Higher commitment.** If developers face a significant tax when initially publishing their subgraph, this sends a powerful signal to curators and indexers alike, that the developers intend to use the subgraph in production. - **Less complex than a showroom solution.** Compared to implementing a showroom, I believe this solution is both easier to understand, as well as much easier to code. I also think there are some drawbacks to this approach: - Compared to keeping the protocol as-is, this introduces complexity - A high tax might feel punitive to new curators. **Variant** Edit: A variant of this solution would be to have a separate curation tax for developers that publish and curate in one transaction: - The protocol can settle on a developer tax that is just high enough to discourage “bait and switch” attacks. - With the initial deploy and curate transaction being exempt from the “Dynamic Curation Tax”, it would be possible to set the initial curation tax even higher. (To further discourage curators from signaling without doing their due diligence.) - The main drawback to this variant would be the added complexity. - An example would be **Feedback** I encourage community members to publish feedback to this approach below. - Do you think this approach can help solve the challenges our community is facing? - What are some of the drawbacks you see with this approach? - If you think this approach is worth exploring, what parameters wold make sense, and why? (Starting curation tax, number of days to reach “target tax” etc.? ) Note : This idea has been further refined. See the post called [Reverse Auction (Dynamic Curation Tax V2)](https://forum.thegraph.com/t/dynamic-curation-tax/2292/15) later in this thread. ---
**Author:** ![TheBondsmith](https://avatars.discourse-cdn.com/v4/letter/t/ecae2f/32.png) [@TheBondsmith](https://forum.thegraph.com/u/TheBondsmith)\ **Post date:** [July 24, 2021, 8:25pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/2 "2021-07-24T20:25:35Z")
Hey Slim 👋🏽 I think that modifying the curation tax is the way to go, combined with “Deploy and Signal” or “Batch GNS transactions” The showroom is a great idea but adding complexity to an already complex system is not necessarily a good thing. Also, making things more difficult for developers in anyway is less than ideal. I wonder, instead of a curation tax upon depositing or in addition to a deposit curation tax, would it not also make sense to tax upon un-signaling in this dynamic way that you have proposed? My understanding is that we want quality subgraphs to have a decent amount of signal quickly so that indexers can begin to sync. Would a heavy tax on early signal then deter curators from signaling at all and thus extend the sync time because indexers are waiting for ore signal? And if the sync time is extended then developers must wait longer for their subgraph to do the job it needs to do. Is the tax necessary? It is possible deploy and signal could defeat the bots on it’s own, which keeps the protocol simpler. To summarize my views: **Adding in a dynamic tax complicates an already complicated system.** **A tax on early signal could delay the sync process** **Perhaps we should look at a dynamic tax upon un-signal** **Deploy and signal may be enough of a fix** ---
**Author:** ![lane89](https://avatars.discourse-cdn.com/v4/letter/l/5f9b8f/32.png) [@lane89](https://forum.thegraph.com/u/lane89)\ **Post date:** [July 24, 2021, 8:43pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/3 "2021-07-24T20:43:49Z")
> [@TheBondsmith](#): > > Deploy and signal may be enough of a fix While I would hate to make changes and then see that the changes were not enough, I think this would be enough to allow bot baits to ruin the bots. It would change the bots from losing 75 GRT to losing that + a large chunk of their stacks and would incentivize the individual to go after bots (and maybe those that blindly signal). Seems like a quick fix, which might be what is needed or could lead to other problems down the line. My first issue that I don’t see resolved is that if the bots can withstand the bot baits and then they are still 2nd into a major subgraph and still first to unsignal. ---
**Author:** ![TumTum](https://avatars.discourse-cdn.com/v4/letter/t/71c47a/32.png) [@TumTum](https://forum.thegraph.com/u/TumTum)\ **Post date:** [July 25, 2021, 6:20am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/4 "2021-07-25T06:20:00Z")
Great thoughts Slim and Bondsmith! I think the deploy and signal is also a great idea but, I am concerned it won’t be enough. I think it could be valuable for someone to look into a dynamic un-signal tax similar to the proposals Slim made for a dynamic curation tax. My 2 cents on a possible dynamic un-signal tax. 1. This would dis-incentivize poor signaling because the curator’s GRT would be locked up longer or they would have to take a larger immediate loss. 2. This would incentivize longer-term curating and hopefully provide better signals where the cost of new shares would roughly equal the future value of discounted cash flows. 3. It would not reduce the initial speed of (quality) curation like the dynamic curation tax might. ---
**Author:** ![Josh-StreamingFast](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/josh-streamingfast/32/628_2.png) [@Josh-StreamingFast](https://forum.thegraph.com/u/Josh-StreamingFast)\ **Post date:** [July 26, 2021, 8:00pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/5 "2021-07-26T20:00:49Z")
While I like the underlying idea of what you are proposing, it’s hard to get deeper into the proposal without having some specific metrics for target tax, time to reach target, and starting tax. Would need some modelling to be run. But one of my main drawbacks is that I think this will just create a new math problem to be optimized: at which point is most optimal to enter the curation curve. Which just means that those can best work through the maths will have a leg up versus everyone else, rather than solving for the problem at hand. While every solution has tradeoffs, I am leaning more towards trying to ensure that whatever the solution may be, that those with a better grasp on the maths, or better able to code a bot, won’t be advantaged (I know this may be pie in the sky thinking, but that’s where my head’s at currently). There is definitely merit to this approach though, I just need to sit with it some more to better opine. ---
**Author:** ![graphgod1](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/graphgod1/32/576_2.png) [@graphgod1](https://forum.thegraph.com/u/graphgod1)\ **Post date:** [July 27, 2021, 10:03am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/6 "2021-07-27T10:03:00Z")
I like this idea. Well done! ---
**Author:** ![Ahmad\_Mardeni](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/ahmad_mardeni/32/803_2.png) [@Ahmad\_Mardeni](https://forum.thegraph.com/u/Ahmad_Mardeni)\ **Post date:** [July 27, 2021, 10:22am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/7 "2021-07-27T10:22:54Z")
I totally agree with TheBondsmith, charging on un-signaling is a great solution and will give us higher rewards during our curation and before we un-signal. ---
**Author:** ![Topher66](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/topher66/32/639_2.png) [@Topher66](https://forum.thegraph.com/u/Topher66)\ **Post date:** [July 27, 2021, 10:35am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/8 "2021-07-27T10:35:04Z")
Batching the signal and deploy txns is vital. That one change would make a significant proportional change to the bot’s impact. As is often the case, simple solutions are best implemented first. ---
**Author:** ![adamfuller](https://avatars.discourse-cdn.com/v4/letter/a/8e8cbc/32.png) [@adamfuller](https://forum.thegraph.com/u/adamfuller)\ **Post date:** [August 4, 2021, 10:59am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/9 "2021-08-04T10:59:21Z")
I have reservations about this proposal as it introduces more complexity into an already complicated & still nascent system. In general I am also opposed to anything that introduces higher costs & complexity for subgraph developers, without unambiguous net benefit. ---
**Author:** ![Brandon](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/brandon/32/1265_2.png) [@Brandon](https://forum.thegraph.com/u/Brandon)\ **Post date:** [August 7, 2021, 12:41am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/10 "2021-08-07T00:41:36Z")
Great ideas in here, thanks for kicking off this discussion @Slimchance! > [@TheBondsmith](#): > > Perhaps we should look at a dynamic tax upon un-signal A downside of an tax based on unsignal is that it penalizes Curators that signal for longer, because they will have accumulated more Curator royalties in the bonding curve that will will be subsequently taxed. > [@adamfuller](#): > > In general I am also opposed to anything that introduces higher costs & complexity for subgraph developers, without unambiguous net benefit. I generally agree with Adam that this proposal in its current form imposes too many additional costs to get its intended benefit. It feels like a blunt instrument. A variant on this idea, however, that we’re researching at E&N is a **decaying capital gains tax**. For example, the protocol could tax capital gains earned over a period of a block at ~100% and capital gains earned over a year at ~0%. This would virtually eliminate any profit opportunities from front-running/ sandwich attacks, and would instead reward Curators whose shares appreciate in price over a longer period of time. The major downside of the above approach is that Curator shares lose some fungibility (brings them closer to UTXOs), and there would be additional bookkeeping required to track the cost-basis of curation shares in order to levy the capital gains tax. My working assumption has been that we wouldn’t be able to do something like this until The Graph migrates parts of its protocol logic to an L2, but it could be worth prototyping sooner to check that assumption. ---
**Author:** ![DataNexus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/datanexus/32/1830_2.png) [@DataNexus](https://forum.thegraph.com/u/DataNexus)\ **Post date:** [August 7, 2021, 2:07am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/11 "2021-08-07T02:07:00Z")
A small group of curators have been discussing a potential solution to this and hope to have it refined a bit more. But we’re excited to present it to the community! ---
**Author:** ![Slimchance](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/slimchance/32/409_2.png) [@Slimchance](https://forum.thegraph.com/u/Slimchance)\ **Post date:** [August 7, 2021, 10:05am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/13 "2021-08-07T10:05:10Z")
Thanks for your reply Brandon. Regarding **decaying capital gains tax** - I’d love more details on how a decaying capital gains tax would work. I assume it would calculate capital gains as (GRT received from burning curation shares - GRT deposited into the bonding curve), and then tax this amount depending on how long the signal has stayed in the bonding curve. - I don’t think this will prevent front-running bots and low quality signal from curators that tries to be first on the bonding curve. The first curator on the bonding curve would still carry the least amount of risk, while also having a large potential upside: - Another potential issue with a decaying capital gains tax, is that it rewards staying in the bonding curve for a larger amount of time. The curation markets should not just reflect the current queries. Curators should also be incentivized to act as predictors for future query volume, so indexers can allocate resources and optimize infrastructure and cost models accordingly. ---
**Author:** ![jona](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/jona/32/1283_2.png) [@jona](https://forum.thegraph.com/u/jona)\ **Post date:** [August 8, 2021, 6:29pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/14 "2021-08-08T18:29:04Z")
Thanks for digging into this 🙂 Hearing from the E&D team is super helpful. I think Capital Gains Tax would solve the issue of front running but would also cause unwanted side effects that would affect the goals and experience of curation. 1. At the heart of curation is the ability to adjust to market changes at a moments notice. Curators have their ears to the ground as they monitor: - New subgraph entrance - Deprecation of subgraphs - Updates to data being stored in a subgraph - Events that could lead to increase/decrease in query traffic Being able to adjust signal based on these factors would not be possible if they are disincentivized to do so. 1. Curators would be incentivized to keep signal on a subgraph that might not be balanced to the amount of query traffic coming in. Indexers would then be mislead to think that the subgraph should have more resources allocated to it. As DataNexus mentioned, we’ve been working on an idea and hope to share with the community soon and would love to get your feedback on it 🙂 ---
**Author:** ![Slimchance](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/slimchance/32/409_2.png) [@Slimchance](https://forum.thegraph.com/u/Slimchance)\ **Post date:** [August 12, 2021, 6:50pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/15 "2021-08-12T18:50:28Z")
# **Reverse Auction** **(Dynamic Curation Tax v2)** Working with @chK8r42z @Datanexus @graphgod1 @Cole@JamesTheBondsmith @jona and @Oliver we have further refined the idea. We have renamed the idea to “Reverse Auction”, as this is closer to what we are trying to achieve. In a reverse auction, the price starts very high and decreases over time. This allows the market to assess the “fair value” of curation shares on a specific subgraph. As we can see in the examples toward the end of this post, this would also ensure a fairer distribution of curation shares. The Dynamic Curation Tax is used to facilitate this Reverse Auction. In this post we will look at: - Challenges with the Reverse Auction , and how we propose to solve them - Parameters for the Reverse Auction, and why they were chosen - Example numbers, showing how the Reverse Auction might mitigate the 3 curation pain points explained in the original post. # Challenges **Challenge:** The Reverse Auction might increase the profit of Curators that are good at assessing subgraphs. However, the very first Curators might receive less shares, which can feel punitive: **Solution:** Curation Fund - The Reverse Auction is there to ensure a fairer distribution of curation shares, and to encourage Curators to assess a subgraph before curating on it. - There is no need to burn the GRT that is collected in the process. Thus, we suggest that any tax over the baseline (2.5%) is not burned, but rather deposited into a curator fund. - This fund will be governed by The Graph Foundation. The Foundation will be directed by Curators using snapshot voting. Over time, we might see this fund evolve to be governed by a Curator DAO - The fund might be used for **Challenge:** Increased complexity for Curators **Solution:** Make sure all critical information is readily available in the UI. - Current Reverse Auction Fee - “Break Even Signal” When the total signal on a subgraph reaches this value, the Curator will be able to burn their shares to retrieve the same amount of GRT they put into the protocol. If the total signal increases above this amount, the curator will be able to sell their shares at a profit. - Showing these two numbers in the UI, would allow Curators to make a decision on whether they should signal or not. If the total signal increases above the “Break Even Signal”, they will be able to sell their shares at a profit. An example of how this might look: ![Wonderful2](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/540541f16353d58bb6508cd2e467729d1485384b.png) # Parameters The Reverse Auction parameters are still subject to change. The parameters we are currently looking at looks like this: ![Screenshot 2021-08-11 011938](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/11a3397d0139955682de422f889de5579f7973d0.png) **Subgraph deployment tax** (20%) - This tax is incurred when developers “publish and signal”. Developers are allowed the first spot on the bonding curve. The tax acts as a deterrent to malicious attacks by developers. E.g “Bait and switch” explained in the original post. - Example numbers: ![Screenshot 2021-08-10 144240](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/optimized/1X/39e1f44b1883b01f561ca872684bd4a99d69b58a_2_690x41.png) **Starting tax (100%)** - When a subgraph is published, the Reverse Auction will start. The dynamic curation tax starts at 100%. It will then linearly decrease over time, until it hits 2.5%. **Reverse Auction time period (10 days)** - The Dynamic Curation Tax will decrease linearly, block by block, until it hits 0. The current suggestion is that the tax will decrease by ~10% each day, allowing it to hit the target tax after 10 days. - A longer time period gives Curators more time to assess the subgraphs. - A longer time period allows the subgraph some time to index. This allows Curators to assess the data provided by the subgraph. - If the time period is too long, network participants might not know what the curation market deems to be a “fair signal” until towards the end of the Reverse Auction period. - Looking at the numbers, the “sweet spot” for early Curators that expect the signal to increase might still be just a few days after the subgraph is published. See the examples later in this post. **Curve (Linear)** - The Dynamic Curation Tax will decrease linearly. - A linear curve was chosen, as it would be easy for Curators to understand and predict the tax. # Examples Let's first look at this example ![Comparison](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/4581f91196ae3dd0fb4bdba4ed536f47f8131861.png) Let us see how this affects the first two pain points. - **Front-running bots and low quality signal.** - With the current system, the first Curators carry the least amount of risk while also having the highest potential returns. Notice how the early Curators hold a vast majority of all curation shares. - In a Reverse Auction, the Dynamic Curation Tax starts very high, and then decreases over time. In the example with a Reverse Auction, being first is no longer a huge advantage: the first 5 Curators all receive the same amount of curation shares. - When comparing the two, we see that only curator 1 and curator 2 hold a larger amount of shares with the current system. The following 8 Curators all hold more shares after the Reverse Auction, even though some of the Curators paid a higher fee. - **High volatility** - With the current system, the first couple Curators hold a majority of all curation shares. If they choose to sell their curation shares, the signal will shift dramatically. - In the example with Reverse Auction, the curation shares are more evenly distributed. Even if a couple Curators sell their shares, the GRT valuation of the remaining shares will not decrease as much. Another example - This one with a subgraph developer signalling on their own subgraph ![ReverseAuction&SelfSignal](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/58d17f4381ee7842b84233c713cd14d5fd431921.png) - **Malicious Developers** - A malicious developer can publish a subgraph they don’t intend for anyone to query. With “Batch GNS Transactions” they will be guaranteed the first spot on the bonding curve. - Developers can deploy a new subgraph instead of upgrading an old one. I explained this “Developer Bait & Switch Attack” in the original post. - Note: In the example with Reverse Auction + developer self-signal, we see that “Curator 1” gets fewer shares than subsequent Curators. This highlights how a Reverse Auction benefits Curators that are able to correctly assess a subgraph, instead of those racing to be the first on the bonding curve. ---
**Author:** ![Daplabs-Jamez](https://avatars.discourse-cdn.com/v4/letter/d/4af34b/32.png) [@Daplabs-Jamez](https://forum.thegraph.com/u/Daplabs-Jamez)\ **Post date:** [August 12, 2021, 9:56pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/16 "2021-08-12T21:56:12Z")
I fully support this refined proposal. Does a great job of taking away incentive in just hopping in & out subgraphs. ---
**Author:** ![DataNexus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/datanexus/32/1830_2.png) [@DataNexus](https://forum.thegraph.com/u/DataNexus)\ **Post date:** [August 13, 2021, 12:17am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/17 "2021-08-13T00:17:50Z")
It is probably no surprise, but I am very in favor of this system. An additional point that is not touched on is this system also prevents the anxiety of being the first to signal. From what I’ve seen most curators have jobs outside their role as a curator or are students. Keeping this leg of the network open to the ‘average but enthusiastic joe’ keeps the scale of participation in play (delegator \> curator \> indexer). ---
**Author:** ![Ohmyjog](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/ohmyjog/32/937_2.png) [@Ohmyjog](https://forum.thegraph.com/u/Ohmyjog)\ **Post date:** [August 13, 2021, 1:22am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/18 "2021-08-13T01:22:03Z")
**I hate to sound like a broken record here, but I still firmly believe that the Continuous Organization smart contract provides a solution to every issue we’ve encountered since the beginning of Curation.** > **[GitHub - C-ORG/whitepaper: The Whitepaper of Continuous Organisations](https://github.com/C-ORG/whitepaper#dat)** > > The Whitepaper of Continuous Organisations. Contribute to C-ORG/whitepaper development by creating an account on GitHub. **Protection from front-running via a Minimum Funding Goal (time based, not GRT quantity based) :** ![MFG](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/53901e8eb42a1358fb51a2d79a74e2861378569d.jpeg) \*\*Security while participating in the MFG: ![MFG2](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/31cc281009ba7429b39597b6ecf9df31f5fa8224.jpeg) \*\* **Additional, optional protections:** ![FR](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/1dc6cc5a415a45dbf0987ca9b6e16130668e12f6.png) **Volatility mitigated by pre-minted shares:** ![MINT](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/e5bbe63bf3cc95d1a3b733fd84106372059b0e7a.jpeg) Subgraph Deployer incentive for Curators: ![BURN](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/b979876fa86a6c012fc314966389c2e911675386.jpeg) ![INCENTIVE](https://us1.discourse-cdn.com/flex020/uploads/thegraph1/original/1X/550fc75ca124855dded500a28336ffa87a623d4b.png) **Here is how this looks in my eyes, as a Curator:** Example 1: Legitimate Subgraph deployer (UNISWAP) w/ or without front-running bots - UNISWAP official subgraph deployed - UNISWAP pre-mints 100 Curation Shares, with the intention of burning them. This burn would increase the future value of that subgraph’s shares & promote long-term signals from current Curators while also helping to attract future Curators. A larger upfront investment from a project would quickly gain attention from Curators, as the Subgraph is more likely to be legitimate. - Along with the pre-minted shares, UNISWAP opts to offer a 7-day Minimum Funding Goal (Should be mandatory minumum of 3 days, IMO) period, where all shares of the subgraph cost the same price. The impact of front-running bots will be nearly eliminated, as the “bonding curve” would not be go into effect until after the 7-day period. Once the bonding curve is active, a bot’s unsignalling would not cause massive volatility as it does now. If it did, however, this is when the subgraph deployer could choose to burn some of their pre-minted shares to help make up any losses incurred by non-malicious Curators. **Exmaple 2: Illegitimate Subgraph deployer (UNIFLOP) w/ or without front-running bots** - UNIFLOP deploys subgraph with no pre-minted shares (hint #1) - UNIFLOP opts for a 3-day Minimum Funding Goal Period (hint #2) - Eager curators & bots “ape in” to the Subgraph, only to find out 24 hours after deployment that the Subgraph is illegitimate. All human Curators unsignal, receiving a refund for their full initial investment amount (less current 2.5% burn or re-allocation as discussed above & gas costs) - UNIFLOP cannot close the Minimum Funding Goal period prior to the end of the 3-day period, without first paying back the GRT signaled to it by all Curators. If bots do not unsignal prior to the end of the MFG, the malicious subgraph deployer essentially “rugs” the bots & we have the perfect outcome of wrong-doers being done wrong by other wrong-doers. I have said it before, and I will gladly say it again - I am not technologically inclined. I just believe in doing what is right, and I want to see every facet of The Graph be sustainable and prosperous for all users. Thanks for reading 🍻 👨🏻‍🚀 ---
**Author:** ![Slimchance](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/slimchance/32/409_2.png) [@Slimchance](https://forum.thegraph.com/u/Slimchance)\ **Post date:** [August 13, 2021, 4:24am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/19 "2021-08-13T04:24:52Z")
Thanks for replying. Continous Organisations are interesting. However, most of the whitepaper is not applicable to The Graph: > A _Continuous Organization_ is an organization type that issues _securities_ through a _Continuous Securities Offering_ by funneling part or all of its realized revenues to a specific type of smart-contract called a _Decentralized Autonomous Trust_" Let us break down some of the features of Continuous Organizations: - Different Buy Price Function and Sell Price Function - Initialization period with a flat price. Edit: Let’s try to keep this thread about the pros and cons of Reverse Auction / Dynamic Curation Tax. If you’d like to dive deeper into Continuous Organizations, lets discuss it in the [Thread about Continuous Organizations](https://forum.thegraph.com/t/deploy-continuous-organization-system-to-curation/2302). ---
**Author:** ![Dalesey](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/dalesey/32/1460_2.png) [@Dalesey](https://forum.thegraph.com/u/Dalesey)\ **Post date:** [August 13, 2021, 11:32am UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/20 "2021-08-13T11:32:33Z")
I support this proposal. I think any change will come with trade-offs. Yes it will reduce the gains if you manage to signal very early, however the pros far outweigh the cons. It smooths things out, and helps to steer curators into thinking of the bigger picture, rather than in it to make a quick multiple before rugging everyone else afterwards (and helps sort out them pesky bots) If uniswap launches tomorrow, it will damage a lot more people than it will benefit within the first couple of days. This taxation gives calm to the whole process where us as curators can do our job as we were supposed to without feeling rushed, and thus potentially making costly errors. The system we currently have pushes curators into feeling like they have to ape in without verifying the subgraph first. I believe with the proposed system it will still be lucrative as when there are thousands of subgraphs, even after 10 days of launch, many will still be under the radar and if we do our research properly, we can find gems and get in very early and do well out of it. Uniswap is like Apple, everyone knows what it is, our job as curators has to go further than that and look at what the future is. There will be subgraphs deployed with very little signal and attention that could be the next uniswap. There’s still a lot of value in the proposed system, it just balances things more and makes it fairer for everyone that wants to contribute with less risk ---
**Author:** ![Ohmyjog](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/ohmyjog/32/937_2.png) [@Ohmyjog](https://forum.thegraph.com/u/Ohmyjog)\ **Post date:** [August 13, 2021, 12:40pm UTC](https://forum.thegraph.com/t/dynamic-curation-tax/2292/21 "2021-08-13T12:40:05Z")
Thank you for the response. In regards to the original post, would it make more sense for the tax rates from the Deploy & Signal and Reverse Auction to be the same? The higher tax rate of 90% (10,000 GRT = 31.6 shares) only applying to day 1 Curators, but is guaranteed to a Deployer who only incurs a 20% tax (10,000 GRT = 89.4 shares). What would Curator #2 signalling on day 1 look like in the Deploy & Signal example shown above (10,000 GRT, day 3)? Is this individual/bot subject to the 90% tax? Some smaller Subgraphs need early attention from Curators/Indexers, and I see this tax as something that might discourage early signals - regardless of a Subgraph being legitimate or not. Additionally, is there any concern that this will simply have front-runners waiting for Day 10+ to signal? Could you help me to understand what this scenario would look like: - DEPLOYER - 10,000 GRT w/ 20% tax (89.4 shares) - CURATOR #1, DAY 1 - 10,000 GRT w/ 90% tax? ( ? shares) - CURATOR #3 - 🤖, DAY 10 - 10,000 GRT w/ 2.5% tax - CURATOR #4 - 🐳, Day 11 - $50,000 GRT w/ 2.5% tax A malicious deployer would be given a huge, immediate financial advantage over the #1 Curator based on the amount of shares received relative to their initial investments. [Next page](https://forum.thegraph.com/t/dynamic-curation-tax/2292.md?page=2)