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
- Grants that improve the curator experience : Dashboards, guides.
- Initiatives that directly improve curator revenue.
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:
Parameters
The Reverse Auction parameters are still subject to change. The parameters we are currently looking at looks like this:
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.
- If this number is too low, malicious attacks will not be deterred.
- If this number is too high, developers might find the tax punitive
- We are working with 20%. As can be seen in the example below: Developers that expect other Curators to signal, will quickly “recuperate” the deployment tax.
-
Example numbers:
- A developer self-signals with 10 000 GRT. 8 000 GRT is deposited into the bonding curve, minting 89.4 shares.
- Another curator deposits 2 125 GRT into the bonding curve, increasing the total signal to 10 125GRT.
- At this point, the developer is already “Break Even”, and could sell their shares to retrieve the initial amount of 10 000 GRT.
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%.
-
A high starting tax ensures that front-running bots and low-quality curation will no longer be profitable. Even for highly anticipated subgraphs.
-
A starting tax of 100% is also symbolic: It highlights one of the intentions behind the Reverse Auction: To encourage smart curation, instead of just being the first on the bonding curve.
-
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
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.
- This will leave the remaining Curators in the the red
-
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.
- A less volatile signal increases the predictability in service for consumers
- A less volatile signal benefits indexers: they can better optimize their allocations and tune their infrastructure and cost models. (By extension, this would also benefit delegators)
-
Another example - This one with a subgraph developer signalling on their own subgraph
-
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.
-
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.
-
Malicious developers can take advantage of Curators rushing into bad decisions.
-
With the Reverse Auction, developers pay a 20% developer tax to be guaranteed the first spot on the bonding curve. This increases the risk for malicious developers that are looking to exploit curators.
-
With a Reverse Auction, Curators are allowed more time to assess a subgraph. - They no longer need to be the first to get a sizeable amount of curation shares. This increases the chances of discovering a “malicious developer” before a decision has to be made.
-
-
Developers can deploy a new subgraph instead of upgrading an old one. I explained this “Developer Bait & Switch Attack” in the original post.
-
Developers are economically incentivized to create a new subgraph instead of upgrading an existing one. Each time they do this, they would be able to sell their curation shares at a profit.
-
As with the previous example: With a 20% developer tax for “publish and signal”, developers are encouraged to upgrade their version, instead of publishing a new subgraph.
-
The Reverse Auction would allow more time to assess newly published subgraphs. It would also allow time for the subgraph to be indexed, so Curators can assess the data. If a developer tries to deploy a similar subgraph under a different account, Curators might recognize that the data served is the same.
-
-
- 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.