RFG: Development of Manipulation-Resilient Price Oracle for CoW AMM LP Tokens

CoW Grants Program
1

One of the core characteristics of AMM deposit receipts (commonly referred to as LP tokens) is that their value is inherently less volatile than the combined volatility of the underlying tokens, thanks to automated rebalancing. This phenomenon, as discussed in @AndreaC 's research piece, positions LP tokens as safer collateral options for lending markets compared to holding the underlying tokens individually.

For LP tokens to be adopted in lending protocols, a price oracle resilient to manipulation is critical. Specifically, the oracle must guard against two key types of attacks:

  1. Short-term over-reporting of value: This could enable attackers to borrow excessive amounts of debt against artificially inflated collateral, resulting in unrecoverable losses during liquidation.

  2. Short-term under-reporting of value: This could allow attackers to trigger liquidations of valid collateral to exploit liquidation penalties, often up to 20% of the collateral’s value.

Historically, a significant challenge in using AMM LP tokens as collateral lies in their susceptibility to manipulation within price oracles. Even when robust oracles exist for the underlying tokens, permissionless rebalancing allows attackers to trade against the AMM pool, skewing the marginal price to create “out-of-market” valuations.

Example of a Manipulation Attack

Consider an AMM pool with 1 ETH and 3000 USDC, supported by resilient price oracles reporting ETH at $3000 and USDC at $1. The total market capitalization of the LP token should be $6000 (the product of balances and oracle prices). However, an attacker could, within a single block, manipulate the pool by trading 0.9 ETH for 27,000 USDC, causing the oracle to report a market capitalization of $30,300.

While some AMMs, such as Uniswap, mitigate such manipulation through time-weighted average price (TWAP) oracles, CoW AMMs are by design less vulnerable. This is due to their rebalancing mechanism, which requires bonded solvers to execute trades. However, given the potential very high damage inflicted by borrowing against overvalued collateral, relying solely on solver bonds may not be sufficient.

Proposed Solution

Building on insights from the development of CoW AMMs (in particular their “helper” contracts for widespread solver adoption), we propose a novel manipulation-resilient oracle design. > Specifically, we can compute the “rebalancing trade” that a zero-fee constant function AMM would accept based on its current balances and external price feeds for the underlying tokens. This allows us to counteract manipulation by simulating the pool’s state post-rebalancing.

For instance, even if the manipulated pool balances are 0.1 ETH and 30,000 USDC, we can calculate the hypothetical trade required to restore balance based on the invariant and underlying oracle prices ($3000 for ETH and $1 for USDC). By performing this “counterfactual” trade, we determine the adjusted balances (1 ETH and 3000 USDC) and accurately compute the LP token’s true market capitalization of $6000.

This is achieved through the following equations:

  1. Ensure the ratio of post-trade balances matches the exchange rate from the underlying oracles:


2. Preserve the constant product invariant:

By solving for R_x and R_y we calculate the rebalancing trade amounts and adjust the LP token valuation accordingly. This method ensures that the LP token’s oracle is as robust as the underlying price feeds.

Scope of Work

The grant seeks to implement a manipulation-resilient oracle specifically for CoW AMM pools. The oracle will:

  • Adhere to the Chainlink oracle interface.
  • Leverage existing Chainlink-compatible oracles for the underlying tokens.
  • Support weighted token pools of all configurations.

Deliverables include:

  1. A fully functional smart contract implementing the oracle.
  2. Comprehensive test coverage demonstrating its resilience to manipulation.
  3. Documentation detailing the oracle’s functionality and integration, with examples of practical use cases.

This proposal aims to strengthen the security and usability of CoW AMM LP tokens as collateral, enabling broader adoption in lending markets and other DeFi applications.

2 Likes
2

Interesting request. Notably what is meant concretely by “Support weighted token pools of all configurations”? Does this include >2 token pools?

3

Two token pools with arbitrary weights are sufficient.

4

This is a v interesting idea!

