CIP-10: Solver Rewards Funding (round 2)

CIP: 10
title: Solver Rewards II
author: Ben Smith <ben@cow.fi> (@bh2smith) 
status: passed
created: 2022-06-03

Voting is now live on snapshot

Update (2022-06-13)

There has been much discussion regarding the possible adjustment to reward distribution which has lead us to determine that capping is not ideal (cf @tbosman’s post here). It is clear, however, that the per batch reward mechanism does not accurately capture the risks involved when settling large batches. The idea for this proposal will be to set a B COW per batch reward plus a T COW per trade. These numbers in a way to keep total issuance the same as the first 12 weeks of the program. Simulations according to this formula:

B * total_batches + T * total_trades = total_issuance

Simulations were performed via this parameterized query taking the total number of batches and trades, and solving T above.

Any choice here ensures that COW token issuance is not decreased, but rather shifted so that larger batches (with higher solver risk) are more accurately rewarded. Results are:

Screenshot 2022-06-13 at 2.17.05 PM

It is expected that the following proposal will move into voting phase on Wednesday, June 15, 2022 provided there are no major objections.

Projected Proposal:

  1. Transfer 12M COW from CoW DAO (0xca771eda0c70aa7d053ab1b25004559b918fe662) to the Solver Rewards safe (0xA03be496e67Ec29bC62F01a428683D7F9c204930) and

  2. Change the reward scheme from 100 COW per batch to B COW per batch + T COW per trade. This change is intended to be made for the accounting period beginning 2022-06-21 according to the implementation drafted in CIP-10: Solver Rewards Scheme Change by bh2smith · Pull Request #38 · cowprotocol/solver-rewards · GitHub

Please vote on the following poll

  • 25 COW / Batch + 53 COW / Trade
  • 30 COW / Batch + 49 COW / Trade
  • 40 COW / Batch + 42 COW / Trade
  • 50 COW / Batch + 35 COW / Trade
  • Keep 100 COW / Batch + 0 COW / Trade

0 voters


Simple Summary

Based on a projected consumption rate of ~2M COW per month, we propose the transfer of 12M COW to fund the next 6 months of solver rewards. This proposal also introduces discussion points on adjusting the per-batch COW rewards schema since, currently, they are economically unsustainable. Data is provided demonstrating the risk-reward ratio for solvers and shows an alternative distribution plan that would deterministically last for 12 months by capping the weekly distribution at 200K COW.

Reward Data Thus Far

The COW Rewards Safe was initially funded with 7M COW & 500 ETH at transaction tx. During the first 12 weeks (3 months) of payouts we have distributed the following:

Rounding the 3 month total outgoing COW to 6M results in a projected estimate of 12M for the next 6 months with the potential remainder of 1 or 2 weeks of buffered funds.

Questions and Considerations

While the proposal is primarily intended to get the proposed funding (before the current COW rewards balance is depleted ~2 weeks), we also attempt to initiate discussion with regards to the following two questions: Should the DAO

  1. increase, decrease or keep the current distribution rate?
  2. consider an alternative (more refined) per-batch distribution?

The decision here, at its root, revolves around finding the fine balance between rewarding risk incurred by solvers while simultaneously bringing value to the protocol. We outline some statistics here on the risks and costs associated with operating a solver along with the burdens incurred by the protocol’s treasury.

At the current price of COW the rewards are valued at ~$17 per batch not including the solver risks (penalty for negative slippage and failed transactions). Slippage occurs when the protocol receives more from, positive, or pay more to, negative, an AMM than expected (i.e. when solving a batch). Slippage can be both positive and negative. Solver’s net slippage, when negative, is withheld from transaction cost reimbursement at the end of each accounting period. In addition to slippage risk, there is also the failed transaction risk, whose cost is not reimbursed by the rewards program.

From the protocol’s perspective there is a cost associated with subsidizing the trading fees to account for protocol overhead that is directly proportional to the number of trades per batch. More specifically, the protocol subsidizes the gas cost overhead of its own smart contracts as a batching layer between the AMMs. A certain number of trades per batch are required to make up for this subsidy. In essence, single order batches result in costs to the protocol.

We examine these stats thus far in each of the above mentioned risk areas:

Risks & Costs

Solver Slippage

Since inception of the reward program, slippage penalty costs, while expected to be 0, total $111,863 over 54,601 batches (averaging $2.05 per batch). This data (built from this parameterized query) is taken from the weekly totals in this spreadsheet. To regenerate the results, simply put the accounting period StartTime into the query linked above. The per trade average slippage cost is $1.36 based on 81,832 trades.

