CoW Native AMMs (aka Surplus Capturing AMMs with single price clearing)

,

In this post I want to present an idea that was loosely discussed with various people in the past (mainly during ETH Bogota) and which could present a new way of building AMMs that protect their LPs from MEV.

Context

For context, liquidity providers (LPs) in automated market makers (AMMs) suffer from maximally extracted value (MEV) by arbitrageurs that incorporate outside information (e.g. price moves from centralized exchanges). The reason this is causing damage to LPs is a concept that Tim Roughgarden et. al coined LVR (loss versus rebalancing).

While LPs receive a fee for each trade, an arbitrageur will only trade against them if the gain they get from incorporating this information is strictly larger than the LP fee + gas costs. Thus LPs lose money compared to if they were actively rebalancing their portfolio themselves.

The permissionless-ness of swaps creates a race for whoever gets to update the AMM first, leading to most of the arbitrage value being paid in the form of priority fees to the miner/validator instead of the LP.

It is estimated that 60-80% of DEX trading volume today stems from this activity. Overall it’s hard to find studies highlighting that LPing on AMMs is profitable these days (cf. this lively twitter debate from this weekend).

There have been suggestions in the past on how to more fairly capture the MEV that comes from LVR for the LPs (rather than the validator). Those include:

  1. MEV capturing AMM (McAMM) - Applications - Ethereum Research (by our very own @Cowry): LP auctioning off the right for first execution in a block to a designated party
  2. https://arxiv.org/abs/2210.10601: more concrete implementation of 1)
  3. MEV Minimizing AMM (MinMEV AMM) - Applications - Ethereum Research - block producers “tip off” AMMs what the appropriate after block equilibrium price is

Particularly 3) is very similar to the idea I will be presenting here.

Traditional AMMs

Traditional AMMs, such as Uniswap, SushiSwap and Balancer follow a simple but exact trading formula. If the price of ETH is currently $1300 and someone wants to buy 10ETH, they will buy the first couple of wei at a price very close to $1300, the next couple of wei at a price close to $1301, then $1302 and so on until the order is filled.

Graphically speaking, if a trader moves the AMM from “previous marginal price” to “new marginal price” they end up paying a price that is roughly the average between the two (not exactly, but in practice this turns out to be a good enough intuitive approximation).

Assuming the trade moves the AMM price to $1310, the trader will on average only pay ~$1305 (for every wei bought at $1301 they bough one at $1309 as well). The difference between the average execution price and the new (presumably fair market) price is captured by the trader and not by the LP in that case. We refer to this extra value - $50 in the example - as surplus.

This surplus distribution rule also applies in CoW Swap trades (when trading against standard AMMs). This is because the protocol aims to offer trades prices at least as good as other DEX aggregators, which do pass that surplus on to their trader.

Let’ take a concrete CoW batch as an example (we omit AMM fees for simplicity):

  • User A buying 100 ETH for USDC
  • User B selling 50 ETH for USDC
  • AMM with ETH at $1300 (buying 50 ETH will move the price to $1310)

The outcome of this batch would likely be a clearing price at $1305 (trading 50 ETH peer to peer and buying the excess 50 ETH from the AMM, giving user A and B the average execution price of the AMM).

It can be argued that this solution is not “stable”, because

  1. If the fair price of ETH was indeed $1305 but the AMM had been moved to $1310 this would open an arbitrage opportunity for someone to correct the AMM price back from $1310 to $1305.
  2. If the fair market price of ETH was indeed $1310 User B might be frustrated having sold ETH at $1305. Not getting the new equilibrium price creates an incentive to try to avoid “trading against the wind”. It may not be feasible to avoid this reliably in practice (and in expectation may not be an issue to the mechanism itself) but it still leads to unstable outcomes (people preferring not having traded in the batch).

Note, that the LVR for the AMM in case 1) would be ~$60 (while the initial trade happened at the fair $1305 price, the “correction” would be ~25 ETH at ~$1307.5 average price) and in case 2) $250 (“fair” price being $1310 average price being $1305)

Surplus Capturing AMMs

CoW Protocol’s general vision is that there should only be a single price per token per block. After all, ordering dependent asset pricing within a single block is what is causing LVR, backrunning and sandwich attacks. That price should ideally be an equilibrium price where demand equals supply and all agents end up with their preferred allocation at this price (no one is envious to trade more or less).

I therefore think it would be nice to have an AMM primitive that fits into this vision. CoW Swap is already creating a single uniform price vector per batch (one where demand equals supply for CoW Swap users while maximizing their surplus). What if an AMM’s trade would be entirely executed at that equilibrium price (rather than at slowly increasing prices over its curve)?