I’m still pretty new to CoW Protocol’s design, so let me know if I’m wrong about anything!

I’m not sure if the current CoW AMM contract design works well with this oracle. Since CoW AMM allows random token transfers, attackers could manipulate the token balances by transferring tokens to the pool. This could mess up the k value in the formula and make it less effective.

Whether someone would actually pay an upfront cost to manipulate it is dependent on how valuable the oracle becomes, and how much the total transfer cost is.

And since surplus is designed to be transferred to CoW AMM directly, the usual fix of tracking token reserves to avoid reserves manipulation doesn’t seem to work either.

Would love to hear your thoughts!

5

Cool, this should make it much easier for the grantee :smiley:

6

Correct me if I’m wrong, but as long as the change in k is permanent (which it is if you send the AMM funds), then this is fine (the LP tokens are actually worth more now).

Given that we always compute the rebalancing trade before assessing the pool’s actual balance, even a one sided transfer should make it so that we “predict” the arbitrage trade that will happen in the next auction and thus use a correct price.

7

It is true that LP tokens are worth more when more tokens are transferred in. However, a potential pitfall is when most liquidity in a pool belongs to a few, or even a single, liquidity provider.

If a few whale providers are malicious, they can transfer tokens into the pool to pump up the LP token value and then withdraw all their liquidity—including the donated tokens—once the manipulation is complete.

An example is lending protocols that use this oracle for borrowing assets. An attacker could hold some LP tokens, split them into two parts, use one part to borrow assets from the protocol, and hold the other part for manipulation. They can then withdraw liquidity after successfully borrowing more assets using the inflated borrowing power.

Detailed calculations would be needed for specific cases, but the above shows the potential risk!

I randomly came across this talk on LP oracle design (at around 4m17s):https://www.youtube.com/watch?v=zsohxOn91vc
tl;dr: pools that allow direct transfers shouldn’t be used for borrowing purposes.

We might also mitigate this with certain usage restrictions, such as requiring pools to be deployed for a certain amount of time or ensuring liquidity is distributed across enough addresses.

I haven’t had time to look into whether there are real hacking cases on this matter, so I can’t say for sure if this is a serious risk!

8

I don’t understand your proposed attack and would appreciate a more concrete step-by-step example.

If I own 800/1000 LP tokens of a pool that has a total market cap of $1M, then a lending protocol might rightfully assume each LP token is worth $1000 and accept it as collateral (ie let me borrow something like $750 against it). Now let’s say I “donate” $1M into the pool, increasing the market cap to $2M and thus making each LP token worth $2000 (and allowing me to draw $1500 in debt).
Assuming the collateral was provided from the remaining 20% supply, I can withdraw my 80% stake leaving the pool with 200 tokens and $400k TVL, thus the price per LP token didn’t change.

How do you attack this?

10

I couldn’t come up with a scenario with working numbers, and I think you’re right!

I was initially thinking about transferring single-side tokens, but since this oracle checks that the price aligns with another oracle, such transfers wouldn’t affect the oracle output price.

It sounds like this design does solves the concern about not implementing LP token oracles on AMMs that allow direct transfers! Sorry for the confusion, and thanks for helping clarify this!

11

Very interesting project @fleupold . Just to confirm, the idea is to use the TWAP strategy to consume the underlying token oracles, right?

12

I don’t think so (could you clarify what you mean by that). The goal is to use the CoW AMM helper contract to compute the amounts the AMM wants to trade given the current prices of the underlying token oracles, then apply this trade to the current balances (assuming an arbitrageur will make a 0 surplus trade in the next block) and then multiply the counter-factual balances with the underlying price oracle’s price.

13

It makes sense, I thought you were proposing to use TWAP on top of the underlying token prices, but I think that is unnecessary.

14

Just posted our proposal here. Also, we developed a PoC using 50/50 pools here. Looking forward to your guys feedbacks.

15

I have just posted our proposal here. Thank you for your consideration and happy to receive any feedback.