In addition to these averages, it is important to note that larger trades incur higher risk of negative slippage. It would be nice to incorporate trade size into the equation when determining rewards. However, due to unreliable price feeds for arbitrary tokens we are unable to accurately assign value to every trade.

Solver Failed Transactions

Currently the per batch average failed transaction cost is $2.15 (deviating by $1.72) with individual solver average costs ranging from $0.16 (Naive Solver) to $5.48 (Otex).

The per trade failed data shows an average cost of $1.69 (deviating by $1.36) and ranging from $0.09 to $4.42.

In addition to the statistical averages noted above, higher risk occurs during times of high price volatility. That is, if a quote is given to a user based on the network state at block N, but the trade isn’t settled until block N + K, even when K = 1, the transaction has a much higher likelihood of failure. One deterministic aspect that could be incorporated into the reward mechanism could be making it a function of gas prices, however exploration of this idea is beyond the scope of this post.

Protocol Costs

Since the inception of the reward program 75% of all settled batches contain only a single trade. Here is a chart query showing the batch size distribution for this time frame.

Single order batches are an expense to the protocol since the fees are subsidized to offset protocol overhead when it comes to transaction costs (i.e. fees collected for a single trade are less than batch execution cost). This means that rewards given for these batches are a loss both in COW and ETH.

This simple statistic shows the cost coverage (fees collected / cost incurred) trends for batches based on size (i.e. number of trades). It is expected to have an upward trend as the number of trades increases but we also see that, on average, the protocol only becomes net positive for batches with more than 5 trades.

At this moment, it is clear that the protocol costs substantially exceed the risk/cost realized by the solver competition.

The combined average cost for both solver risk categories is $3.36 while the reward per batch is currently about $17 (with COW token valuation of 17 cents).

The current average cost per batch for the protocol is ~$16 (= 17 - 0.86) derived as cost in COW - revenue from fees. Note, that fee revenue is calculated from May 4 since we have recently reconfigured the fee subsidy model so prior data does not resemble the current state of operations. For more detailed historical data, please visit the daily average per batch revenue chart. Unfortunately, sustaining these rewards at the current distribution rate is not economically viable for the protocol in its infancy (i.e. during a time before network adoption has been realized).

Certainly protocol adoption is key to driving the batch sizes up, but in the meantime we could strive to reduce the per batch cost of rewards while keeping the competition attractive!

Adjustments to the Reward Scheme

In the original proposal CIP-2: Solver Rewards and currently, the rewards were specified as 100 COW tokens per batch. This was considered a reasonable first approach to reward distribution with limited complexity that could be quickly implemented and launched. However, from the data shown so far we have seen that this distribution scheme bears a substantial cost to the protocol that is not long term sustainable.

Some immediately apparent, straight-forward, yet good alternatives:

  • Rewards per trade instead of per batch:
    This would be easily implementable with minor changes to the current setup. It is completely deterministic and reproducible and, since the number of trades correlates directly with protocol expenses, can be seen as a good first step in the right direction.

  • Capped weekly rewards distributed proportionally according to some measure:
    This alternative works well together with any adjustment made to the way solvers are scored while simultaneously given more certainly to the distribution rate over time.
    Example Simulation (Trades per Batch)
    For example, if we rewarded T (<= 50) tokens per trade rather, then single order batches would not be such a burden on the protocol. We can simulate the total outgoing COW rewards based on the total number of trades 76636 (total outgoing COW / number of batches quoted above)

COW Reward / Trade Total Outgoing COW (first three months) Solver Reward / Trade $
30 2.3M 2.05
35 2.7M 2.90
40 3.1M 3.75
50 3.8M 5.45

Where Solver Reward is calculated at a 17 cent COW price and deducts the per trade average cost for slippage 1.36 and failure 1.06 (cf. computation in spreadsheet).

So, if we were to take an approach like this (as is also indicated by the batch-trade distribution chart), a 35 token per trade reward would essentially double the projected time frame for which the proposed funds would last.

Of course, this is just a simple example of an alternative mechanism for reward distribution and preservation of protocol value with the prospect to eliminate raw loss. Other suggestions are welcome for discussion here.

Summary

We remind the reader that this proposal’s primary goal is to top up the Solver Reward Safe 0xA03be496e67Ec29bC62F01a428683D7F9c204930 with 12M COW to sustain the next 6 months of rewards.

