Investigate Market Manipulation Risk in ZRX and Other Tokens

Ideas
1

In our recent security review of Compound v2, the Volt Protocol team identified a class of market manipulation risks. The full report is available here, but I have quoted the most relevant section below.

In reviewing the security of Compound in preparation for PCV deposit, the Volt Protocol team explored the risk of market manipulation attacks. The attack is possible when the amount of a token borrowable on markets like Aave and Compound is large compared to the liquid market. The most notable example is ZRX, which has borrowable liquidity on each of these markets comparable to or greater than the usual daily volume across all centralized and decentralized exchanges.

Collateral Withdraw Attack

In the most basic form of the attack, a user borrows a large amount of the available supply of a token, such as ZRX, and sells it across multiple centralized and decentralized exchanges, depressing the open market price. The combined borrowable liquidity for ZRX on Aave and Compound v2s is more than twice the average daily volume currently. Once the oracles which inform Aave and Compound update, the user withdraws most of their original collateral. With numbers: supply $30 million collateral in stablecoins. Borrow “$20 million” of illiquid token and sell it, depressing the token’s market price by 95% and realizing $7.5m. New market value of the user’s debt is $1 million, allowing withdrawal of $28m collateral. Attacker profits $5.5m, leaving underlying market(s) with bad debt.

For this to work, it is necessary that the amount of the token borrowable be sufficiently large to depress the open market price. When the same token is borrowable on both Aave and Compound, as is the case with ZRX, this appears more likely. It is uncertain whether the current amount of borrowable liquidity would be sufficient to carry out the attack, though we believe that it is possible based on our analysis. If carried out in the form described above, bad debt would be confined to the ZRX market and not concern Volt Protocol PCV.

Two-Oracles Attack

There is a more sophisticated form of the attack that relies on differential oracle updates between Aave and Compound, and is in theory possible whenever two markets use different oracle systems. Whenever a Chainlink update gets sent into Compound, its price is compared against the cached 30 minute TWAP of that asset on Uniswap, which can be re-updated every 30 minutes. If the price on Uniswap and the price from chainlink are more than 15% apart, the Compound Oracle system does not accept that update as a valid price input, and will refuse to accept this new market price into the system.

An attacker can take advantage of this difference by, as in the Collateral Withdraw Attack, borrowing a large amount of ZRX from Aave and selling it rapidly across all exchanges to depress the price. Chainlink will “correctly” update the Aave price down, allowing the user to borrow even more against the same collateral, with the end result that all of the ZRX on Aave is borrowed. Once there is little to be gained from selling into the market, the attacker can instead deposit ZRX on Compound as collateral and use it to borrow. Since Compound rejected the price update from Chainlink and is still using a higher old TWAP price, the attacker can cash out by borrowing stablecoins or ETH on Compound. This would result in bad debt in the ZRX market on Aave, and bad debt in a stablecoin or ETH market on Compound.

Given the low returns of borrows against the least liquid tokens, and the large total value locked in Aave and Compound, we feel taking active precautionary action is warranted even if the possibility of the attack is theoretical rather than certain, so long as it cannot be proved infeasible.

More extensive simulation might shed light on the precise amount of borrowed ZRX or other tokens needed to manipulate the open market price, and as such what total borrowable supply across DeFi is safe. We believe this risk vector is worthy of ongoing monitoring and concern, even if short term precautionary action is not taken.

Volt Protocol will soon integrate into Compound v2 as a lender, and will conduct a similar review of all future governance proposals, including direct testing, so long as the integration remains.

2 Likes
2

Given the recent GMX oracle attack which involved manipulation of exchange prices, perhaps there is interest in revisiting this topic.

2 Likes
3

The Mango Markets manipulation from yesterday also seems to indicate that liquidity attacks represent a real risk to the protocol.

In this case the attack worked somewhat differently from attack described above in OP. General process (slightly different due to use of perps, but this would be the equivalent for spot liquidity market like Compound):

  1. Deposit stablecoins or other hard collateral with high collateral factor in account A
  2. Borrow/short low liquidity asset XYZ from account A
  3. Transfer XYZ from account A to account B and deposit as collateral
  4. Purchase a lot of XYZ across DEX/CEX to push price up significantly
  5. (optional) Deposit additional purchased XYZ to account B
  6. Account A may be pushed into liquidation, causing further upwards price pressure on XYZ
  7. Borrow hard assets (stablecoins, ETH, etc) at max LTV from account B using inflated value of XYZ collateral

