eIP 18: Move all asset price oracles to Chainlink where available ahead of the Merge

  • Title: Move all asset price oracles to Chainlink where available ahead of the Merge
  • Author(s): Michael Bentley & Seraphim Czecker
  • Submission Date: 5.09.2022

Simple Summary

All markets on Euler currently use Uniswap v3 for their price oracles. This proposal suggests moving all assets on Euler over to Chainlink where available, following its integration as part of eIP 14. This should help to allay some concerns about a reduction in the manipulation cost of Uniswap oracles after the Merge.

This doesn’t mean, however, that Uniswap TWAPs won’t be used on Euler at all. What this means is that wherever available, Chainlink oracles will be used. For everything else, Uniswap TWAPs will be the default oracle solution.

Motivation

The Merge from PoW to PoS is a consensus layer change on Ethereum that is due to take place sometime around mid September of this year. After the Merge, block proposers will be chosen deterministically before they validate blocks. This feature creates new challenges for decentralised price oracles, like those provided by Uniswap v3, because it opens up greater potential for inter-block price manipulation.

At present, a Uniswap v3 price oracle is often extremely expensive to manipulate (see an article I wrote about this here). An attacker must move the spot price of an asset by a very large % for at least one block in order to impact the time-weighted average price (TWAP) oracle. This exposes them to the risk of arbitrage. Any price manipulation will usually be countered by MEV bots, rendering attacks more costly than any benefit a price manipulator could usually hope to achieve.

However, after the Merge, block proposers will be alerted ahead of time when they are selected to propose a block. This gives them a unique opportunity to carry out oracle manipulation attacks. If they are chosen to propose block n, then they can attempt to manipulate the spot price on block n-1, knowing that they will be free to arbitrage their own price manipulation on the next block (and censor any other attempts at arbitrage).

It is hard to estimate how many block proposers will view oracle manipulation attacks as a legitimate way to increase their income. It seems likely many will not take the risk of carrying out these kinds of attacks. However, so long as the number is non-zero, it is clear there is some degree of reduced cost for carrying out oracle manipulation attacks after the Merge.

Hypothetical Attack on TWAPs Post-Merge

The first option is for the validator of block n (i.e. the attacker) to bribe a darkpool service like flashbots to include their manipulation transaction in block n-1. This is feasible, but involves some risk. As far as I’m aware, there’s no guarantee that the validator won’t still take advantage of the arbitrage opportunity for themselves. Note also that if the transaction isn’t LAST in the block, then any ordinary trades that happen after the manipulation transaction will probably be costly to the attacker. Imagine finding out you swapped 1 ETH for 1,000,000,000 because you happened to nip in after the attacker’s manipulation, but before they were able to arbitrage themselves back.

The second option is that the attacker has sufficient stake controlled to be able to wait until they can propose two blocks in a row. In this scenario, they can safely manipulate the spot price on block n-1 AND arbitrage it back themselves on block n. You might think it quite unlikely that a validator would get to propose two blocks in a row, but actually it might be relatively common (see Table below from this article ).

Column shows number of blocks validated consecutively. Rows shows percentage of stake controlled. So, for example, if you have 5% of the stake, then there is a 7.14% probability that you will get two blocks in a row in a given epoch. Which is pretty high, in my opinion. I expect most staking pools won’t be viewing oracle manipulation attacks as legitimate sources of MEV, but even small staking pools will hit upon this opportunity once in a while.

In the medium-term, the Euler Labs team have continued their research on oracle manipulation attacks and will propose new solutions for this kind of attack in the future. You can read more about some of their early research on this here. However, in the short-term, a clear solution to reduce concerns about oracle security ahead of the Merge is to switch at least some markets over to Chainlink (a new integration introduced as part of eIP 14).

Chainlink oracles have secured billions of dollars worth of assets across DeFi for many years at this point, and are the market leader in their sector. Whilst not free from their own criticism (see here, and response here), Chainlink oracles have not yet failed other major DeFi lending protocols, like Compound and Aave. The proposal would therefore be to move WETH, USDC, DAI, WBTC, UNI, and LINK over to the new Chainlink system. One might include a wstETH oracle too.

Implementation

The following assets will switch to Chainlink should eIP 18 pass:

Collateral Assets

  1. WSTETH
  2. USDC
  3. DAI
  4. WBTC
  5. UNI
  6. LINK

Cross Assets

  1. USDT
  2. ENS
  3. SHIB
  4. MATIC
  5. CVX
  6. MKR
  7. PERP
  8. AXS

Isolated Assets

  1. FTT
  2. LDO
  3. AAVE
  4. SNX
  5. OGN
  6. GRT
  7. 1INCH
  8. DPI
  9. RAI
  10. WNXM
  11. ANT
  12. BADGER
  13. GTC
  14. APE
  15. YFI
  16. ILV
  17. NMR
  18. MIM
  19. IMX
  20. LUSD
  21. LRC
  22. REQ