If possible it would be nice to include a concrete adjustment plan based on the data and discussion provided here. For example, a proposal of the form

capped weekly distribution of 200k COW with proportionality measure determined by number of trades

would ensure that 12M COW lasts for 12 instead of 6 months.

If no consensus is reached for the adjustment plan, this request for 12M should be moved quickly into voting (as there are only 2 weeks left for the current program).

In pseudo transaction format, that is

Transfer(
    token=0xDEf1CA1fb7FBcDC777520aa7f396b4E015F497aB, 
    from=0xca771eda0c70aa7d053ab1b25004559b918fe662,
    to=0xA03be496e67Ec29bC62F01a428683D7F9c204930,
    amount=12000000000000000000000000,
)

Plus, potentially, a reconfiguration of the Solver Rewards Distribution Project depending on how the discussion goes.

Happy discussing!


Based on the discussion so far, it has become clear that one thing left out from the original post is the added risk incurred by solvers for high value trades. The additional risk is both due to slippage and likely hood of failure. Below are two polls which, together could help shape a reward restructuring proposal (cc @voyta.eth , @Filius , @prometheus , @tbosman - since you have been the most active so far).

Cap weekly rewards or not?

  • Cap at 200k
  • Cap at 250k
  • Do not Cap

0 voters

Metric for which rewards are computed

Note that basing solver rewards based on tiers comes with a 1.6% error margin. See here for supporting data.

  • Reward per Batch
  • Reward per Trade
  • Per Trade Reward Tier (with trade size tiers)

0 voters

4 Likes

First of all, thanks for this insightful information. From everything said I don’t have much more to add besides that we probably should make a distinction between single trades and multiple trades per batch.

Made the following query using the same time interval to simulate what I think would be better. Values can be adjusted by anyone willing to try different solutions but my idea would be to give 30COW for single trades (default_reward) and 40COW per trade (bonus_reward) for multiple trades per batch. With this solution we would give 2.66M COW instead of 2.7M (if we would go for 35COW per trade), meaning it’s quite equivalent but it would push solvers to include more trades in each batch. Another solution would be to cap the reward per batch to 120COW (40*3=120, or whatever) nevertheless that solution isn’t relevant at this point since we don’t have many batches with 3 or more trades (I didn’t include any cap in the query).

I can be wrong but it seems that some solvers are now pushing trades faster/harder than before in order to get the batch reward but what we really want is solvers to push for better solutions, not for faster execution solutions. If users really want faster executions they should pay a premium for that.

In conclusion: we should decrease current distribution rate. Any solution per trade is fine but I would like to see a bonus for multiple trades per batch. Also, the 200k COW weekly cap should be implemented (we may not need it with lower activity but better to be safe than sorry).

2 Likes

Generally speaking, I think it’s the step in the right direction - namely the fact that batch reward should be variable and based on the orders that the solver chooses to settle. It makes sense that larger batches should be rewarded more than batches with just a single trade. This is also because larger batches enable CoW trades which are a major value-add of CoW Protocol as opposed to competitors.

However, I believe this model is still too simple, and solver rewards will need several other iterations. A non-exclusive list of factors that may need to be considered for COW rewards:

  • Order trade volume (denominated in ETH or USD) - currently, batches with very low USD volume are rewarded too much, and batches with very high USD volume are potentially rewarded too little. Trade volume is a major driver of user benefits but also is a major factor for execution risk that the solvers are undertaking. Large orders have a significant chance of moving the markets too much, and being profitably frontrun. Therefore, rational solvers might not bid for settlement of very large orders to the extent that they have to bear revert risk costs (failed tx gas cost) and slippage risk (being subtracted from COW rewards).

*Traded pair characteristics - as with order volume, the type of token (its volatility, liquidity) influences solver’s execution risks. It’s much easier settling a $1m USDCDAI than say $1m SHIBETH, because SHIBETH pair is much less liquid.

3 Likes

Risk is higher for high volume trades but I don’t see this as an issue. On the other hand, low volume trades can be quite an issue since they don’t add much value to CoWs. The easiest way to somehow fix that is to “force” solvers to include this low volume trades in larger batches. To achieve this we could reward batches only if they reach a minimum volume, not a fair solution but I’m sure solvers can find ways to not prioritize this trades.