In the example from above the new outcome would be a clearing price of $1310 (trading 50 ETH peer to peer and buying the excess 50 ETH from the AMM for $1310). Note, that this would give the AMM $250 in “surplus revenue” turning it profitable for LPs even in the absence of trading fees (I don’t want to say no trading fees will be needed at all but I think they can be much lower than in today’s AMMs).

One reason that such a pricing function isn’t working in traditional AMMs is that a trader could split their trade into many tiny transactions each increasing the new spot price only by a bit, therefore effectively sampling the behaviour of tradtional AMMs (buying a few wei at 1300, then 1301, etc).
In CoW Swap however, since there is only one price per batch, such an “attack” would have to be carried out over many blocks (making it much less practical in the presence of “real” trading demand).

For regular users (noise traders) it could be cheaper to trade against such an AMM because the LPs can afford to charge a lower swap fee than competing AMMs (due to less toxic flow & price finding).
At the same time LPs would be protected from LVR (they always trade at the new equilibrium price). Overall volume may be significantly lower than in traditional AMMs due to the fact that arbitrage is slower and limited. However, I still think it could overall be more profitable for LPs to engage in this mechanism.

Implementation

One way to implement such an AMM would be using the new Smart Order primitive that ERC1271 powered orders enable.

Unlike regular AMM interactions these orders are subject to single price clearing and are therefore executed at the same price as all other user orders. A smart order can defer the correct quantity and price finding to a solver and - when asked to trade - only perform a check if a given price and quantity are satisfying its CFMM preference curve. The solver would be able to use this price curve in its computation and would - if applicable - create a “just in time” ERC1271 order on behalf of the smart order with the correct amount (the price would be the same as for all other orders).

Concretely, the smart order would implement ERC1271 something like this:

function isValidSignature(
  bytes32 hash,
  bytes calldata signature
) external view returns (bytes4 magicValue) {
  GPv2Order.Data memory data = abi.decode(signature, GPv2Order.Data);
  require(hash == data.hash(domainSeparator), "invalid order");
  require(this == data.receiver, "invalid receiver");

  uint256 k = token_a.balanceOf(this) * token_b.balanceOf(this);
  if (token_a == data.sellToken && token_b == data.buyToken) {
    require(k <= (token_a.balanceOf(this) - data.sellAmount - data.feeAmount) * (token_b.balanceOf(this) + data.buyAmount), "K violated");
  } else if (token_a == data.buyToken && token_b == data.sellToken) {
    require(k <= (token_a.balanceOf(this) + data.buyAmount) * (token_b.balanceOf(this) - data.sellAmount - data.feeAmount), "K violated");
  } else {
    revert("invalid token pair");
  }
  magicValue = ERC1271_MAGIC_VALUE;
}

The “signature” passed into the verification function is the encoded preimage of a limit order that satisfies the AMM’s demand curve (think of it as the point on the curve where AMM demand intersects the excess user supply in the graph above).

The contract then computes its “k” based on current balances and verifies that after a swap at the proposed buy and sell amounts, the invariant is still satisfied. If this is the case it is guaranteed that the trade will at least be executed according to its demand curve (but can potentially capture extra surplus if the execution price is better).

Deciding on the correct limit order to pass in is a task that solvers would have to do as part of their solution finding (similar to how they decide the correct trading amounts for traditional AMMs). The main difference is that trading against surplus capturing AMMs would not happen in the form of “interactions” but instead as native CoW orders.

From the trader’s perspective, this type of AMM would just be an additional liquidity source to CoW Swap. If traditional AMMs offered a better exchange rate for a given trade size, solvers would still choose whatever price is best for CoW protocol traders.

It is also possible to implement this AMM as a “hybrid” CoW native AMM. The contract could still allow regular EOAs trade against it at will (no guarantee of uniform clearing price), but charge a significantly higher swap fee due to the increased likelihood of toxic trades.

We could also implement the original idea of McAMMs where permissionless trades are allowed only after the lead-searcher (in this case CoW Protocol) had traded first. In fact for other common aspects of AMM design (join/exit, LP tokens, etc) it’s probably best to piggy back on existing open source AMMs.

It would be cool to experiment with such a mechanism on CoW Swap today, so I’m hoping to spark a discussion and maybe find some interested community members to build a working version of this.

CoW DAO recently launched a Grants Program, which could be a good vehicle to fund this idea.

8 Likes

Hello! Thanks for the post.