Risk Assessment

The Chainlink oracle change has undergone auditing by Omniscia:

https://omniscia.io/reports/euler-finance-chainlink-support/

It has also been reviewed by Sherlock:

https://www.hacknote.co/17c261f7d8fWbdml/1821f966f40pJG_t

Vote

Snapshote vote link: https://snapshot.org/#/eulerdao.eth/proposal/0xed0cfd4efb6ac3452cbaf626e7ef806a0de5c83a70eaa6d4547d362c01d15fd5

Yes means you support shifting the price feed of the above mentioned assets to Chainlink.
No means you do not support shifting the price feed of the above mentioned assets to Chainlink.

Conclusion

These changes will switch the price oracle for all assets over to the new Chainlink integration where availlable. This is intended to increase security of these markets and lower overall systemic risk on the protocol ahead of the Merge in mid-September.

Relevant Links

Uni v3 TWAP oracle attack cost research:

Median oracle research:

Chainlink criticism:

Chainlink response:

eIP 14 (Chainlink):

3 Likes

Bear with me, because I’m still trying to wrap my head around TWAP Oracle attacks (though your paper definitely helps). Let me give an example of how I understand this attack would need to be structured. Please correct me if I’m mistaken:


TAP Oracle Manipulation Attack Example

  1. Token XYZ is currently trading at $1 on Uniswap v3’s XYZ-WETH pool.
  2. Bad-actor knows that their validator is proposing block n
  3. In the last transaction of block n-1, bad-actor buys up enormous amounts of the token XYZ from the Univ3 liquidity pool → enough to move the TWAP high enough that they can profit despite collateral factor.
    • Since TWAP uses the last transaction in block n-1, wouldn’t the attacker have to be guaranteed that spot? Guaranteeing that spot would be hard to do unless the proposer of block n-1 is also in collusion/controlled by the attacker – there is too much money on the table for arbitrators to just watch that transaction go through (I think this holds true with the future proposer-builder separation but I’m not sure).
  4. At block n, the one the the bad-actor is proposing, he collateralizes a bunch of the inflated token XYZ and withdraws as much liquidity from Euler as he can get away with. He then arbitrages his own Uni v3 transaction with the profits he made from draining other assets from the protocol. He sensors all other transactions to ensure that his scheme succeeds.

Is that an accurate representation of an attack? If so, I’m still having trouble wrapping my head around the logistics of Step 3 – how does an attacker actually pull this off without controlling the validators of two consecutive blocks?

2 Likes

Great summary! In step 3, you need a few extra things to happen to enable the attack.

The first option is for the validator of block n (i.e. the attacker) to bribe a darkpool service like flashbots to include their manipulation transaction in block n-1. This is feasible, but involves some risk. As far as I’m aware, there’s no guarantee that the validator won’t still take advantage of the arbitrage opportunity for themselves. Note also that if the transaction isn’t LAST in the block, then any ordinary trades that happen after the manipulation transaction will probably be costly to the attacker. Imagine finding out you swapped 1 ETH for 1,000,000,000 because you happened to nip in after the attacker’s manipulation, but before they were able to arbitrage themselves back.

The second option is that the attacker has sufficient stake controlled to be able to wait until they can propose two blocks in a row. In this scenario, they can safely manipulate the spot price on block n-1 AND arbitrage it back themselves on block n. You might think it quite unlikely that a validator would get to propose two blocks in a row, but actually it might be relatively common (see Table below from this article).

Column shows number of blocks validated consecutively. Rows shows percentage of stake controlled. So, for example, if you have 5% of the stake, then there is a 7.14% probability that you will get two blocks in a row in a given epoch. Which is pretty high, in my opinion. I expect most staking pools won’t be viewing oracle manipulation attacks as legitimate sources of MEV, but even small staking pools will hit upon this opportunity once in a while.

1 Like

Option 1

I’ve been doing a lot of MEV and TWAP reading because of your post. Found some very good discussions about TWAP manipulations on the Flashbots discord server (look at April and May 2022 in the general channel).

Apparently, it is not currently possible to pay for the last tx position of a block. Block builders are committed to following the FFMP, but that seems to allow them to immediately arb back the price in the same block (as long as no one else is trying to do it).

Still a very real attack vector seeing as it has happened in the recent past to Inverse Finance. Though this was a small oracle pool and a lot of the work done by this hacker was aimed towards stopping arbitrators from correcting his attack in the same block (and he succeeded).

Option 2

Those odds of consecutive proposals within a single epoch are a lot higher than I had assumed (will be interesting to see the followup article that shows how much the odds increase as the timeframe is expanded).


