Second price auction is broken for small orders since CIP-74

[tokenwood]

TLDR;

• CIP-74 changed solver reward cap per order from 0.01 eth ($40) to the protocol fee (2 basis points)
• to remain profitable post CIP-74, solvers must introduce fees to break even
• these fees will get reflected in prices for users and a loss of competitivy for cowswap
• the current rewards are heavily concentrated towards solvers settling few large orders vs many small orders.

Disclaimer / context: I run the Fractal solver which has in the last few months been settling about 20% of cowswap trades and 5% of volume. I have seen my rewards reduced by 80% recently which is what has lead me to look into the problem I will explain here.

To remain profitable, a solver must have a positive reward expectancy. To place a bid on an order, a solver must ensure that if he wins,

E(total_reward) > 0,

which can be rewritten as

E(base_reward) + E(penalty) + E(slippage) + network_fee - gas_fees > 0

Solvers are free to set the network_fee as they see fit, but higher fees lower the order surplus and therefore the base_reward and their likelihood to win.

base_reward

The base_reward is the second price reward paid to solvers for winning a batch in the auction. It is defined in CIP-67 as
base_reward = max(min(score - reference_score, reward_cap), 0) where the reference score is the score (sum of order surpluses) that the auction would have without the solver’s bids.

CIP-74 changed the reward_cap from 0.012 eth to the protocol fee collected for that settlement, which generally 2bps (more if limit order or the prive improves from quote).

This means that the max reward for a $2000 trade went from $35 to $0.4 if we value eth at $3000.

penalty

I separated the negative base_rewards as “penalties”, so penalty = max(min(score - reference_score, 0), -0.01)

If a user wins a trade and doesn’t settle it within the time limit (because it reverts or doesn’t get included in time), the solver incurs a penalty as defined above.

slippage

slippage is the difference between the solver’s expected output for the trade and the actual output.

as this query shows, https://dune.com/queries/6371954/10133071 slippage tends to be negative for small orders, and positive for large orders. This is due to lower value order being settled more onchain and larger orders more through private liquidity.

reward expectation vs batch value

Combinding data from the previous dune queries, and fetching the /competition endpoint, I looked at 10810 Fractal won auctions with a single batch from 2nd of december to the 16th of december. I bucketed these batches by value and looked at the base_reward, penalty, capped reward, old reward (with a 0.01 cap) and expressed them in basis points. I joined each row with the slippage stats accross all solvers from the query above. Here are the results:

	uncapped_reward_bips	reward_cap_bips	old_reward_bips	capped_reward_bips	penalty_bips	slippage_bips	Capped_reward+penalty+slippage	Num batches
price_bucket USD
0–1k	22,09	13,13	22,04	7,84	-4,35	-5,62	-2,13	5311
1k–10k	8,04	5,32	7,37	3,49	-2,49	-2,74	-1,74	4266
10k–25k	5,29	3,79	3,42	2,10	-0,97	-0,71	0,43	584
25k–100k	5,81	3,27	2,14	1,65	-0,49	-0,15	1,01	495
100k–250k	5,01	2,82	0,78	1,43	-0,25	0,10	1,28	110
250k–1M	10,87	3,84	0,48	1,68	-0,07	0,12	1,72	43

This shows, for instance, that for orders betwek $1k and $10k, Fractal had on average 8bps of improvement over the 2nd best bid, Cow protocol earned 5.3 bps of protocol fees (after removing partner fees), the protocol paid Fractal 3.49-2.49= 1 bps in base_reward which after slippage resulted in - 1.74 bps profit without network fees. Pre CIP-74 with the old rewards capped at 0.01 eth, Fractal would have earned 7.37-2,49-1,74 = 3,14 bps . Fractal now needs to set a network fee of 4bps if it wants to generate an average of 2bps of profit, which will be reflected in prices for cowswap users. This is not a second price auction anymore, it’s a first price auction.

Without introducing a network fee, solvers expected profits are now NEGATIVE for trades below $10k. In practice, solvers have to set fees even higher to generate profit and be able to cover their costs. These fees will be reflected in prices offered to users which affects cowswap competitiveness.

In addition, when given sufficient rewards solvers can bid truthfully (at the amount they think they can obtain) to maximize the trade surplus for users. This is now no longer the case, solvers have to come up with fee models to profitably place bids on orders < $10k. (which represented 74% of cowswap batches between december 2nd to december 16th)