I think you are misinterpreting LVR a little. LVR is defined as the amount of money that arbitrageurs can make off of LPs because LPs cannot (feasibly) update the quoted price in a CFMM when prices on a CLOB do continuously update. So in your example with a concrete CoW batch, you assume that noise traders have an effect on the amount of LVR extracted from LPs. This is a contradiction with the assumptions of the LVR-paper which states that arbitrageurs - not noise traders - will extract as much as possible: LVR. In both cases of the example the LVR would be equal because it is independent of any noise trades. In practice, any noise trader interacting with a CFMM will trade later than an arbitrageur, meaning that the noise traders trade against fair prices.

Even if you have a single price per token per block, LVR can and will be extracted from LPs, the extraction will just be smoothed out over all the relevant transactions in the block, effectively making all traders arbitrageurs because the initial price was not the market price, making LPs no better off. This is also where it can be shown that the assumption that ordering dependent asset pricing is the cause of LVR is not true, LVR is caused by the fact that LPs cannot update prices in a CFMM. Anthony Lee Zhang’s talk at a16z gives a super nice intuition about this: if you have a high-frequency perfect price oracle, LVR = 0 because LVR is basically defined as the difference between this case and the current case. With such an oracle, there is of course ordering dependent asset pricing. In fact, LVR is technically only defined for cases where there is ordering dependent asset pricing because it is currently only defined for CFMMs.

1 Like

Thanks a lot @fleupold for the idea! As you know I am very enthusiastic about this thinking and excited about seeing a LP pool for COW. I have some comments:

Assuming the trade moves the AMM price to $1310, the trader will on average only pay ~$1305 (for every wei bought at $1301 they bough one at $1309 as well). The difference between the average execution price and the new (presumably fair market) price is captured by the trader and not by the LP in that case. We refer to this extra value - $50 in the example - as surplus.

Isnt the average execution price for the buy order = the average execution price for the sell order? So the LP should not be capturing anything more. His average sell price is also $1305. In fact he is happy that his offer is now showing at $1310. Or am I missing something?

If the fair market price of ETH was indeed $1310 User B might be frustrated having sold ETH at $1305. Not getting the new equilibrium price creates an incentive to try to avoid “trading against the wind”.

I am confused why User B is not happy? His initial price that he was seeing is $1300! he should be grateful he even got $1305! (Thats because there was a much larger buy order in the batch) Or is it because he is naively seeing an advertised price post-trade of $1310 and feels he could have gotten a bit more?

For regular users (noise traders) it could be cheaper to trade against such an AMM because the LPs can afford to charge a lower swap fee than competing AMMs (due to less toxic flow & price finding). At the same time LPs would be protected from LVR (they always trade at the new equilibrium price).

Please correct me if I am wrong but as I understand you are saying that the user might get a better price if there are no high LP fees? So what we are doing here is giving LVR to the LP but giving the LP fees to the user. Which one is more? How do you know they would both be better off?
So in the solution you proposed the equilibrium price would clear at $1310 so the LP is happy because she is getting more than $1305 for her ETH, and User B is happy too. User A is not because they just overpayed. Also wouldnt the solver find the best solution to be the outside AMM that maximises the surplus for ALL the users at $1305? Unless the fees make up for the 5$ for User A then the solver would find your solution optimum. Is that what you are saying? If so, how do we model this fee vs LVR issue to get a conclusive answer?

On the implementation bit, it feels super neat that we can do a Uniform Clearing Price while also maintaining the CFMM preference curve. Its illuminates the beauty of smart orders.

Also in reference to the original LVR paper and the SBC talk, is they find that outside volatility is directly proportional to LVR. Their recommendation for minimising LVR includes:

  1. An improved pricing oracle to minimise the effect of toxic trades/adverse selection/opportunity cost (or simply LVR)
  2. Have dynamic fees that is a function of volatility (sigma).

Given we have a solver mechanism we do not need a pricing oracle as that role is played by the solver. So the solution above is indeed quite neat as it leverages the use of the solver as the most efficient pricing oracle.

By the way, this paper may be relevant if you are looking at designing socially optimal AMMs: [2103.08842] The Adoption of Blockchain-based Decentralized Exchanges

I don’t think this is true. Assume the price of FTX went from $15 to $5 in the matter of 12s, the CFMM still offers liquidity at $15, however in the next block they can only be accessed once at a single price (with the combined demand of the market at that price). What would that price be?
Arbitrageurs would likely be happy to still sell FTX at some price slightly above $5 so the “uniform clearing price” that LPs would receive would be close to $5.
Traditional CFMMs would buy at an average price of $10 thus creating much more LVR.