If amount borrowed in step 7 (XYZ collateral * price * collateral factor) is greater than sum of collateral provided in account A (step 1) and cost of purchased XYZ (step 4), then the attack will generate a profit. The largest risk factor for an attack like this being profitable is illiquidity of a prospective target XYZ asset - this would allow the an attacker to move the price up significantly with relatively smaller amount of capital. Secondary risk factors include collateral factors for XYZ asset and of other hard collateral assets that could be used to borrow XYZ.

I’m working on a proposal that I think could reduce risk of these sort of liquidity attacks, while having minimal impact on capital efficiency and UX of regular / non malicious users. Hope to share more soon!

2 Likes
4

I will be excited to hear the details of this proposal. You beat me to the punch coming in here to bring up the Mango incident.

We’ve brainstormed a few possible solutions to this category of risk:

  • global rate limits on borrowing. Market manipulation is much more difficult as duration increases, something like an hourly rate limit equal to the max organic borrow in the last month.
  • per-collateral borrow limits such that no matter how high the price is, risk per collateral type is capped
  • maximum and minimum oracle prices. Compound has already used the idea of a circuit breaker or fallback oracle. The system rejects a Chainlink update that deviates too far from the Uniswap TWAP. Instead of simply rejecting the update, it could also pause all new borrows until a valid update comes in or a governance action unpauses the market.

SBF says it well below.

1 Like
5

I think this can be achieved immediately with borrow limits feature.

This could be achieved using borrow limit automation features, probably would look similar to Maker’s debt ceiling instant access modules (target available borrowable amount that can update every 6-12 hours). Would require some new engineering work I think, and replacing the borrow cap guardian from multisig to a contract.

Other possibility (although maybe more complicated) is to limit the rate of change of oracle updates. Eg for any prices that have changed more than 30% over the past hour, limit the change to 30% instead. Would need to be careful of possible edge cases for doing this.

1 Like
6

Thanks, @monet-supply @OneTrueKirk. Gauntlet is running analyses to estimate the cost of these attacks and will return to the forums ASAP to provide recommendations. It would be great to collaborate together on actions the protocol can take to mitigate these risks.

3 Likes
7

For those who might not be aware, OpenZeppelin has built monitoring to watch for low liquidity attack vectors in V2 markets. I don’t think this bot covers exactly the same attack vectors as a Mango-style incident but further bots could also be developed to tackle this once a methodology is figured out.

Bot Description: This bot monitors Compound Finance cToken contracts that have low liquidity for potential market attacks where a malicious actor mints cTokens and then transfers additional tokens in
order to unbalance the contract such that subsequent mints will not yield cTokens.
Bot Link: https://explorer.forta.network/bot/0xe49ab07879658c258d5007ac6b88428a2b88cc5cfef206222ad94690840be87a

2 Likes
8

Moving forward, it’s clear that these attack vectors do exist on the current implementations of Compound V2.

Instead of band aid solutions that don’t fully fix the problem, I would propose that the oracle implementation be fixed with the same solution that SBF uses on FTX. Collateral factors on long tail assets get adjusted very far down to account for lack of liquidity on both centralized and decentralized exchanges, and instead of ignoring price updates if they deviate more than 15% from the TWAP value, always update the price in the oracle, just allow up to a maximum of 15% price deviation on any update. This means if an update comes in that says the price changed 30%, the protocol instead calculates the price of the asset at a 15% higher rate and stores that. Additionally, there should be a minimum period of time enforced between oracle updates so these 15% changes cannot be applied in too short a period of time that would nullify the effect of capping percentage changes.

Removing the concept of the uniswap anchor would be helpful as well because it would simplify the oracle codebase and remove the dependency on a TWAP value that in some cases has less than $200k in liquidity on the uniswap V2 pairs.

The clock is ticking, and the longer the protocol takes to implement a solution, the more likely someone exploiting this economic threat vector becomes.

9

We have published recommendations here.

An oracle manipulation-based attack analogous to the one that cost Mango Markets $117m is much less likely to occur on Compound due to collateral assets having much deeper liquidity than MNGO and Compound requiring loans to be over-collateralized. However, out of an abundance of caution, we propose pausing supply for the above assets, given their relative liquidity profiles.

Importantly, this will be a step towards incentivizing migration from Compound V2 to Compound V3, which the community has voiced support for. Compound V3 has meaningfully more risk controls, including supply caps.

6 Likes
10

I’m happy to see this risk mitigation step being taken (and also looking forward to when we can integrate Compound v3 in the future). New borrows against these assets are not likely to be large in size in the near term compared to the tail risk they bring to the market. Will be looking forward to hearing about the results of modeling attack cost.

3 Likes
11

I will support this proposal.

and this is the proposal summary written by korean.

2 Likes