Centralizing effect on rewards in the solver competition

I aggregated at the uncapped_reward (surplus delivered to users vs 2nd best solver bid), the protocol_fees and the base rewards at a per-solver level in this query

If we look at the rewards from the 2nd until the 16th of december, cowswap earned 276 eth of fees and paid 93 eth to solvers, 72 of which to the top solver (even though it earned only 45% of the uncapped rewards, which is a measure of value provided to users).

We can see that the current reward incentives for solvers favor solvers settling few large orders vs solvers settling many small orders resulting in extreme concentration of rewards.

Suggested solutions

multiple things can be done to reduce this issue:

1 - add min reward cap

I suggest we introduce a min reward cap (at least on mainnet) per batch:

instead of

reward_cap = protocol_fee,

use

reward_cap = max(protocol_fee, min_reward_cap)

Which could be set around 0.005 eth (to be tuned properly by core team)

2 - reduce penalties (bring them back in line with the rewards)

instead of

max_penalty = 0.01

use

max_penalty = min(reward_cap, 0.01)

3 - cap solver rewards on a weekly level instead of per order

This is a bigger change that would need to be considered more carefully but would significantly improve solver rewards distribution:

instead of using

base_reward_per_auction = max(min(score - reference_score, protocol_fees), -0.01)

remove the per auction cap and add a weekly reward cap

base_reward_per_auction = max(score - reference_score -0.01)

weekly_solver_reward = min(sum(base_rewards_per_auction), weekly_solver_protocol_fees * factor)

where the factor is a tunable parameter.

The biggest risk of this approach is that it does introduce a previously present risk (pre CIP-74) of wash trading by solvers: they could create their own orders, settle it themselves at high surplus value, lose the protocol fees but gain more than what they lose at the expense of the protocol. I believe this risk is limited as there are two mitigating factors:

• wash trading profits it would be limited in value to the difference between solver rewards and protocol fees * factor.
• So a solver who doesn’t generate protocol fees couldn’t benefit from it.
• solvers have significant bonds that would be slashed if they behave in a dishonest way.

Therefore I doubt it would be an issue in practice.

[marco_at_quasi]

Hi Tokenhood!

Thanks for the post. It seems clear that CIP-74 changed the rewards distribution in a way that favors large trades, and consequently those solvers that have an edge on settling them.

However, I suspect that this was intended. That is, that what we see is a consequence of a strategic decision rather than a “broken second price auction”, if by “broken” we mean “not doing what is intended”. CIP-74’s title is literally “Align Solver Rewards with Protocol Revenue”, and more specifically revenue coming from volume fees. So if we look at revenue only, can we say it did not fulfill its purpose (not an rhetoric questions, perhaps we can measure this) ?

But maybe there is another layer to this discussion. Is COW protocol a strictly revenue-oriented protocol? And if it is, are we maximizing current revenue will maximize future revenue?

If any of these are true, then perhaps we’re witnessing a “kodak” moment - finding routes that strictly go through public liquidity will be reserved for long tail circumstances, like new/rare tokens or market conditions that are not profitable for mm. We will see decreased revenue for most of the solvers, and much higher variance on the weekly payouts, which might prompt solvers to either move on or adapt. And perhaps that is intended?

[harisang]

Thanks a lot to both @tokenwood and @marco_at_quasi for kickstarting the discussion (see also this post by @marco_at_quasi → Thoughts about second price auction in case of reverts ). I would suggest we try to keep the discussion in this thread and not split it into two separate ones.

Preliminary thoughts

A few preliminary thoughts on my end. Disclaimer: I am still trying to get a better understanding of the implications of CIP-74, and so i will share some thoughts, but nothing very conclusive yet.

Truthfulness

I will start by questioning this statement

This is not a second price auction anymore, it’s a first price auction.

The goal has always been to have solvers truthfully report their evaluations and not making them guess/try to learn what the competition is doing. I would argue this hasn’t changed with CIP-74. Say I am solver and I see an order that I can settle with onchain liquidity and generate $10 of surplus. If I know the rules of the game, and I am aware my solution will revert with 50% chance, I claim that my true evaluation is not $10, but rather it is $5.