Why does it needs to be high frequency, if state updates can only happen every 12s? Assuming that price discovery happens on chain, the combined demand and supply for an asset in a block (noise traders, passive LPs, active LPs, arbitrageurs from other venues, etc) should pose such an oracle (CoW Swap’s core mechanism aims to find such equilibrium prices).

Adding the quoted presentation from Lee Zhang here as it indeed gives a very nice overview over how such a CoW native AMM would behave. CoW clearing prices are an approximation (the more order flow the more accuracy) of the perfect oracle he is referencing, because it aggregates total market demand and supply rather than letting everyone trade at different prices sequentially.

He also offers a way to simulate the behaviour which could help answer some of @mohammed’s modelling questions.

In both cases they are unhappy because in hindsight they traded at least some amount at a price that wasn’t the equilibrium price at the end of the block (the same instant as their trade happened). It’s like you are offering lemonade on the street for $1, I come to your booth buy all of it and then tell you everyone else on the street is offering it for $2. Are you happy you now know the right price or unhappy that I bought some off you at an “unfair” price?

Would there still be a well-defined bonding curve? Subject to the bonding curve, arbitrageurs will minimize the pool value which is then equal to the LVR. Different bonding curves will result in different amounts of LVR. Average clearing prices without amounts being cleared relative to pool value do not paint the whole picture. If there is no well-defined bonding curve LVR is technically not defined, also since we cannot determine how much volume at what price will be cleared.

The oracle needs to be high-frequency because there should not be a latency game where an arbitrageur still has newer price information than is used in the block.

If price discovery happens on-chain, yes all demand and supply forms an oracle for the price discovery but in most relevant literature, it is implicitly assumed that price discovery happens off-chain. Whether this is the case or not or how we can move more towards this is super interesting but a subject for a separate study.

Yes, the AMM in the pseudo-code for instance follows x*y=k. However the AMM can get executed to a point that is above the curve (just like in the OMM case where the curve gets replaced by a strictly superior after each trade).

If price discovery happens on-chain, yes all demand and supply forms an oracle for the price discovery but in most relevant literature, it is implicitly assumed that price discovery happens off-chain.

Even if price discovery happens off-chain in the presence of arbitrage competition and uniform clearing prices LVR should still be minimized.

Consider two arbitrageurs A1 and A2 with unlimited funds. The price of ETH goes from $1300 to $1310 in the matter of 12s. From the previous block, a CoW AMM is still trading at $1300.
What price to buy ETH would A1 and A2 bid in the batch, knowing that all participants gets cleared at a single clearing price? My assumption would be some price just below $1310.
In a traditional AMM, one arbitrageur would beat the second to the punch and get an effective price of $1305 (capture more LVR).

Hey everyone.
Thanks @fleupold and @Julian for resources.

In the pursuit of finding out whether the economics and the numbers of the proposal above would work in real life, I did a quick and dirty numbers crunching exercise today which I would like to share. The code used and results are available in this [repository]. Feedback, suggestions and mistakes spotting are very welcome. (GitHub - mohammed7s/Feedlot)

Model description:

  • Invariant: Constant product market maker (x*y=k)
  • Use the historic executed price as the solver-pricing-oracle
  • Input Variables: 1) Initial Reserves (USDC) 2) Fees level (%)
  • Tracked variables (output): 1) % of trades executed 2) Volume executed 3) LP fees collected

Method:

  • Set up pool for top volume tokens on cow swap: USDC and WETH.
  • Dataset: 3 month historic trades from Dune. Query = 37241
  • Use traded price as the oracle price input for AMM.
  • Initiate the pool with different USDC values and fees configuration.
  • Go over trade by trade and check if new k > old k. If yes, execute and add to the reserves.

Results summary:

Sample data summary
Data range 08.08.22 – 08.11.22
Total Volume 271,804,939 USDC
Total Trades 6295
Fees = 0
Initial reserves (USDC) Trades percentage Total Volume Volume % Total fees collected
1,000 17.06% 6,045 0.00% 0
10,000 34.73% 336,961 0.12% 0
100,000 65.97% 8,362,579 3.08% 0
1,000,000 90.10% 53,388,163 19.64% 0
10,000,000 92.59% 94,359,895 34.72% 0
100,000,000 95.96% 153,624,635 56.52% 0
1,000,000,000 96.99% 182,812,101 67.26% 0
10,000,000,000 97.43% 223,370,768 82.18% 0
Reserves = 1,000,000
Fees Trades percentage Total Volume Volume % Total fees collected
0.10% 89.65% 47138564 17.34% 47,139
0.20% 87.75% 38966374 14.34% 77,933
0.30% 74.93% 19089016 7.02% 57,267
0.40% 75.96% 12120700 4.46% 48,483
0.50% 66.69% 9048900 3.33% 45,245
0.60% 55.82% 7480118 2.75% 44,881
0.70% 53.06% 6437279 2.37% 45,061
0.80% 47.80% 4631886 1.70% 37,055
0.90% 47.31% 4076307 1.50% 36,687
1.00% 41.08% 3327112 1.22% 33,271

