"Pennying" as a strategy to win more auctions, and how to deal with it

Technical
1

DISCLAIMER: This post is in no way an attack or criticism about the strategies currently being used by the participating solvers; its intent is to highlight a potential problem in the current rules and propose ways to fix it.

This is based on discussions with @marco , @fleupold and @voyta.eth .

What is pennying?

During the last few weeks, it has been observed that, in order to win the competition, multiple solvers are increasing their chance of winning an auction by “buying” additional surplus for the users using a technique we call pennying. We describe pennying with an example.

Example of pennying

Suppose there is a single user order in a batch, that sells 1 ETH for at least 1500 USDC, and that a solver finds a Uniswap v3 pool to execute the trade, such that the pool returns 1510 USDC. This means that the computed user surplus is 10 USDC. If there is no slippage when settling the transaction on-chain, then the pool indeed returns 1510 USDC, and nothing would be pending in the weekly re-adjustment between the protocol and solvers. Now, the solver can instead report a price of 1515 USDC for 1 ETH, effectively incurring “artificial” negative slippage on the solver side, that is taken into account in the weekly accounting. What this means is that the solver is willing to pay 5 USDC from its pocket, in order to increase the objective value of its solution and make it more competitive. In the case where the solver ends up winning the auction, it pockets the 50+35=85 COW reward (currently valued at ~$10), while paying a penalty of 5 USDC = $5. Thus, the solver makes a profit of $5.

This technique of slightly inflating the prices by a small amount (usually ranging from $1 to $5) so as to increase the chance of winning an auction is what we call “pennying”.

Sample data from mainnet solver competition

To demonstrate that this is not a theoretical problem but a very real one, we give examples of different solvers, coming from a dune query that identifies slippage, using data from August 2022. Figure 1 shows the distribution of slippage for solvers that we believe are not pennying (mass concentrated around zero), while Figure 2 shows the distribution of slippage for solvers that are likely to be pennying (mass concentrated around some small negative value).

image (8)
image (8)1133×201 29 KB

Figure 1

image (9)
image (9)847×201 19.2 KB

Figure 2

Is pennying bad?

Solutions that incorporate pennying are valid given the current competition rules. The protocol does allow for deviations of reported prices compared to the actual executed AMM prices since volatility is in many cases present; this is why accounting is needed in the first place. However, we believe that allowing for some slack does not mean that solvers should be able to systematically report better solutions than they are actually able to find,and play games with the sole intent of getting a fixed COW reward for a particular batch. By using pennying, solvers are effectively getting an unfair advantage over other solvers that may have a better (or at least as good) solution but are not pennying. Again, we stress here that this is not just some theoretical observations, but we have enough evidence that demonstrate that pennying has played an instrumental role in solvers winning many batches (this is also due to many batches only containing a single order that is quite straightforward to match against some AMM); the competition itself also shows that if pennying was not effective, it would not have been used so extensively.

While all solvers could employ pennying, under aggressive competition, it is clear that pennying will lead to solvers exhausting most of their COW rewards in order to win auctions. And, in an extreme case where a rich solver enters the competition, one could imagine that particular solver essentially giving away free money, incurring losses that it can sustain for a relatively long time, to the point that other solvers cannot do anything but give up on the competition.

Dedicating time and resources into developing sophisticated pennying strategies does not lead to any meaningful progress/growth for CoW Protocol, so we believe that such a systematic manipulation of solutions should not be allowed.

How to deal with pennying

It is not trivial to detect pennying and distinguish it from normal on-chain volatility. Because of this, we believe that pennying should be explicitly disallowed, and that we could agree on some soft monitoring rules that could detect it. The course of action after that would be up to the DAO to decide, but in any case we would like a mild process where the first step would be to notify a solver and monitor its behavior, in order to see whether things improve, and if not, attempt to identify the problem and whether it is intended or not. At its most extreme form, systematic pennying could lead to slashing.

Some additional steps can also be taken. As of now, solvers are required to report expected input/output amounts in all the interactions they include in their response json. The numbers reported could be interpreted as a commitment on the solvers’ side that indeed these are the amounts they expect to see on-chain. Thus, checking global token conservation, also known as token conservation per token (see here for more details), could help; as a clarification, we would only require that the reported numbers are such that token conservation per token is satisfied. This does not immediately prevent a solver from lying about these numbers, but would help serve as written commitment from the solver that indeed these are the numbers that are expected to be seen if the solution is settled on-chain. Systematic upwards deviation from these numbers could be considered as evidence of pennying (see Figure 2 above). Moreover, a requirement on top of that could also be that solvers must provide a block (around the time the batch was created) in which their solution simulates with no slippage at all; this would serve as strong proof that indeed their calculations are accurate given the information they have about the state of the blockchain.