What I want to claim here is that truthfulness doesn’t really mean completely disregarding the fact that nothing will move onchain, and it also doesn’t mean that I am optimistic and hope that losses/reverts/slippage here and there will be mitigated by me getting rewarded on other auctions. If I view each auction independently, then, as is also mentioned in the original post, I want to ensure my expected profit is non-negative. I don’t know the competition, i don’t control it, and ultimately, i shouldn’t care about it. I would even say that I should make a worst-case assumption of perfect competition, i.e., no rewards. In that case, i should bid such that even with zero rewards, i should be fine on average.

Of course, I acknowledge here that estimating the probability of getting negative slippage, or ultimately a revert, is a hard problem, but nevertheless, by only focusing on these and not caring about the competition does help maintain this sense of truthfulness.

Concretely, I would rewrite your original condition by setting base reward equal to zero. The penalty is capped by max(-0,01, -my_score), and so everything then is “controlled” by the solver and not the competition.

To make my point even more explicit, I would urge you to think of the case where the rewards would always be negative; ie. assume as a thought experiment that for every batch you settle, you need to pay 1 dollar to the DAO. Even then, one would claim that truthfulness doesn’t break; you should still aim for non-negative expected profit, which would simply mean that you need to reduce your bid by (at least) 1 dollar.

I feel this is an aspect that is still missing from certain solvers, although again, i acknowledge this is still not an easy evaluation to do, and also solvers can become carried away by more aggressive solvers that disregard this aspect. Nevertheless, I claim that more accurate (which in many cases would mean more conservative) bids, could lead to solvers winning fewer auctions but also becoming way more sustainable.

Impact on users

In practice, solvers have to set fees even higher to generate profit and be able to cover their costs. These fees will be reflected in prices offered to users which affects cowswap competitiveness.

I fully agree with that, and this is something that we should definitely think seriously about. Per batch viability on the protocol and solver side means that we push more costs to the users. I would still hope that our competition is efficient enough so that the impact would be minimal, and the benefits (very reliable and good executions on the vast majority of token pairs and volumes) would outweigh a small fee for the service provided.

Competition sustainability

At a high level, as @marco_at_quasi stated, the goal of the CIP was to finally get to a place where the competition over all chains the protocol is operating on is sustainable and is not a gamble, from the DAO’s point of view. And unfortunately, this has not been the case prior to CIP-74, where we observed profits in certain chains combined with significant losses/subsidies on other chains.

Of course, strong competition and good executions is still the primary goal, and I hope the CIP is not perceived as just a revenue-maximizing process.

Slippage

Regarding your points about slippage, I think it’s a very interesting topic and there might be more to look into. From a quick query we did, it seems that average you computed doesn’t apply uniformly to all solvers. Some solvers seem better at handling slippage than others, and this might have to do with: more conservative bidding, faster executions (first block instead of second or third for mainnet), reduced usage of buffers, trading meme tokens vs tokens with lower volatility etc. So I cannot really draw any confident conclusion from your query.

Concentration of rewards

This seems to be indeed a valid concern. We definitely not view 2-3 solvers as the only ones worthy of rewards; such a view is very dangerous as it can lead to centralization and in the long run, reduced and worse competition.

Next steps

Given your findings, as the core team, we commit to digging very seriously into all the data we have, so as to gain a better understanding of which buckets of trades (token pairs, volumes etc) have been more negatively affected by CIP-74, and try to work out a solution with solvers. If needed, a revision of CIP-74 will be executed by end of January or early February the latest. Specifically, we will definitely take the following into consideration:

• modifying penalties
• allocating part of revenue to bring back consistency rewards that will reward solvers that reliably provide good (even if they are not winning) bids.
• making the auctions even faster so as to reduce the effects of volatility.

Comment on @marco_at_quasi’s post and suggestion on reference score

Given what i mentioned above, the reference score should, ideally, already account for the revert probability, in the sense that each solver should bid its expected score and not the “full score”. In practice, this doesn’t happen, but still, as a solver controls their own bids, by incorporating this revert risk into one’s bid, one can ensure that on expectation they do not lose.

[marco_at_quasi]

Thanks Haris!

I think these are two separate issues: there’s the CIP-74 consequences, in this post, and there’s the penalties issues I raised on the other post, which are pre-CIP-74. Possibly the former makes the latter more apparent, but I don’t think it changed anything. I’ll stick with your suggestion and reply here, but I’d like to focus only on the penalties.

the reference score should, ideally, already account for the revert probability

I agree, as it is, things work on expectation (an variance-wise too).