Results Discussion:

  • Capturing 90% of the trades does not mean capturing 90% of the volume (note: there are a lot of small orders in the data where the trade value is less than $1). The pool needs to have around $1bn to capture 67% of the traded volume!
  • For a pool size of 1,000,000 USDC, the LP annualized return is 31.1% which is quite reasonable for a Defi APY but also seems suspiciously high. However a pool of this size would only have captured 19.6% of the trade volume.
  • There seems to be a sweet spot for the fee configuration whereby much higher fees start to impede the percentage of trades the AMM would have captured. This result is similar to the Laffer curve in tax economics. (you can raise taxes up to a point before you start impeding growth in the economy).

Further Questions:

  • Are there better invariants that are more suitable for this application? Can we improve capital efficiency for the LPs? (capital efficiency defined as capturing more fees/trades for same amount staked). For example, a curve-like stableswap mechanism (curve V2) comes to mind where the repegging would happen on the solver-price-oracle. (will aim to model this next)

  • How do we conclusively demonstrate/prove that the use of the winning solver’s pricing as a price oracle solves the LVR problem for the LPs? How does it compare using a high frequency price oracle vs solver pricing oracle?

  • What is the best mechanism for using the winning solver’s price as an oracle input to the AMM? How do we maintain trustless guarantees? Do we need to create a commit-reveal game with positive expected value for the solver to engage in? Can solvers collude to deplete the pools?

  • Using the solver-price-oracle means the AMM pricing can only update when there is a batch. Hence it would be unsuitable as an LVR/Surplus capturing AMM for generic orders. It does not mean it cannot be used directly by calling the public swap function in the contract as long as it satisfies the preference curve as Felix suggested above that one can have a higher fee for those orders. However, you would be back with the LVR problem for the LPs. Do we introduce a new type of high frequency oracle that tracks volatility of the token from various CLOB exchanges and tie the fees to this oracle as suggested in the LVR research? Or… this AMM only serves CoW orders?

1 Like

@mohammed I would caution your LP annualized return figure because you are extrapolating an annualized figure (365 days) from only 3 days worth of data.

@Julian In fact, LVR is technically only defined for cases where there is ordering dependent asset pricing because it is currently only defined for CFMMs.
I offer some caution with the reasoning behind your assertion. The paper claims that CFMMs are path-independent and LVR is being applied in the context of CFMMs. However CFMMs are only path independent in the absence of fees, which is what the authors assume when they use a “black scholes setup” which is absent of any transaction costs. For more details about CFMM path dependency, please see section 2.3 “splitting trades is more expensive” section in this paper.

However again, when you say that LVR is only relevant in ordering dependent asset pricing, this is factually correct, but not in line with the LVR paper results.

@fleupold It’s an interesting idea - does Cowswap Solvers essentially do a hybrid approach with Balancer already?

Overall volume may be significantly lower than in traditional AMMs due to the fact that arbitrage is slower and limited. However, I still think it could overall be more profitable for LPs to engage in this mechanism.
I agree this might be a problem. There is certainly a lower bound of activity required to keep the LP spot price somewhat “fresh” enough. LP profitability is as a function of volume * fee so however much volume decrease you expect, you would have to offset with a higher fee, which might create bigger iliquidity (and conversely greater arbitrage opportunities).

One reason that such a pricing function isn’t working in traditional AMMs is that a trader could split their trade into many tiny transactions each increasing the new spot price only by a bit, therefore effectively sampling the behaviour of tradtional AMMs (buying a few wei at 1300, then 1301, etc).
Please see secion 2.3 “splitting trades is more expensive” section that I mentioned in my response to Julian. Splitting trades into many tiny transactions is not free to traders and is the result of CFMM’s being inherently path dependent when considering fees/transaction costs.

Hi @0xEvan thanks for comments. The data range used is actually 3 months not 3 days. (Maybe the date format mentioned was not clear. My bad) I still however would not take the annualized LP result too seriously yet as the model is slightly simplified. The key takeaway I believe is that there is clearly some surplus to be captured by a well funded AMM trading the most commonly traded assets on COW.

