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

[felixhenneke]

@harisang

One problem that both @tokenwood and @felixhenneke have already picked on is that although you don’t know this F, with high probability you know you will get capped at the end of the week (even if the scaling factor is generous enough). And this can make a solver switch bidding behavior as then they can act as if every auction is capped, leading to the agruably cleaner mechanism that we have now (modulo the scaling of the protocol fee cap).

Let me also comment on why I think the proposal on capping by aggregate fees collected per solver dose not increase profitability of small orders.

From the query @harisang posted above, if we cap rewards by 50% of aggregate protocol fees, with few exceptions, the payments to solvers would just be that 50% of protocol fees. This means that a solvers increases their payment for winning an auction by 50% of protocol fees collected in that auction, and not by anything related to our current second-price reward. That means that every auction throughout the week would be a first-price auction with a fixed reward given by 50% of protocol fees.

This would severely change the character of the mechanism. It is probably equivalent to a first-price auction without rewards and a 50% smaller fee for users. This is a mechanism we are considering, potentially in combination with an incentive rewarding consistency. Besides solvers typically preferring a second-price reward scheme, the first-price auction alone also does not seem to address issues of profitability of small orders.

[xozzslip]

Have you considered subsidising the reward cap for orders? There could be an algorithm that sets a per-order reward cap bump (similar to how protocol fees are calculated). The exact value of the subsidy could depend on the unspent budget, order volume, competition level, and so on. This algorithm could also take into account orders that CoW isn’t interested in subsidising at all—like certain L2 bot orders that had unfairly large rewards pre-CIP-74. Then the auction reward cap could be calculated as protocol fees plus these per-order bumps.

The question with consistency rewards is what share of rewards would actually be distributed via consistency. If it’s a small amount, it won’t solve the underlying issue that our solver (and others, I guess) is sometimes barely profitable while generating ~7-10× more revenue for CoW. That doesn’t seem great. If it’s large, then why should our advanced solver effectively share profit with other solvers that are just providing unused bids that are low and maybe even non-executable?

@harisang @marco_at_quasi @felixhenneke

[felixhenneke]

Have you considered subsidising the reward cap for orders?

We have thought about approaches subsidizing certain orders via larger caps, though not exactly what you are proposing.

This algorithm could also take into account orders that CoW isn’t interested in subsidising […].

Finding a way to aviod subsidizing undesirable trades is the core problem we tried to address with CIP-74. We did not find a simple approach which is better than capping at protocol fees. Having a more complex algorithm as part of the core reward mechanism sounds riksy. If you have a more concrete sugeestion, we can do some backtesting.

One general problem with approaches related to again just modifying our current second-price type mechanism is that it does not solve current issues with robust service provision across networks and token pairs. One paradigmatic example being the routing through a converter contract between tokens with a fixed exchange rate. There is typically little value in implementing such an integration for solvers, but significant value to the protocol in terms of securing integrations. No change to caps can change that. But the protocol and other solvers profit a lot from such integrations as they drive large volume on more standard networks and token pairs.

Rewarding a consistent service more explicitly sounds desirable to me. How that can be measured is not clear, though. We are currently experimenting with different metrics, for example

• the bare or the marginal change to the number of orders executed,
• point based systems where the best few solvers per order get points and are rewarded proportionally, or
• marginal change to expected scores where the latter means scores in the sense of a probabilistic counterfactual with solvers getting removed based on their overall participation rate.

These approaches vary in how easy they can be gamed and in how much they actually capture the value of a solver in the competition.

The question with consistency rewards is what share of rewards would actually be distributed via consistency.

We are currently thinking about aiming for 50% of protocol fees to be paid as rewards - around 75% should be performance rewards, 25% consistency rewards - with a mechanism to keep those numbers stable. On certain chains we might additionally increase the absolute consistency budget.

If it’s a small amount, it won’t solve the underlying issue that our solver (and others, I guess) is sometimes barely profitable while generating ~7-10× more revenue for CoW.