Conclusion

The purpose of this post is to raise awareness about the quite controversial phenomenon of pennying and have meaningful discussion about it and about ways of dealing with it. Depending on how the discussion goes, this could potentially lead to a new CIP addressing pennying (e.g., prohibiting it or proposing ways to reduce its impact).

7 Likes
3

It sounds to me that there are two ways to address this phenomenon: (A) impose technical limitations on pennying itself or (B) deal with the negative externalities caused by pennying: namely consistent selling of CoW tokens to fund the pennying strategy.

@harisang’s post seems to focus on approach (A). The problem that I see is that while (A) solves the immediate problem of CoW being dumped through the pennying vector, it has the side effect of causing worse prices to be delivered to traders. Granted, the current “better” prices are artificial, but they are real and they are not violating the objective function. Another downside is that more complexity is being introduced on the solver side to address this specific corner case.

I wonder if there are better approaches that aim to address (B) directly: how might we reduce the negative externalities caused by pennying on the CoW token itself? The benefit of this approach would be that we would not eliminate the possibility of a solver using their own private liquidity (independent of CoW rewards) to fund this strategy.

I do not yet have a specific proposal that fits in (B), however past ideas to reduce sell pressure on the CoW token have included a vote escrow models (“VeCoW”) and revenue sharing tokens as per this draft CIP.

4

I would say there’s more…

C) Slashing via Social Consensus (CoWDAO can slash the respective bonding pool).

If we get to a point where we need to say enough is enough we should do it. Technical solutions are always better but not the only solution.

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

5

Hi all, first post here. I’ve been working on getting my solver up and running these last few weeks. I actually hadn’t known about this until I saw this post this morning.

I think yeah this is undesirable behaviour. In my understanding, this does NOT lead to better prices for traders. You inflate what you report so you can win the auction but you provide the same execution to traders. You end up paying the penalty for negative slippage back to the protocol. In fact, you may provide worse execution if you beat out someone with a real solution that’s better. Will have more to say soon.

2 Likes
6

I completely agree with the problem being addressed here, but I disagree with the root cause, and expect that just addressing pennying in isolation creates more bad incentives than it removes.

You get what you reward

I think the root cause is that the rewards are mispriced. The vast majority (by count) of batches that settle, have a lot of solvers submitting solutions that are very close. Eg, where the top solutions have utilities within 1 USD (in real terms) of each other. Thing is, only the top solution wins the reward. This reward maybe 9$ or more depending on cow price and number of trades in the batch etc.

In other words, the strategy of taking a loss to increase win probability is completely overpowered for the average batch. Pennying as described in loose terms above, is just the most effective way to do so, both in terms of gas/surplus generated and in terms of implementation difficulty. I don’t want to give people ideas unnecessarily, but there are definitely other ways to ‘lose money to win the batch’, using more gas and perhaps having higher capital requirements (not good for decentralization).

This does not mean that having extra solvers doesn’t help the protocol. I have seen batches where number 1 had a solution with an objective functions 100s of USD higher than number 2. However, those cases are rare (frequency-wise). They may contribute a lot to the overall surplus, but they make up very few cases. And rewards are paid out roughly by number of batches won, not so much overall marginal contribution to the utility generated.

Also, note that pennying becomes pointless in cases where the 1st and 2nd solutions are further apart than the reward to be gained (you would go negative EV if you’d try to penny your way to the top).

IMO the solution should focus on addressing the incentives directly. In any case this would involve reducing cow subsidies for crowded batches, and use it to reward solvers that find particularly exotic solutions, or solutions with high delta compared to the rest.

How to fix

There have been earlier suggestions to reward solvers for incrementality more. I opposed these, because they involve distributing a fixed reward weekly based on ranking, but letting cost accrue to solvers with every batch as it the case. This generates a way more complex meta game than we have now.

The simplest way that I can think of that will completely remove any strategic behavior would be to use some form of second price auction mechanism. Could look as simple as this.

  • Solvers submit batch as they do now, plus they quote a price they need to cover failed tx cost and net slippage if they win (this number could be negative, if slippage is expected to be sufficiently positive on average)
  • The solutions are ranked by objective - quoted price
  • The top solvers get the batch, the reward is the quoted price + difference in utility between top and second best solution