What we have done is simply filter two pairs commonly traded USDC & WETH and assumed there is a CPMM pool with these two assets and compared actual executed prices of the last 3 month trades in these assets with different reserve and fee values on this AMM as variables. With a BIG ASSUMPTION that we are able to capture the surplus between the actual traded price and the current AMM price. (so we are constantly shifting the k to k_new whenever its higher). You can think of the surplus as the difference between k_new and current k. Which traditional Uni V2 style AMM is unable to capture. So yes it is a big assumption that we are able to design some mechanism that is able to capture this surplus.

Sorry, it took me a while to take a look at this, but this is actually quite interesting data. How does this compare to Uni v2, Sushi, Balancer and even Uni v3’s fee/tvl ratio? I’d assume it least for the first three it’s substantially smaller than 30% annualized.

One thing you assume in your computation, which I’d caution (you also mention it in your latest comment) is that trades are still executed at exactly the same price as they would have been without the CoW AMM. I think some part of the fee (especially for small orders) may go towards the trader as solvers would find more surplus for the user by offering them a better price (using CoW AMM). Unless, we also add the surplus that CoW AMMs incur to the objective function.

We were planning to run a trial with Balancer where the LP fee would be lower for trades coming from the CoW settlement contract, however until now we haven’t gotten around doing this (it would also not allow surplus capture for Balancer LPs)

In our AMM profitability would be (volume * fee) + surplus (aka LVR) so as long as the ratio of LVR to volume is large enough, LPs should be making more money even with less volume and the same fee.

This is true. However bots could slice their trades into the smallest feasible chunk (not arbitrarily small) where the arbitrage gain is still larger than the transaction fee.

@fleupold to be honest I am still not sure how to interpret the results. It is saying that had there been a specific pool USDC-WETH out there with those reserves, the cow solvers would have chosen that as the best priced AMM. Which is surprising. Especially that the uniswap V3 pool alone has more than 76m USDC in tvl. So I am surprised it captures anything below 76mln in our study. Maybe we have mismodelled some fee? Also, the model is set up in a way that assumes that there is some sort of a two step game where solvers find the best price in first step then check with this AMM in the second step and any difference is kept by the AMM. Is this just another side of the coin of the same concept of surplus in the first post?? As shown in this graph:

image

I also have a concern. You simply assume that trading at the marginal price solves the LVR issue for the LP. That I accept. Also you assume that the price coming from solvers will be the marginal price at times thereby capturing the surplus. But wouldnt such an AMM that charges this difference (between marginal and average) be strictly more expensive than other external AMMs with same reserves? So solvers would never choose it. Even based on this example above you provided here:

Arbitrageurs would likely be happy to still sell FTX at some price slightly above $5 so the “uniform clearing price” that LPs would receive would be close to $5.
Traditional CFMMs would buy at an average price of $10 thus creating much more LVR.

This AMM will never be chosen by the solvers. Solvers will pick the external AMM that is buying at $10 so this surplus capturing AMM will not get the order flow. My concern is basically that the solver’s price is not a good oracle to capture the LVR/surplus because solvers work in the best interest of the user not the LP. So the price coming from the solver is a reflection of the worst priced pool (in the eyes of the COW AMM LP) that is out there in the market.

Unless I am missing something around block vs batch timing that would nullify this concern?

2 Likes

I think you are not accounting for searchers which will likely do everything they can to update the price of traditional AMMs before any retail user can trade it. Therefore, the CoW AMM wouldn’t really be more expensive (other AMMs will already be at $5 in the example from above) unless solvers themselves can capture that arbitrage, which may be hard to incentivise (they will only be rewarded a percentage of the value they achieve for the protocol where in out-of-cow arbitrage they can keep everything for themselves).

Right, I think the truth is that this value would be somewhat split between LPs and traders (and I also have a hard time coming up with a good way to model it).
One argument why it should be mostly captured by the LPs is that there should be “batch-arbitrageurs” who - in the example - “optimistically” place orders close to $5 (plus fees) on CoW Swap when they see the CEX price at $5.
That is, they are happy to sell FTX in case CoW Swap decided the clearing price was significantly above $5 (to immediately re-buy it for less on the CEX).

A competitive “arbitrage-sell/buy-wall” around the CEX price should ensure a clearing close to $5 (giving most of the LVR to the LPs) and thus capture most value for LPs.