Made this query using the same time interval as before, same default values plus a min_volume variable at 100USD to reward 0COW for batches not reaching the minimum and instead of 2.66M COW we would give 2.58M (~7k COW less every week). It doesn’t make much difference but it can work as an incentive for solver to find better ways to mitigate the cost/impact of this low value trades. If people like this kind of solution I don’t see any issue following something like this but it doesn’t make a big difference.

There are two different things - overall level of rewards, and how the the rewards incentivize solvers to behave (and possibly discriminate different orders - which is something you don’t want, you want to them to be still willing to settle all orders, but also not give them unnecessarily high rewards).

Regarding forcing small trades in larger batches: a fairly extreme solution, why wouldn’t we instead decrease the reward so much that any rational solver would combine them in a batch anyway?

But why is too low of a reward not an issue?
I would say the issue is both

  1. low value trades are generally subsidized too much (in terms of COW inflation).
  2. some high value trades do not carry large enough reward for the risks that settlement brings (execution risk is taken on by the solver). I suspect the only reason why some large trades are going through is solvers aren’t “rational” yet so would settle orders which are unprofitable for them as well (and the average is working out very well still). Imagine an extreme case, a user settling $10m SHIB>ETH, slippage tolerance low. CoW Protocol welcomes such whale trades (although they might need to be a higher fee in future, but this is a different issue), and the user should benefit from CoW Protocol as well. But, why would you settle such an order as a solver?
    You can get 100COW, but how much more can you lose from slippage risk if you get frontrun by a generalized MEV bot that monitors Cowswap pool? If you lose 0.1%, that’s $10k you owe to CoW DAO. If gas price is currently high, such a transaction can get reverted quite often, and you would not be compensated in such cases. Again, the COW reward must be reflecting this chance (which can be high for $10m SHIBETH, as opposed to a small trade which does not move the AMM prices)
1 Like

The idea is to change that. There’s plenty of solutions we can work on.

My last example would be to give zero rewards to low volume batches for simplicity and because it’s a fairly low impact solution but we can work on something different. Meanwhile I updated the last query allowing people to change the min_volume_reward for low volume batches, instead of 0 people can try any value they want. After all it doesn’t make much difference assuming we reduce the default reward to 30COW or 35COW for each trade.

Keeping everything how it is now (100COW per batch) isn’t a solution I will vote for. Anyway, I suggested something simple since I have some concerns directly factoring volume for Solver Rewards. For instance, protocol fees and transactions cost don’t rely on this order volume meaning the solution provided by a solver needs to be a good one otherwise there’s no reason for them to provide a solution for this trades. I’m not even sure if I would put a $1M (or more) trade in CowSwap because of the 0.1% on-chain slippage.

Edited: After thinking a bit more on this we could give 15COW per trade (or 10) plus a bonus considering the batch volume. We would need to use the cube roots of the batch value (v3 in this query) since we don’t want the reward to increase linearly. The overall reward can be quite similar depending on the ratio reward and the base reward we would apply but this solution can be gamed. For instance Solvers would do better splitting high value trades instead of matching them in the same batch (not exactly a CoW friendly solution).

The way I think about it, any solution has a maximum gas price at which it becomes stops being viable. By lowering the rewards for a particular type of solution, we reduce that maximum gas price. In other words, if you reduce the rewards for small batches you reduce the gas price at which solvers stop bidding those batches, or at least with on chain liquidity. There are several positives effects to this: solver may start waiting for an internal match, or for the gas price to drop, so that the fees collected better cover the tx cost. A macro effect might be that it may push solvers to find sources of private liquidity to be able to settle those batches profitably at all.

Still, I don’t believe this is 100% aligned with how COW accrues cost: fees scale with the gas price, so it’s not true that fees automatically cover tx cost below a certain threshold. Perhaps a more dynamic incentive would be to make award some fixed cow per batch, plus a percentage of profit (= fee - tx cost - fixed solver reward) whenever that is positive. This way you incentivize solvers to wait with bidding until they find a solution that has at least certain level of coverage. It still depends a bit on the gas price, but less so than is currently the case.

1 Like

One thing that I see missing on the discussion above is the game theoretic aspect of the solver competition. Until private liquidity starts becoming more important, most solvers will arrive at the same (or nearly the same) solution.