Note this mechanism is truthful in the sense that solvers should report their true expected cost: if you are not winning when you quote truthfully and you penny to gain the batch, you will lose money on average. If you already won the batch then pennying won’t increase your payoff any further.

There are some drawbacks to this approach:

  • one is that it might require an unbounded amount of subsidy from the cow protocol. I don’t have a good suggestion of the top of my head, but maybe there is something we could do there.
  • The second is that the protocol values redundancy, but redundant solvers mean that margin will tend to 0. I think this latter problem is elegantly solved by picking a random auction winner instead of always picking the top one, like they do in at rook protocol. One way to implement it for cow would be to add Gaussian noise with some fixed standard deviation to the utility (eg 1USD worth), and pick the top solution afterwards. This forces the equilibrium strategy to have positive margin even under perfectly identical solvers.

I am not married to this particular approach, but I do believe any solution should involve having the rewards set by the market more, instead of banning specific ways to exploit mispricing. The latter will just trigger an race to find new ways that might be even more negative sum .

We shouldn’t ban pennying

On thing to note about the pennying observations posted by Harris above, is that the observation is about median/mode (I think they are pretty close here). Ie, the ‘pennying’ solvers are not reporting values equal to the median token flows. This says nothing about expected token flows though, and that number is the only one that matters for the bottom line. In particular, the solvers that are not pennying may have vastly positive of negative expected slippage, and I am sure we have seen examples of both.

In particular, you could have one solver that has $0 slippage 99% of the time and -$1K slippage 1% of the time for an average loss of 10$ per transaction, while the other solver has -$1 slippage 99% of the time and +$99 slippage 1% of the time, which would create an average loss of $0. By the median logic, the latter solver is pennying, but we really should prefer it over the former.

This is not an artificial problem either. It pops up when choosing to route certain multi leg paths through 0x or 1inch. These will typically give the same return if you route it on historical blocks, while the 1inch contract is more gas efficient (by a tiny amount, I think it’s a few thousand gas). However, the 1inch contract keeps slippage above a certain threshold, which adds up to a lot over time. (Think someone estimated it to be above $750K lost across all solvers so far?)

In particular, you’d want an efficient solver to detect when routing to 0x and pennying the difference in gas is more efficient than routing through 1inch after taking into account expected slippage and gas price and the rest of the batch etc.

Just to be clear, I agree that pennying is used just as much for burning rewards as for the legitimate case described here! It’s just that these cases are not distinguishable from the outside, so you are throwing away a lot of value if you ban pennying entirely.

If we really want to ban pennying

I’ve mentioned this elsewhere before, but if we really want to force solvers to report the median, I would suggest the following approach:
simply refund gas but don’t award any further rewards if there is negative slippage in the settled batch. The risk here is very straightforward to understand and manage for solvers, ie you just need to factor in that x% of the batches don’t deliver a reward if you report simulation on latest block, where x is small.

5 Likes
7

No actually pennying does improve execution for traders. Linearly so, in fact. If a solver over reports, the difference is paid out from the contract buffer, and the solver is charged for this difference so the protocol is made whole in the end.

The issue is that this is, essentially, just taking cow earmarked for incentivizing solver development and passing it directly to the user. There is no long-term benefit in letting solvers compete on this. Instead you really want solvers to be building better infra, more complex algos, access to new sources of liquidity etc.

3 Likes
8

I am against protecting against this. At the end of the day, users are getting better price.

When yearns deploys its solver an order might trigger a yearn strategy harvest to do a cow. Would that be “pennying” as well since we get an additional benefit on top of the batch won?

A possible mitigation might be locking cow rewards. Something like a 6 months lock, which would reduce the liquidity of cow rewards for the solver and making pennying more risky.

1 Like
9

I agree with @tbosman that banning this will probably lead to other strategies that try to get the reward while losing money in the settlement. Therefore I think its indeed better to search for alternatives to reward ‘honest’ solvers than to ban behavior from ‘dishonest’ solvers

10

Hi, and thanks for your reply. There’s a lot to digest here, but I would like to first focus on your suggestion in “if you really want to ban pennying”.

What are the advantages of not rewarding a solver with negative slippage (which might happen legitimately without any pennying involved) versus simply forbidding pennying?

I see at least the disadvantage that while indeed the solver that was pennying is penalized, so is the other that would have won the settlement if the former was not pennying in the first place (because it also does not get the rewards).

11

The idea is to make it the optimal strategy to report the median. Sometimes violations will happen to truthful solvers, but that is exactly the reason you can’t perfectly distinguish truthful from untruthful behavior, making enforcing a binary rule difficult.