Thought experiment: Imagine that you could prove, that for the N solvers that submitted a solution to an auction, all of them would have reverted, not because there was something wrong with their solutions, but because someone payed for a CEX arbitrage worth 10x more than the 1 ETH order on cowswap. Do you think the protocol should still charge a penalty in that case?

My point is that a solver can only do so much with what it is given (the order volume). There are externalities common to all solvers, and when all solvers learn to “price the penalty” game, they will be passed, as fees, to the user. Why would a user pay for the CEX-arber event, that even happened in some other auction?

(Sure, one can argue the CEX-arber can come and work as a cowswap solver, but until cowswap dominates the world, let’s find an interim solution )

For reference: the original post.

[notsoformal]

While I can’t really bring added value to the technical discussion - which I think it is a very relevant one, the Protocol should aim to make participating, profitable for solvers that have a “good performance” (indep. of how this is categorised), but want to bring to the attention that the optimisation exercise should be extended from “just” a partial equilibrium of the solver side, but as a wider system, where:

1. The protocol ideally gives the better prices in the market to users;
2. Solvers maximise their profit;
3. The protocol in itself is sustainable (e.g. generates a higher than 0 profit to ensure coverage of ongoing maintenance and a minimum level of expansion / R&D)
4. There is a sufficient excess that can be shared with tokenholders, ensuring attention to the token.

[tokenwood]

To respond to @marco_at_quasi, it is true that “broken” is a strong choice of words and that it may have been intentional. And maybe it is a coherent move if Cowswap thinks it should focus on the large order market. But I think Cowswap should aim to be the best place to trade onchain no matter the order size or type and I’d like to make sure we understand fully the second order effects of CIP-74.

To respond to @harisang, I’m glad to hear the Core team is taking this seriously and I look forward to the proposed changes. I think reducing penalties could be a big step in the right direction and some kind of consistency reward could significantly help with reward distribution. I also agree that slippage is ultimately the solver’s responsibility since different routes haver different risk profiles and that the risks management should be included in the solver’s bids.

In that case, i should bid such that even with zero rewards, i should be fine on average.

Here I disagree. It’s like saying all poker players should play defensively. A solver wants to maximize E(total_reward), not E(total_reward | base_reward = 0). And since a solver is free to set the network_fee, he is actually trying to maximize E(total_reward | network_fee). And the reward cap has an impact on the network fee that maximises the reward expectation.

Let’s take a simple example: a solver is trying to settle a sell order of 0.3 eth for at least 1000 USDC and let’s ignore gas fees and penalties. He finds a route that yields 1010 USDC.

In an uncapped second price auction, the solver and the user’s interests are perfectly aligned: the higher the bid the higher the rewards. The solver can bid 1010 and that should maximize his returns.

In this case however the reward is capped at 2bps so 0.20 USDC. And he knows his won bids are on average 10bps (1.0 USDC) higher than the 2nd best bid. So it is now in his interest to set a network fee to maximize profit (around $0.80, he’d have to look at the reward distribution and how this affects his win rate to configure exactly). So he ends up bidding $1009.20, and it will have cost the user 10bps of fees, not 2.

So I encourage the core team to track how solvers are modifying their “network_fees - gas_fees” pre and post CIP-74 (and by volume amounts) to see the real effect CIP-74 on prices offered by Cowswap to its users. I would expect solvers will take some time to adjust though.

Finally to respond to @notsoformal, I agree that this is about more than just solver equilibrium. But if anything I think the data shows that with the right incentives there is room for both protocol and solvers to make money without users paying more than the 2bps volume fee.

[Wraxyn]

Hello from Wraxyn.

I agree with @tokenwood’s assessment - since CIP-74, the solver economics for small orders is largely broken. With rewards now effectively capped by protocol fees, fills below X thousand USD are no longer economically attractive unless additional costs are passed on.

As a result, we’re starting to filter out orders below a dynamically set minimum threshold - currently in the several-thousand to low five-figure range, which we expect to adjust (and likely increase) over time.

As quoting & solving are aligned, it obviously means there’s no incentive to quote those orders as well (even though we technically can quote & settle them, it’s just to risky to try)

We’ll need to evaluate whether re-enabling solving and quoting for smaller orders makes sense at all and if it does, it would come at the cost of materially worse quotes.

This inevitably shifts solver focus toward larger orders and leaves small trades underserved, which seems like an unintended side-effect worth addressing.