Given all solvers access (almost) the same liquidity sources, the only reason why a solver would be able to fill an order that another solver can’t fill would be due to differences in their methodologies (CoW search algorithm, buffer usage algorithm, etc). It won’t take long until solvers can all arrive at the same solutions, given they all use the same sources of liquidity. At that moment, the best I could do to maximize my profit would be to submit a solution whenever there is one. Otherwise, another solver would send the solution and I would be left hanging for waiting until two orders can be filled to earn a “higher” reward. So, the question here would be, given that a single order settlement is rewarded, how often can a solver expect to settle two-order settlements? Why would a solver wait until two orders can be filled, if she risks losing the opportunity to win the reward of settling with a single order.

The way this should be thought of is as follows, say you always wait until two orders can be filled, then your expected reward would be something like this Prob( 2 orders are feasible ) * 30 COW, where Prob( 2 orders are feasible ) would strongly depend on the behavior of the other solvers. As soon as that number is smaller than 50%, then no rational solver would wait to see two orders being feasible. Since this is a competition, there is no reason for any of the solvers to believe that probability will be larger than 50%. Even though that could increase the total expected profit of all solvers as a group. In game theory there is a good example that describes this sort of behavior called “Prisoner’s dilemma”.

To summarize, a per trade reward scheme won’t change the current distribution of trades per settlement. It will only modify the total rewards distributed. If you want to see a different distribution of trades per settlement, you would need to stop rewarding single-order settlements.

3 Likes

Indeed. It’s a good point and we can do something similar to promote “CoW friendly” solutions but I don’t think we should implement something so radical (almost all batches would receive zero COW) in the near future (round 2).

Let’s say we give 10COW (or 5 COW) for every trade and we add a bonus on top of that considering the quantity of trades in each batch. Something like:

  • 1 trade => no batch bonus (batch reward = 10COW)
  • 2 trades => batch bonus = 50COW (batch reward => 10*2+50 = 70COW)
  • 3 trades => batch bonus = 100COW (batch reward => 10*3+100 = 130COW)
  • 4 trades or more => batch bonus = 150COW (batch reward => 10*N+150 = 190+COW)

To be fair, I like this kind of solution more than the previous since it will reward solvers trying to be more “CoW friendly”. On the short term it may have a significant impact on the protocol. Considering the sample data used before it would only reward 1.78M COW (query) but I’m sure Solvers will adapt and this numbers will change sooner than later (to be safe we should apply the 200k cap per week).

To mitigate the fact that solvers will not be encouraged to solve single order settlements we probably need to push for another proposal that would allow “priority trades” to be implemented. If users want their trades to be executed asap (in single order settlements for instance) they should pay a premium and Solvers should also receive a bonus reward executing this trades (we can add this at any moment without changing how the round 2 works). I believe this would be the best solution for users, solvers and for the protocol.

Thanks for your post and the really nice query! One thing to point out here.

Solvers don’t really have the choice about how fast batches are processed. The Auction clock is still maintained by the driver.

1 Like

Thanks @voyta.eth for these ideas. I definitely forgot to mention the added risk (in both categories) for high value trades.

While it is definitely a goal to incorporate trade size into this formulation, at the moment we do not have a reliable price feed, there are still about 1.6% of our trades for which we cannot assign value (query). Unvalued trades are those for which we cannot assign a value to both the buy token and sell token. Here is a list of token pairs for all unvalued trades in the firs three months of the reward program.

Having made this query, I was actually under the impression that the proportion of unvalued trades was much higher. So, if we were willing to accept this margin of error, we could actually work with this!

If we were to allocate COW based on trade size what do you envision this might look like? Here is a table describing a naive approach:

Trade size reward tiers:

  • below 1k => 30 COW
  • between 1k and 10k → 35 COW
  • between 10k and 100k → 40 COW
  • between 100k and 1M → 45 COW
  • above 1M → 50 COW

Is this similar to what you had in mind? Or were you also hoping to account for comparison of how deep the liquidity is for the token pair?

1 Like

I agree the current rewards scheme needs to be changed.
$1m and higher trades actually happen sometimes, although I agree onchain slippage should be decreased for some pairs. Getting a bit off topic here though.

Yeah, no need to scale them linearly and we certainly don’t have enough to say how exactly reward should scale with volume. Agree with a minimum reward (which needs to be lower than cost of an additional order to prevent spam) and scaling less than linearly (question is how much though). Splitting a high value trade is an issue, but it might make the solver not win the batch.

1 Like

I understand that but I don’t really understand why trades like this are settled.