Just a toy example, let’s say when reporting the price on the last block on average the price moves up 10% of the time, down 10% of the time and stays the same 80% of the time. A truthful solver get’s penalized 10% of the time, but we can compensate by inflating the rewards by 1/0.9 (without it costing the DAO more). On the other hand, a solvers that consistently reports last block price + epsilon will get penalized closer to 90% of the time. The only way they are not getting penalized is if the price random,y moves in the favorable direction. Hence a truthful solver gets 9 times the reward of an untruthful solver on average.

Importantly, untruthful solvers have this disadvantage in every individual batch by design. There is no use trying to hide pennying in the statistical noise, which would be a good strategy with soft enforcement.

12

Just did a quick analysis to illustrate how skewed the competitiveness of batches is when you look at averages vs quantiles. Unfortunately I can’t easily share it in a reproducible or self-contained way, and the data is not available offline, so if someone from the DAO could run it on the ground truth might be nice.

I took recent batches with at least 5 solutions, and ranked the top solutions by USD value of the objective function (using a fixed $1650 eth price). Then I looked at the average utility for each rank, and the fraction of the time each of the ranks are within x$ of the top rank.

Out of ~1000 batches, the breakdown looked roughly like this:

Rank : Avg utility | % within $1 of r1 | % within $5 of r1 | % with $10 of r10

  • Rank 1 : 221$ | 100% within $1 | 100% with $5 | 100% with $10
  • Rank 2 : 209$ | 33% within $1 | 81% with $5 | 89% with $10
  • Rank 3 : 190$ | 6% within $1 | 64% with $5 | 81% with $10
  • Rank 4 : 178$ | 2% within $1 | 54% with $5 | 74% with $10
  • Rank 5 : 165$ | 1.5% within $1 | 46% with $5 | 66% with $10

The average utility difference between the ranks is quite big, 12$ for best to second-best, which is close to the average reward but doesn’t factor in failed tx cost and the fact that 25% of rewards can’t be sold. Based on average gaps there should be no point in pennying. However, this gap is dominated by outliers. In most batches the top solvers are all very close and they are equally rewarded for winning in those settings.

Let’s say we somehow manage to eliminate pennying altogether. Let’s say we also plug all other ways to burn reward to gain a couple of bucks in utility. We still have an incentive problem. It’s way more profitable to try to close a tiny gap for easy batches where everyone is close, than it is to find a large improvement in rare cases, which has more impact on the user.

In long term, we will be paying out the majority of subsidies to a large number of nearly identical solvers before it becomes competitive to build a long-tail solver, and those solvers then compete for a much smaller share of the pie.

2 Likes
13

The problem I see is that there is no such thing as “stays the same 80% of the time”. The distribution of slippage seems to fit a cauchy distribution (two symmetric heavy tails) centered at zero: 50% of the times you get negative slippage, the other 50% positive slippage. I think not rewarding solvers 50% of the time is perhaps too penalizing…

14

Thanks for this very good discussion so far!

We totally agree with you on this one, however simply “fixing the rewards” has proven to be challenging, will likely require a few more weeks to be in a CiP-ready state and even then not be perfect (there will continue to be mis-priced batches, but hopefully fewer and with less mis-pricing).

Really getting the reward structure right, will likely take a few more months, which is why banning pennying now seems like a good way to stop the bleeding.

:point_up: nails it :100: and why we think we should act on this ASAP (while we don’t yet see a race to 0, we are seeing uneven competition because of this). In our mind an alternative course of action would be, in the short term, encourage non-pennying solvers to engage in that race to 0 (but we prefer the approach outlined here).

For this we were thinking to have a fixed reward per batch or order and then the variable “improvement” reward would be computed at the end of the accounting period based on the distribution of all improvements in the week given some fixed budget. I also like the random sampling between the top k solutions idea, alternatively we could provide a “runners up” rewards which should incentivise someone to report a good second outcome.

This is an interesting case, basically saying that slippage allows sophisticated solvers to protect less sophisticated solvers from making mistakes (instead of letting them win and live with their bad choice). It is true that there are currently still some “naive” solvers (mostly operated by Gnosis which aren’t operated in a strictly profit maximizing manner).

Note, that even with the given proposal it would be fine for the 1Inch solver to underreport the expected outAmount it may be getting if things go well (up to a point where it doesn’t violate baseline envy-freeness), it’s just not allowed to overreport. To me adding extra carefulness to your report is a much more reasonable use case than adding extra optimism.