Based on what you are saying, the total protocol fee or the marginal change to protocol fees collected per solver seems a relevant metric to you. It should be interesting to look at this metric.

If it’s large, then why should our advanced solver effectively share profit with other solvers that are just providing unused bids that are low and maybe even non-executable?

Submitting bids without the intention/ability to execute is indeed one possible way to game certain metrics for consistency. We have not observed that in the past with consistency rewards between CIP-20 and CIP-48, but it can definitely happen in a more hands-off setting with lots of solvers. One approach is to reward only the best few bids, so that there is a real “risk” of winning for anyone receiving a reward (e.g. the point based approach mentioned above).

[tokenwood]

Hey @felixhenneke and @harisang , what do you think of this proposal that combines my proposal #1 and @xozzslip 's:

Instead of the current per-transaction reward being capped at the protocol fee, add a lower bound to this reward cap that is computed retroactively at the end of the week in a way that 50% of the fees are paid as rewards.

so something like

reward_cap = max(protocol_fee, min_reward_cap)

and

min_reward_cap = argmin(x) |sum(rewards(x))-0.5*sum(protocol_fees)|

It’s not trivial to compute that lower reward bound but doable, like by querying a for a range of values and interpolating or doing some form of gradient descent.
Solvers will not know exactly where that reward cap will land, but I’d argue it’s strictly better than the current mechanism, and it could be somewhat stable week over week.

[felixhenneke]

@tokenwood

a lower bound to this reward cap that is computed retroactively at the end of the week in a way that 50% of the fees are paid as rewards

I guess there are different ways to implement such a rule. One way is what @harisang did above in this dune query, with a budget of 50% of protocol fees per solver.

One problem with this is that in practice it just turns into a first-price auction. The cap per auction is a bit misleading, as the overall payment in typical weeks is just 50% of protocol fees. Solvers are not actually paid more for settling small orders.

Another problem with any such approach tweaking our current performance rewards is that a certain form of service which is valuable to the protocol (e.g. redundancy, support for trades which are difficult to monetize, solving on smaller networks) is not rewarded.

When reasoning about the different proposals, we check, e.g., the following things:

• Does it change the game theory (much)? Can a solver still participate by essentially ignoring other solvers?
• How easy is it to game the mechanism? Can arbitrage bots mess with rewards or are malicious solvers required for that?
• Can we keep rewards somewhat stable at a fraction of fees? E.g. 50%.
• How are users affected? Will they get better or worse prices on average?
• Does supporting small orders generate profits for solvers? E.g. by looking at counter factuals where all solutions with small trades are removed for a solver.
• How close is it to other metrics for measuring the value of a solver to the protocol (e.g. number of orders settled, volume settled, revenue generated)? How concentrated is the distribution of rewards?

I have not seen a proposal which is better in all aspects. For example, the proposals around consistency rewards we are currently thinking about are better at encouraging consistent service and worse in terms of gaming.

[tokenwood]

In the query from @harisang you shared above, he removed the current per transaction cap and only caps at an aggregate level, which as we have seen results in a first price auction for most solvers. What I am suggesting here is to keep the current per transaction cap in place, so it stays a 2nd price auction below that cap, but add a lower bound to the cap in a way that cowswap doesn’t spend more than 50% of protocol fees on solver rewards. This does not turn into a first price auction, it actually increases the number of orders for which it is a 2nd price auction compared to the current system.

To go over your list:

• game theory is barely changed
• the rewards would be stable since they would be exactly 50%
• This proposal would increase profitability of small orders since small orders will be able to generate higher rewards, which will result in lower fees for users.
• arb bots can possibly exploit the lower bound being higher than the fees, but the exploitable amount is small (it stops at 50% of protocol fees). I don’t see a way around this if we want to be able to reward small orders more than the protocol fees (which are almost nonexistant for small orders).