Batch value is lower than the tx cost and the tx cost is twice the fee collected, solvers could not provide a solution for this trade but they provided. In a competition, if the reward is enough valuable for a solver they will provide solutions even if it’s sub optimal, that’s what I’m thinking solvers started doing since we have rewards. Before that they probably wouldn’t provide a solution for this trades (anyway, I can be wrong about the why this trades are settled, it just don’t make much sense to me).

This is also why I’m inclined to vote for any solution that consider the amount of trades in each batch. Rewarding a quite low value to single order settlements seems a good idea. Obviously volume can be considered per batch or per trade.

For instance, I’m fine with this but we should reward single orders settlement less than more complex settlements, otherwise solvers may be inclined to push for sub optimal solutions. Since it’s a competition solvers providing sub optimal solutions win if no other Solver provides an alternative solution, unless I’m missing something?

why trades like this are settled

Note that the fees collected in comparison with the cost of settlement is not a parameter solvers need to be worried about. The protocol reimburses the cost and rewards the solvers per batch (or as proposed per trade). In this case, the protocol is responsible for an effective fee quoting mechanism that will result in net positive fees - costs.

I’m fine with this but we should reward single orders settlement less than more complex settlements

This is the intention of changing to a per trade reward instead of per batch.

Thanks, yes a tiered structure or perhaps a more complex function of the volume (capped, floored, monotonically increasing in log (trade size) or someting like you have) is what I had in mind. My intuition suggests the rewards should be more sensitive to trade size than you drafted, even though clearly we can’t make them linear. I think there are few trades over 1M, and the COW rewards for settling them should likely be higher. For instance, if the solver uses default 0.1% price tolerance onchain, they are risking incurring up to 1000 USD (over 6000 COW as of this time) before they are reverted. Btw, I am not meaning that the reward should be 6000 COW (no reason to believe they can get front-run to this extent), but intuitively, the reward should be higher than 50 COW which is <1% of this amount of risk, when you also consider revert risk (probability of losing gas costs when revert).

Given we need to move quickly before rewards are gone, it looks like a guesstimate is needed but for next iteration, it’d be great if we can come up with a more “calculated” approach.

1 Like

To my understanding, the protocol does not reimburse a solver if they get reverted, the impact of a solver’s revert risk is rising linearly in gas price, something which is not embedded in either user fees or the COW rewards.

Yes, the protocol does not reimburse the solver for reverted transactions:

This point of my comment (reply) is not at all referring to cost of failed transactions.

@prometheus has highlighted a batch with a total trade value of 7 dollars, having 12 dollars in costs and only collecting 5 in fees. He is asking why are batches like this settled.

1 Like

I feel like there might be a misunderstanding about the auction mechanics as they work right now. It sounds like you think that with a different reward structure, one of the solvers might have found a larger batch for that specific auction you highlighted. Is this what you mean (please tell me if I misunderstood)?

That is very unlikely, in any case.

In almost every auction, only solvers that propose a solution filling the maximum number of trades stand any chance of winning. Among those solutions, it’s generally up to the surplus and/or gas efficiency.

In the case you highlighted, it probably wasn’t possible to match any other trade in the batch. If there was a solution matching two trades possible, that one would surely have taken the auction. In this case, only a tiny single trade batch was possible, and the objective function apparently ranked this solution higher than no solution at all. If we don’t want this kind of solution to go through, the objective function should be changed, not the rewards.

1 Like

This is my concern: If one Solver is willing to settle a trade and no one else is, they get the Reward + tx cost (100COW wasn’t a bad reward) but it’s like you said…

Anyway, we can also do what you suggested, it can be more efficient to just “ignore” some solutions (at least for some of this cases, not all):

Let me give a bit more context on why the protocol is currently choosing to settle batches that are not economically viable. If people place orders via the CowSwap UI, they expect their order to get settled without any other user interaction. The way the fee mechanism is implemented today, is that users get a firm fee quote which they will pay in full iff the order gets executed.

It is entirely possible that between the type of quoting and the time of execution, gas prices change both up or down. In case the gas price goes up we don’t want the user to re-sign their order and therefore chose to execute them even if it means a loss for the protocol.

I think it would be nice (and I believe @voyta.eth has already started thinking about a model) where the per order fee can be dynamically computed based on some features (token pair, trade size, market situation, etc).

Yet, we are a bit under time pressure (in order to guarantee uninterrupted reward payouts we need to move into stage 2 by this Monday) so if we want to experiment with a new payout scheme we should come to a conclusion soon. Otherwise, we can also keep the current mode and vote on a more advanced reward structure in a separate CiP?

2 Likes