This is a very interesting, pragmatic to implement, yet harsh, proposal. Do you think this would - on average - hurt the user in that solvers would have to underreport their expected outcome to avoid losing rewards?

From a protocol level it should still be our biggest priority to - on average - offer same or better prices than on any other DEX/ DEX aggregator in the space.

I don’t think this would count as pennying. You have access to some real liquidity that you are using to improve the price. In the mid-term any form of “private liquidity” could still be used to penny (it’s hard to argue what the “correct” price for a private market maker is) but until this point we still don’t have good private liquidity integrated (which in itself would be a net benefit for the protocol) and by the time we do hopefully we have a more accurate reward scheme.

4 Likes
15

Thanks for all the discussion so far. I will attempt to address some of the ideas above here.

  • Solvers submit batch as they do now, plus they quote a price they need to cover failed tx cost and net slippage if they win (this number could be negative, if slippage is expected to be sufficiently positive on average)
  • The solutions are ranked by objective - quoted price
  • The top solvers get the batch, the reward is the quoted price + difference in utility between top and second best solution

This is a nice and clean scheme. Of course, we still have to think about the dynamics of it, as it seems to me similar races to the bottom can happen here; a solver gets reimburses the difference in utility, which, for simple batches where pennying is utilized, will be some value between zero and the pennying amount. Of course, due to competition, the difference again might tend to zero, so you will be losing the pennying amount, so I am not sure how much difference this makes.

I like the suggestion of combining with some randomization. What we have called “bucketing” internally (i.e., putting all solutions with very close obj value in the same bucket and picking one at random, which is quite close to the “add gausian noise” idea of yours) might indeed help to at least reduce the effect of pennying.

but I do believe any solution should involve having the rewards set by the market more, instead of banning specific ways to exploit mispricing. The latter will just trigger an race to find new ways that might be even more negative sum .

This is definitely a very valid concern.

In particular, you could have one solver that has $0 slippage 99% of the time and -$1K slippage 1% of the time for an average loss of 10$ per transaction, while the other solver has -$1 slippage 99% of the time and +$99 slippage 1% of the time, which would create an average loss of $0. By the median logic, the latter solver is pennying, but we really should prefer it over the former.

For this, I am not convinced. I am not saying we should be happy with solvers being sloppy with such large amounts, since at the end of the day, the first solver only loses very real money, while the second solver might actually be using pennying to simply gradually push positive slippage to the users. From the users’ perspective, the second solver is indeed providing a service, but again competition-wise, the second solver might be manipulating prices and so it hurts the competition. An extreme case could even be that the second solver got this $99 positive slippage from a random token whose price simply happened to skyrocket within minutes, while the first solver got this $1k negative slippage within a few batches at a very volatile period where no other solvers were willing to play the game.

In particular, you’d want an efficient solver to detect when routing to 0x and pennying the difference in gas is more efficient than routing through 1inch after taking into account expected slippage and gas price and the rest of the batch etc.

This again is a very valid point, serving as a counterargument to what I said just above!

simply refund gas but don’t award any further rewards if there is negative slippage in the settled batch. The risk here is very straightforward to understand and manage for solvers, ie you just need to factor in that x% of the batches don’t deliver a reward if you report simulation on latest block, where x is small.

How would you ensure reliability of service here? If solvers haven’t accumulated much of positive slippage already, I suspect that solvers would simply avoid submitting solutions in quite a few cases. This is already a problem today, but I feel this would make things worse, since I suspect there are ways of “predicting” when negative slippage is more likely (i.e., it is not just uniformly random)

A possible mitigation might be locking cow rewards. Something like a 6 months lock, which would reduce the liquidity of cow rewards for the solver and making pennying more risky.

We could indeed have a more aggressive strategy, asking at least for some percent to be locked. We have to be careful though not to make this unprofitable at all for several months, since this would pose yet another entry barrier for external teams.

16

In this light, how many teams/persons are known to be working on a solver?
How many are in the test environment?

17

It’s Gnosis with a few solvers and 3 more teams with solvers in production. 4 more teams are preparing their solvers and currently participating in the shadow competition and at least 3-4 more teams have expressed interest.

1 Like
18

I don’t think the probability of moving is 50% for all batches, but let’s assume that worst case number. You can blow up rewards by 2x and get the same result on average. It will just take some batches to converge to the average. Solvers can’t participate without taking these kinds of bets anyways. A random fraction of batches will fail, and you have to swallow the entire transaction cost on those each time (could be much more than the reward).

