CIP-27: Incentives mechanism for the Price Estimation Competition

Governance Closed Proposals
,
1

Summary

Price estimation is currently a key component of the protocol. This proposal aims to set up a rewards mechanism in order to incentive all solvers participating in the solver competition to become estimators in the price estimation competition.

Introduction

As outlined in this (Towards a stronger price estimation competition) post, price estimation is integral for the success of the protocol. Establishing a robust, consistent and competitive quoting mechanism will lead to more accurate quotes for the users, much better fee estimation and will eventually minimize the percent of expired orders (i.e., orders that got a quote but solvers were not able to realize it). This will, ultimately, lead to increased traffic in the protocol.

Currently, only a subset of the solvers participating in the solver competition do price estimation. Concretely, only Gnosis solvers and SeaSolver are participating in the price estimation competition. Many Gnosis solvers solely rely on external APIs (such as 1inch, 0x), and from time to time these solvers get rate-limited, thus resulting in suboptimal performance. Due to this, significant dependency on external APIs poses a non-trivial risk to the protocol, and we believe that by encouraging multiple solvers to participate in the price estimation competition would mitigate this and would result in very consistent good quoting. Moreover, the solver competition is already in an advanced stage, where solvers have evolved a lot and are quite sophisticated, and able in many cases to outperform external APIs. For all these reasons, we believe it is crucial to make the price estimation competition stronger by having solvers participate in it.

Mechanism

We propose the following mechanism. We start by noting that the number of orders getting settled onchain per month is between 30k and 35k for the last few months. To simplify the analysis below, we will assume throughout that we have 35k orders being settled onchain, on average, every month.

To incentivize solver participation in the price estimation competition, we propose to reallocate 15% 20% of the COW rewards, currently allocated for the solver competition and intended to be distributed as consistency rewards. As a reminder, there is a total of 20M COW tokens allocated for solver rewards over a year, which corresponds to an average weekly budget of 383307 COW for solver rewards, of which 25%, or 95826 COW, is intended to be used for consistency rewards, as specified by CIP-20.

Here, we propose to reallocate 15% 20% of the COW rewards budget, equal to 4M COW over a year, or ~77,000 COW per week, to the price estimation competition. The rationale behind this is that:

  • as explained above, we believe that price estimation is crucial for the success of the protocol. A very competitive and reliable quoting system is the first step towards increasing order flow, allowing the protocol to always quote the best possible prices to users, along with competitive fees.
  • Based on the fact that for many weeks, significantly more than 25% of the COW rewards given are consistency rewards, we expect that the reduction of the total budget for solver rewards will not eliminate consistency rewards, which are very important as they ensure robustness of our batch auction mechanism. On top of that, the protocol has made significant steps in the last few months to minimize solvers’ costs, especially with the introduction of MEV Blocker, and the hope is that this budget reduction will not negatively affect the development and well-being of the solvers participating in the solver competition.

Given the weekly budget of 77,00 COW for price estimation, we propose the following distribution mechanism:

  1. Every market order being placed in the orderbook is associated with a quote, that is the winning quote of the corresponding price estimation competition that took place. We link each order with the solver that gave this winning quote. We stress here that for a quote to be eligible for participating in the price estimation competition, full calldata must be provided which should be able to successfully simulate.
  2. For every market order that a solver provided a winning quote for, we track whether it got successfully executed onchain or whether it expired and in the case where the order got successfully executed onchain, the solver that provided the winning quote gets a reward of 9 COW. If the order expired without getting executed, the solver gets a (negative) reward of -Y COW.

On the first day of each month, the rewards for each solver are aggregated and the protocol transfers out the COW rewards in the rewards address already specified by the solver where the COW rewards are currently being sent.

Note: We stress that the majority of quotes do not lead to order creation. We view this as something positive, as price estimators would have to be consistent and provide quotes for most of the requests in order to get rewarded, as one cannot know in advance if a certain request will lead to an order being placed in the orderbook.

Sanity checks

Since we have assumed a total of 35k orders being executed onchain per month, it is clear that on average the protocol would spend 35k * 9 * (7/30) = 73,500 COW per week. Thus, the rewards proposed above fall within this budget and can also accommodate an increase in the number of orders being executed.

Regarding how much a solver will actually be gaining, a solver that ends up getting 10% of the rewards would earn 7,350 COW per week, or 31,500 COW per month. With the current COW price, this would be around 2200 USDC per month. We believe this should be enough to cover infrastructure costs. More importantly, we believe that solvers that will engage in price estimation will, as a byproduct, become much faster, reliable and competitive for the solver competition as well, thus gaining significant edge, which should also result in more rewards in the solver competition.

2 Likes
2

Great proposal! How would we handle the fact that we currently require two separate price estimates in order to generate a quote:

  1. Estimate how much buy token we can get
  2. Estimate how much sell token we need to buy 1 ETH (used to compute how much sellToken the protocol needs to withhold as a fee to reimburse the gas cost)

While the second has better caching mechanisms in place and therefore produces less load overall, it is currently I believe more brittle since only few aggregators support buy orders. Therefore ideally we’d find a mechanism that incentivises both types of quotes. We could combine the two estimates into a single one, but I believe the backend team had some concerns around that (cc @MartinquaXD, @nlordell).