So, I am in favor of this proposal as it would protect the protocol from systemic risk.

But why stop with just Collateral Assets? In the interest of protecting lenders of lower tiered assets, why not switch over to using Chainlink for all assets that have a significant Total Supply and have a reliable Chainlink oracle?

The drawbacks I can think of are related to Uniswap TWAP oracles being more decentralized and permissionless than Chainlink oracles – but it seems like a fair tradeoff as it makes theft less likely. What are your thoughts on this?

1 Like

Although this solution increases security of the collateral-tier markets, it also reduces the level of the permissionless of the platform, which was originally one of Euler’s main ideas, and adds a new point of failure (Chainlink) if something goes wrong.

At the moment I don’t see any good solution to this problem, so I think that we must continue to look for less radical ways to solve this problem.

2 Likes

It does not necessarily reduce the permissionless nature of Euler, since, by default, all markets will still be supported by Uniswap oracles. So permissionless activation of new lending markets remains in tact. However, I agree that it adds a governance overhead to the system, which is far from ideal. Euler Labs are working on new solutions that will aim to restore the power of decentralised price oracles and will present these to EulerDAO in due course. Thanks for your input!

2 Likes

Longterm, what if Euler employed a hybrid solution like Compound does – UniswapAnchorView (UAV) V3 is the newest iteration of this that they just voted to implement.

Since we’re concerned with both permissionless and manipulation resistance, we could use the Uni v3 TWAP as the assumed price while also comparing that price to Chainlink. More than a x% deviation and Euler uses the Chainlink oracle instead – this way an attacker would have to both manipulate the Uniswap TWAP Oracles and do some sort of simultaneous attack on the Chainlink oracles.

Or, it could even do something even more radical like freeze all borrowing/lending of that asset until the two Oracle prices fall within the bounded range – I don’t like this last idea much since liquidations are critical in keeping a healthy lending market.

2 Likes

The problem with your idea is that you have to measure both Uniswap and Chainlink oracles on each operation to know if there is a difference. That is kind of wasteful and adds a lot of gas cost. In the event they disagree, it’s also hard to pinpoint what should be done. Is Uniswap right or Chainlink? Should liquidations be allowed or not?

For the long-term, Euler Labs has a proposal we would like to put to the DAO, which involves deployment of a new oracle solution as part of a custom-built DEX called EulerSwap.

3 Likes

Good points! You’re totally right, after thinking through my first idea I realize it would be functionally identical to setting the oracle to Chainlink – the deviation could be due to Chainlink being attacked, and the protocol would switch over to the attacked pricefeed and use it instead.

You guys obviously have put a lot of thought into this so I’m looking forward to seeing your team’s solution!

1 Like

I think you’ve made a good point regarding not been constrained by just using Chainlink for collateral assets only. I personally think it makes sense to switch to Chainlink where it’s available. These assets are:

Collateral Assets

  1. WSTETH
  2. USDC
  3. DAI
  4. WBTC
  5. UNI
  6. LINK

Cross Assets

  1. USDT
  2. ENS
  3. SHIB
  4. MATIC
  5. CVX
  6. MKR
  7. PERP
  8. AXS

Isolated Assets

  1. FTT
  2. LDO
  3. AAVE
  4. SNX
  5. OGN
  6. GRT
  7. 1INCH
  8. DPI
  9. RAI
  10. WNXM
  11. ANT
  12. BADGER
  13. GTC
  14. APE
  15. YFI
  16. ILV
  17. NMR
  18. MIM
  19. IMX
  20. LUSD
  21. LRC
  22. REQ

If everyone agrees we could proceed with an eIP.

3 Likes

We support this proposal to move the price oracle from UniV3 TWAP to Chainlink. The Merge will open a greater potential for inter-block price manipulation attacks on decentralised price oracles. Moving to Chainlink will increase market security while keeping the system risk-free.

Additionally, as stated above, the system will use Chainlink wherever available. For other markets, it will use Uniswap V3 TWAP. This will make the system still permissionless.

1 Like

@seraphim I am not skeptical of this proposal, but i will abstain from voting

My reason for this is an NZDS/USDC Pool Incident that happened a while ago on DFX Finance due to the Chainlink price oracle fault. You can read about it here in this medium article: NZDS/USDC Pool Post Mortem. Website | Twitter | Telegram | Discord… | by DFX Finance | Medium

In short…

During the weekend of July 01 to July 03, the NZDS minor price movements occurred at regular intervals on DFX. The prices provided to the protocol by Chainlink had a small range between 0.61 (0.612755) and 0.62 (0.620340).

It would be wrong if, one day, some other asset out of the blue would start to provide incorrect prices that would cause liquidations for no reason.

2 Likes