The worst thing is negative slippage though, we have seen plenty of cases racking up 1000s of USD worth of negative slippage in a single batch. These can easily wipe out a weeks profit and then some. Of course, this problem can trivially be avoided by using an appropriate dynamic slippage management algorithm, writing bug-free code and not using incorrect data from bad APIs etc, but well… harder than it sounds. :sweat_smile:

Either way, harsh, but not harsher than the rules already out there.

This will definitely hurt the user compared to the status quo, but not necessarily more than other ways of forcing solvers to report the median. On the short term, users get worse prices because prices are not overreported. This difference should flow into the DAOs reserves partially through positive slippage and gnosis solvers becoming more profitable, and can be given back to the user at a future date. Part of it will exit the ecosystem to various places though: higher margins for external solvers, slippage kept by eg 1inch for the reasons outlined earlier, and part of it will be wasted on things like higher slippage limits to save batches that would be non-economical to save as there is no incentive to conserve those buffers.

With absolutely no data backing this up, my gut feeling is that the long-run impact of slippage is about the same order of magnitude as the cow rewards, with it being much smaller in horizontal periods and much bigger in volatile periods. So, it would be realistic though expensive to compensate for that loss with subsidies.

Of course solvers could report median minus something to increase the probability of making money if they win, but this comes at the expense of reducing the probability of winning the batch. The reason for this thread is that there is too much incentive for solvers to reduce the probability of making money to win more batches, so it won’t be a problem immediately. In either case such batches of the ‘rare but high impact’ type and until the rewards structure is updated, there is little incentive to tailor the algorithm to those cases because they are rare.

My conjecture would be that most of the batches where pennying matters have a very zero-inflated slippage distribution because they consist of 1 user order, hitting 1 or 2 AMMs. Of course some of AMMs get hit almost every block (like Uni V3 USDC/ETH 0.05%). But what choice do you have as a solver? If that pool is in the optimal path, someone is guaranteed to find it. You could use a different pool with lower chance of moving the price, but then you simply won’t win the batch.

It might make things slightly worse but it’s really a drop in the bucket compared to the effect of the mismatch between rewards and potential costs. Right now you get roughly 10$ reward for a 5$ gas cost transaction when nothing is happening and revert risk is <1%, while you get the same reward when things are super volatile, a batch cost 250$ in gas and 10% of txs are failing. In the latter case it’s really neither here nor there if you get 10$ in 90% or 10$ in 45% of the cases.

Btw, in the mechanism I am proposing accumulated positive slippage doesn’t really matter for the rewards. You only get the reward for the batch if there is no slippage at the batch level. The gas gets reimbursed either way. The idea being, if there is negative slippage you don’t lose money, if there is positive slippage, you make a fixed amount of money. If you have accumulated positive slippage you can of course be more reckless with slippage limits to make sure you revert less often, but you can’t use it to profitably win more batches as the reward decision doesn’t look at history. In fact not looking at history is the main point behind it. It removes possibility of being strategic with averaging things out over a longer time period.

(Emphasis mine)

Yeah this is a good point, and perhaps enough justification to just give it a shot.

19

Cool, I created a separate topic here not to pollute the discussion here. Also, agree that this bucketing idea would probably work equally well in practice.

1 Like
20

Ah right thank you for the correction. I forgot that Cow doesn’t pass that slippage on to traders.

Some really good points in the discussion here. I definitely agree that the reward scheme should be reworked to reward significantly better execution provided over just edging out the competition on a large number of batches. Randomizing when top solutions are very close seems like a solid idea but it only mitigates the problem partially.

In the short term, I support asking solvers not to penny and enforcing it in some way while more detailed proposals like randomizing and changing the reward scheme are discussed. As a new solver, I do not want to compete on uneven ground nor do I want to waste resources developing pennying strategies. I’m bullish on Cowswap and I believe we should be rewarded for providing actual value to users and the protocol.

3 Likes
21

Trying to summarize everyone’s points:

  • We all seem to agree that pennying is detrimental to the protocol.
  • There are more involved ways of inflating the objective that does not involve incurring negative slippage.
  • The long term solution should come as a redesign of the reward structure: possibly even some sort of reverse auction where solvers bid for the price they think their solution is worth

So this idea is more of a quick bandaid to try to keep the competition interesting, specially for new solvers just starting,

As a new solver, I do not want to compete on uneven ground nor do I want to waste resources developing pennying strategies. I’m bullish on Cowswap and I believe we should be rewarded for providing actual value to users and the protocol.

6 Likes