1 Like
3

Good point. For me, providing a quote consists of the following.

Sell market order:
The user inputs an amount Z of the sell token, and the estimator provides an amount Z’, which indicates how much of the buy token one can get by selling Z of the sell token. Fees and/or gas are not taken into account, but instead the estimator provides calldata and the gas units needed to convert Z of the sell token to Z’ of the buy token

Buy market order:
The user inputs an amount Z of the buy token, and the estimator provides an amount Z’, which indicates how much of the sell token needs to be sold so as to get Z of the buy token. Fees and/or gas are not taken into account, but instead the estimator provides calldata and the gas units needed to convert Z’ of the sell token to Z of the buy token.

The above, in particular, would suggest that when placing an order, the quote that is associated with the order is the one that estimates how much buy token we can get.

On the other hand, I do see your concern about solvers potentially avoiding to provide quotes for these “buy 1 ETH” orders, and it would be good to incentivize these quotes as well. One point to investigate is how many such requests are made per day. Maybe the backend team can provide some more insights here.

4

Continuing the discussion, and after collecting some feedback from the backend team and some of the solvers, I want to note 2 things:

  1. Price estimation can get expensive due to the thousands of queries per minute, and because of that, I would like to suggest to increase the reallocation from 15% to 20%, which would suggest an increase in the + X parameter, which is the reward given whenever a winning quote results in an order execution; this is up to discussion, but could be increased to 9 COW.

  2. The “buy 1 ETH” requests, due to efficient caching that is currently done, end up being around 40-50 per minute. Since the competition about the actual quote associated with each order is not affected by these “buy 1 ETH” requests (as they are only used in a second stage to determine the fee in the sell token), we suggest that for now we don’t accommodate for those requests. The rationale behind this is that, given how pressing price estimation is and how low is the number of such requests compared to the more standard sell_token/buy_token quotes, this can be done in a subsequent CIP that would also adjust or refine the scheme proposed here. In other words, we believe that a strong competition in the requests of type (1) (see @fleupold post) would already resolve the majority of price estimation issues the protocol is currently facing.

In case there is some agreement on these points, I will update the text of the proposal.

1 Like
5

I agree with most of this proposal but I think the incentives should at least partially be based on the size of the order, as volume is also a key metric and can differ wildly between orders. Maybe halve the suggested values and add a volume term with coefficient such that the budget is roughly the same.

1 Like
6

This is definitely a valid point. However, I see some issues if we want to incorporate this into the mechanism. Let’s think about sell quotes, where there is a sell amount and solvers are requested to compute the expected buy amount:

  1. To assess volume, most likely you need a price of the sell token with respect to ETH. This is exactly what the requests of the second type compute (the “buy 1 ETH” requests). Which means that we cannot really compute the reward only based on the quote itself, but we would need some “external” information in order to evaluate the reward; not necessarily bad, but also not the cleanest solution either.
  2. I am worried whether in the case that we decide to evaluate the volume and increase the reward for larger volume quotes by using these “buy 1 ETH” quotes to convert the sell token to ETH, that the estimators would then try to inflate the price of the sell token so as to make the quote look like it is selling a larger volume. Not sure how valid of a concern this is, but I think this could happen.

In general, I agree with you that the mechanism feels a bit too static, and in a way, the whole effort resembles the solver competition rewards, and it could happen that price estimation evolves in a similar way to solver competition, with gradually more fine-grained rewards that take into account the complexity of the order/quote in question. On the other hand, there is already enough complexity to the protocol, and since it is not clear how soon we will have multiple external solvers competing in price estimation, and how stable these estimators will be, I am in favor of pushing something simple forward to get things started, and depending on solvers’ engagement and the potential problems that will show up, we should monitor and revisit the mechanism soon.

Still, I would like to hear some other comments on this as well. If there is some consensus that the reward should somehow depend on the volume (e.g., by doing some linear interporation between a min and a max reward that is based on the volume on the order, as @tomatosoup suggests), then we could make this part of the proposal.

1 Like
7

I think we have seen from our journey through the different settlement rewards schemes that volume itself may also not be a good enough proxy and introduce games depending on which token is being traded.
I personally think the protocol should provide a “baseline price estimator” and price estimation rewards should be based on how much a solver can improve that “baseline quote” (similar to how settlement rewards are based on the surplus improvement to the second best solution).

This way, solvers could also opt out of sending responses for tokens where there is likely only a trivial route (single Uni v2 pool) as they won’t be improving the baseline.

That being said, implementing such a scheme is more work on the backend/accounting side, so I’d be in favor of starting with the proposed solution.

1 Like
8

Did some edits in the proposal. Specifically, there are two changes being proposed:

  1. The reallocation of rewards increases from 15% to 20%.
  2. Since there is an explicit requirement for calldata associated with each quote, which should simulate successfully, the need for a penalty is not very clear anymore, so it was removed altogether.

Let me know if you think this is an improvement upon the original version of the proposal.

9

Proposal moved to voting phase!

https://snapshot.org/#/cow.eth/proposal/0x64e061568e86e8d2eec344d4a892e4126172b992cabe59a0b24c51c4c7e6cc33