[Wraxyn]

Replying to @marco_at_quasi

I still think that the idea that “small orders are unprofitable for solvers” seems to miss the fact that solvers themselves create the reward opportunity. The reward is a function of the difference between the limit price, created by solvers when quoting, and the second best price, also defined by solvers. Solvers are free to internalize whatever fraction of surplus they need to offset the fact that the reward is going to be capped. Even a reward of zero can be profitable for a solver, right?

Very hypothetical thought: Imagine that everyone here agreed that for orders less than 10 ETH solvers would relax the quote by x% less. Would that still lead to small orders being unprofitable?

I am not saying there is not a problem. But I think the real issue is the mechanism is somehow failing to give us this “coordination” lever for free. In particular for small orders, I think they are difficult to settle due to solvers mispricing its reward/penalty ratio. And this is happening due to a combination of

• when quoting or even solving solvers don’t know neither the reward nor the penalty, and is difficult to do risk management without them
• reverts seems hard to predict
• depends on second best solution, which probably is mispriced as well

But maybe I am missing something.

I agree with the theory, but I think this is where practice diverges quite a bit from the model.

Yes, in theory, if all solvers coordinated to charge higher effective fees on small orders, the system could converge to a new equilibrium where those orders remain profitable. In practice, that’s very unlikely to happen. Solvers have different risk tolerances, cost structures, and objectives, and there’s no shared coordination mechanism to align behaviour.

On top of that, solver strategies are constantly and independently adjusted. Any change by one solver influences the competitive landscape and can force others to react, often in unpredictable ways. Since solvers don’t share internal logic, pricing models, or risk parameters, this quickly turns into a moving target rather than a stable convergence point.

Some solvers haven’t updated their strategies post-CIP-74, so they’re still quoting aggressively on small orders without “properly” accounting for the reward cap, penalties, and slippage.

If we implement proper risk management and quote conservatively (with higher fees to offset the limited reward potential), we simply don’t win those auctions - we just waste computational resources solving and submitting bids that never get selected. Our “correct” pricing becomes theoretical profit that never materializes because we’re outbid by solvers who haven’t adjusted yet.

The choice for a solver on small orders becomes:

1. quote conservatively - be safe but not win,
2. quote competitively - win, but take asymmetric downside due to capped rewards, uncertain penalties, and revert risk.
3. don’t quote at all

CIP-74 has effectively created two different auction mechanisms:

1. Large orders (~ >$10k): Solvers are incentivised to improve prices as much as possible to capture CoW rewards - “be as good as you can”
2. Small orders (~ <$10k): Solvers are incentivised to worsen prices just enough to stay profitable - “be just good enough”

[Cheng]

I strongly agree with the proposed solution. Due to the cap on rewards, small orders are effectively treated as having no value—at least from the solver’s perspective, they tend to be ignored when submitting solutions because the reward is insufficient.

CIP-74 adjusts the reward cap to be non-fixed, but does not make a corresponding adjustment to the penalty cap. This leads to a mismatch between incentives and penalties, especially when executing small orders: the upside drops to near zero, while the risk remains high. Here, the risk refers to penalties incurred when a submitted solution fails to execute due to on-chain state changes or uncertainties in RPC nodes.

As a result, when facing small orders, solvers—acting in their own economic interest—will either choose to filter out such orders or lower their quotes to hedge against risk. Either approach is unfriendly to users submitting those orders. Small-size users may therefore turn to standard AMM aggregators instead to execute their trades on cowswap.

For these reasons, I am in favor of appropriately reducing penalties and increasing rewards to better balance the asymmetry between solver risk and return. I also hope that such changes would elicit a more positive response from solvers—encouraging them to merge a large number of small orders into a single transaction—thereby reducing user trading costs and improving the overall user experience.

[Cheng]

In addition, CIP-74 only adjusts the solver reward cap to be tied to the additional protocol fee (20 bps). In practice, this does not significantly improve incentives for solvers that rely on public AMM liquidity to generate quotes.

For example, consider a very large order whose liquidity is entirely sourced from public pools. In such a case, all solvers are likely to submit the same price. Even though this trade can generate substantial protocol revenue, individual solvers receive very limited rewards because there is no meaningful price differentiation between solutions. The reward mechanism remains highly dependent on relative price improvement rather than absolute value contributed to the protocol.