This is an aside:
Honestly I am not a fan of LVR. I don’t believe the current research is strong enough to suggest it is as big of a problem as people are currently making it out to be. There are two assumptions that are made that makes LVR make sense:

  1. cex liquidity is deeper than dex liquidity
  2. low latency oracles have a speed advantage over higher latency oracles. Also needs to assume that 1) holds.
  3. Exclusion of fees or transaction costs in the analysis

Suppose that liquidity on-chain is deeper than off-chain liquidity. Then LVR would be going in the opposite direction from a CEX to a DEX (rather than a DEX to a CEX). Does that reasoning make sense? For 2) let’s consider univ3 on ethereum and univ3 on arbitrum where the arbitrum price oracle is much much faster than the ethereum
price oracle. Does this setup leak information such that the arbitrum price oracle is more informed even if it has less liquidity depth?

Again I’m not saying that LVR is or isn’t a problem. My opinion is that I think there isn’t enough information/research done to make the leap that LVR is as big of a problem as people make it out to be.

If we look at the solver data more carefully, can we verify these assumptions quantitatively? Also if you need more data than you can get from the dune query, I can possibly help with extending the dataset to include more historical data from the subgraph.

@mohammed I read through your overview.md file in the github and have some further feedback that might strengthen the research direction you are trying to go in.

  • What is the marginal price differential between using a uniform clearing price from a batch auction design vs other pricing mechanisms? (posing a more general question that encompasses more than LVR) The idea is to understand the tradeoffs better between a batch auction UCP and other oracles (such as high frequency oracles, TWAP oracles, etc). This could be done by comparing trade details (swap size, volume, execution price, etc) between batch auction trades and DEX trades. Just need to group the data into 1-15 second time intervals to create a uniform index to do time series analysis. No idea where you can get the equivalent data to compare for CEXs.

  • If there is a consistently positive (could be for either LP, swapper, or both) marginal price differential, then what is a price range in which one could auction the rights to trade in a non batch auction design?

  • I personally would like to see more data on the solver decision making process and data flow that solvers consider up to the batch auction process. My knowledge is kind of murky on this compared to @fleupold and others. I think understanding this process in more detail (through charts and numbers) is a crucial part to further analyze batch auctions + uniform clearing price mechanisms in general.

Hi @0xEvan first of all yes I would love to look at more data. There are a bunch of things worth looking at. Feel free to message me on discord: mohammed38mah#9804

I do not think the LVR issue is about liquidity at all. It is about:

  1. An AMM that is not able to adjust pricing on its own because it is a smart contract.
  2. By simple design of the CPMM invariant: It always takes the other side of the trade.

You can have the best reserves (liquidity) in an AMM, if there is a new info in the market and prices of that asset need to adjust, that AMM will lose on LVR. Because the searchers will probably do the adjustment on its behalf (and earning the the arb which is the LVR). In CEX’s the market makers can react to volatility and adjust their spreads accordingly (check section 2.5 here), a CPMM cannot do that.

The proposal above in the first post I feel is strongly based on two fundamental assumptions:

  1. Searchers will do what they do best: always arb away the differences.
  2. The COW solvers will always see this new adjusted price.

The only difference between a traditional AMM and the proposed “surplus capturing AMM” is that the latter does not lose to searchers adjusting the price. It simply jumps there using the COW solvers price. No searcher would be able to arb it. They both would have the same ending marginal price resulting from the trade. One bled liquidity getting there, other one didnt. But note how important assumptions 2 is for this result to hold. The “surplus” really comes from this difference which you might call LVR. Regardless of how one feels about the maturity of LVR research, one cannot argue with math. If the two assumptions are actually true, then such a “surplus” does exist mathematically. How accurate are the two assumptions in real life?

Which brings us back to data crunching. I am now almost convinced the experiment in the repo reflects this exact phenomena of the surplus. It might need further verification around fees and further data (more pairs and longer horizon) as you suggested which I would love to explore with you if you are up for it.

The term “marginal price differential” What do you mean exactly with it?

On the high frequency price oracle: if it were to truly exist then it would solve the issue of the LVR for any AMM. I feel this “high frequency oracle” is the most ideal in theory. But since we work in blocks in Ethereum its not so easy in practise. So how good is the COW solver price in relation to this ideal? That definitely should be explored quantitatively. I am still digesting the rest of your feedback on the overview.md thank you for the thoughts.

There seems to be a little paradox. If we do manage to define an invariant for the proposed AMM, or at the very least its possible to determine what k_new the AMM willing to accept, wouldnt the COW solvers (due to competition) always quote the k that is just equal to k_new? thereby passing on all the surplus to the users?

I do not agree that assumption 1 holds all the time in practice. LVR research is very nascent in the sense that practical scenarios that have transaction costs (fees, gas costs, compute costs etc) are given no consideration. In real world situations, transaction costs are very real and exist.

That is where we fundamentally disagree, but I am happy to chase the data, let the data speak for itself, and be proven wrong :slight_smile:

I am defining the marginal price differential as the delta between the uniform clearing price and other pricing mechanisms (e.g. CPMM spot price mechanism). I would say I am asking the same question as you are stating here:

Ok lets look at a more straightforward example where we isolate the potential price impact of a single trade. Lets assume we only have two AMMs in the world. One external CPMM on uniswap call it AMM1 and a surplus-capturing AMM called AMM2. We are looking at ETH-USDC pool with initial reserves in both of 100 USDC - 10 ETH. The starting marginal price currently is 10 USDC in both AMMs.

Single Order

A user wishes to buy 1 ETH and submits the trade to COW swap. Solvers will price this trade at AMM1 at the mean execution price of 11.11. The marginal ending price of this trade on AMM1 would be 12.34. Assuming no searchers, and no MEV, the solvers will choose to execute this trade at AMM1 because AMM2 will want higher than 11.11 (if k_new >k condition) and maybe if you design it such that it charges the marginal ending price it would want 12.34. In both cases AMM1 will get the trade. Even if you assume that AMM2 will accept k_new = k, and solvers do decide to give the order to AMM2 then AMM2 would have not captured any surplus and would be 100% identical to AMM1. Both executed at the mean price of 11.11. AMM1 traded all the way up to 12.34 along the curve marginally, AMM2 just “concentrated” its liquidity at 11.11 but both have the same mean execution price.

Macro event price change

Now lets assume that ETH got very bullish news (US president signed a bill whereby all FX and Stock and bond trading shifted to batch auctions on an Ethereum application) and ETH price needs to go from 10 to 20. AMM1 will be selling ETH all the way up to the P2 marginal price of 20. Its mean execution price is 14.14. Arbitrageurs have milked the LPs all the way up to 20. Now AMM2 is sitting there doing nothing. A trade comes on COW to buy 1 ETH, the price it will reflect will probably be closer to 20 as solvers will bake in the price movement to 20 on AMM1 and AMM2 would have retained some “surplus” that it otherwise would have lost if it was a traditional AMM1 style. Surplus being (20-14.44 = 5.66). AMM2 will get the trade because its easy to satisfy the threshold of k_new > k (where simply the price has to be above 14.14 to satisfy this condition since the other AMM1 trading at 20) . So AMM2 can charge 19 for example and both the LP and the user are happy.

How do we split this surplus exactly? What sort of fees structure would split the surplus? I don’t have an answer yet. Also, there are a ton of assumptions that need digging into as @0xEvan has pointed out. Would searchers actually shift the AMM1 price to 20? (probably holds) and do solvers really bake in the searcher’s work of shifting AMM1 to 20? Needs some number crunching.

I also still do not have clear formulas of all the above but I am qualitatively making a distinction between the effect of a single impactful order whereby a surplus-capturing AMM has no advantage vs a global shift in the price of the asset whereby the advantage of a surplus-capturing AMM potentially becomes evident because it doesnt trade continuously and is almost behaving like a CEX market maker that adjusts its selling price according to new information.

MEV Protection?

Moreover, if the surplus-capturing AMM is only permissioned for the COW settlement contract does that mean we will never have any front running and no MEV since no one can actually trade on this AMM except for COW orders? If so, what are the MEV savings that the solvers have had to calculate for traditional AMM orders?

1 Like

I don’t think we disagree then.

In the single order example there is no LVR, because the price didn’t move on some external exchange, it’s retail ETH demand driving the price up (in a perfect world assuming there is a liquid external market a market maker should be willing to sell ETH at 10.05 and avoid moving the AMM up). Thus the surplus capturing AMM performs as well as the standard one (the optimal path will actually split the volume 50/50 across AMM1 and AMM2 and find the average price of AMM1 to be the uniform clearing price).

In the second example there is LVR (external price moving between blocks) and thus AMM2 performs better. Regarding the surplus split, we could envision a design in which any surplus captured by the CoW native AMM also contributes to the objective value (therefore giving the AMM a better price will make your solution better). Then the problem of surplus distribution reduces to the one we already currently have in case there are overlapping buy and sell order (I’m willing to buy 1ETH at $1200, you are willing to sell 1ETH for $1100, where do we meet?). As long as CoW Swap is not yet the primary price finding layer we use the external price (based on other AMMs) as the reference in that case, but we are researching rules that also work without any reference price.