In contrast, solvers with access to private liquidity are much more sensitive to large orders. They can create price differentiation and therefore effectively unlock a much higher reward ceiling under the current design.

As a result, large orders routed through public liquidity may generate significant protocol fees, while contributing little incremental incentive to the solvers who actually execute them.

One possible improvement would be to introduce a minimum guaranteed reward for solvers that is directly tied to protocol revenue per trade. For example, allocating a fixed percentage (such as 10% or 20%) of the protocol fee generated by each transaction as a base reward for the solver. This could better align solver incentives with protocol revenue, especially for large trades where competition is price-neutral.

[harisang]

Thanks for all your comments and suggestions . Will make sure to properly read all of them. I am just posting a follow-up for now to update that we are planning to heavily focus on this in the next 2 weeks.

And in the meantime, I will try to clarify some things that might have not been very clear (or were potentially mixed together) in my previous post.

I agree with @marco_at_quasi that the issue of penalties is separate from CIP-74. But I think it makes sense to treat everything at the same topic so that we all try to reach some sort of consensus about what are the problems of the mechanism, what is preventing solvers from being truthful etc.

I raised the point of truthfulness with regards to penalties, and I will still say that a truthful bid should take into the revert risk into account and pass it as a fee to the user. And this indeed has nothing to do with CIP-74, as the same penalties were around as before. Whether this is too much of a burden for users is a good question. But this is what i had in mind when i was referring to truthfulness cc @tokenwood.

Without introducing a network fee, solvers expected profits are now NEGATIVE for trades below $10k. In practice, solvers have to set fees even higher to generate profit and be able to cover their costs. These fees will be reflected in prices offered to users which affects cowswap competitiveness.

I would reiterate here that a solver can bid truthfully and not be on the negative, and that the previous equilibrium was working for certain solvers just because their overbidding was balanced out by the price improvements they were providing here and there and rewards they were receiving. Given that rewards fully depend on how strong or not the competition is, I would argue that such an equilibrium, although it seems to be “ok”, isn’t really reasonable (e.g., what would happen if for small trades, a solver very similar to Fractal joined the competition? Maybe Fractal wouldn’t notice due to profits from larger trades, but still it would mean that Fractal would be on the negative for smaller trades, which indicates that inaccurate bidding/overbidding was already ongoing). In other words, I used truthfulness to refer to the fact that without any assumption/expectation about the competition and potential profits a solver might have, a solver can participate and bid “honestly” such that on average, it is not losing money.

Of course, as @tokenwood said, a profit-maximizing solver (i assume all teams are such!) is affected by the cap, and especially about how frequently it gets hit, and this does mess with truthfulness. Even before CIP-74, there was an upper cap, but the percent of auctions it was hit was relatively low (less than 10%). We are planning to put together a comprehensive dashboard analyzing various metrics around the competition during the next week, in order to observe how frequent the cap is hit, depending on batch sizes etc. And if indeed we have a very large percent of small volume batches being hit by the cap, then I agree with @tokenwood ‘s claim that such batches are now turning into a first-price auction rather than a second-price auction (and so truthfulness collapses).

Something very relevant as well is the following comment by @Wraxyn

Some solvers haven’t updated their strategies post-CIP-74, so they’re still quoting aggressively on small orders without “properly” accounting for the reward cap, penalties, and slippage.

Indeed, solvers can, even unintentionally, overbid and mess up with the competition and the more conservative bidding of other solvers, so that’s a very good point to keep in mind. I admit I don’t have any decent suggestion for this one at the moment.

One possible improvement would be to introduce a minimum guaranteed reward for solvers that is directly tied to protocol revenue per trade. For example, allocating a fixed percentage (such as 10% or 20%) of the protocol fee generated by each transaction as a base reward for the solver. This could better align solver incentives with protocol revenue, especially for large trades where competition is price-neutral.

We have observed in the past that allocating fixed rewards for winners actually pushes to overbidding, so although i haven’t thought about this much, I expect it would have the same effect. What this means is that if all solvers believe they will execute with the same price, more or less, but the winner will receive, for example, at least $100 (say the protocol fee will be $1k and we allocate 10% to the winner), then in anticipation of this fixed reward, solvers actually start overbidding and passing this reward to the user (meaning they return more to the user by paying from their own pockets as they will get this back from the protocol)! (Context: back when the competition started, we used to have a fixed reward per batch, and most solvers started overbidding at some point in order to claim this fixed reward)