From our perspective, it is not really a good option to almost under any circumstance consider swapping to pricing an asset directly from on-chain sources, like Uniswap V3 TWAP, no matter if the source looks healthy.
As mentioned previously by @CL_Michael , the different layers of the Chainlink Price Feeds are simply a net gain over fetching the price from an on-chain venue because:
- They must (and do) include the most liquid venues on-chain (in this case the Uniswap V3 WBTC pools).
- Assuming the perfect functioning of the oracles’ infrastructure (we have no reason to assume the opposite), they add on top other types of protections, like awareness to “flash” manipulations, by dynamically removing outlier liquidity venues, those reporting anomalous price for a short period of time.
In addition, the cost of maintaining different approaches to pricing (e.g. Chainlink and directly Uniswap v3 TWAP) is not really something the community should consider taking on unless there is a complete major reason, which we don’t find realistic.
For extra context, it is worth it highlighting that other protocols of similar nature (e.g. Compound, Euler) progressively followed the lead of Aave in dropping their custom pricing solutions to use Chainlink, as the alternatives were only introducing additional risk, with not really advantages.
Generally, we are not really keen on introducing short-circuit behavior on pricing algorithms. The reason is that for it, important assumptions need to be taken about what an artificial market movement is. For example, if WBTC goes below 0.90 BTC, is there a legitimate reason for it? What about 0.95 BTC? What about 0.98 BTC?
If there is actually some security problem on WBTC, the most correct way of protecting the protocol is actually to be fully correct on pricing, in order to start liquidations as soon as the depeg event starts, that way reducing the room for bad debt. This can appear as going against the current pricing based on BTC/ETH, but the explanation is simple: currently, the protocol simply accepts the security risk aspect of WBTC, considering it not realistic to happen.
To include the security aspects of WBTC on the pricing, the cleanest solution is to use Chainlink Proof-of-Reserce, which factually acts like a short-circuit (we will be updating on the PoR topic from BGD pretty soon). This will be one of our following steps on the PoR integration.
Given that the different analyses on this thread point that using a WBTC feed could be preferable, we will create a Snapshot vote to swap to this approach.
If approved, from our side, we will start working on the technical details of this change, mainly:
- Using an adapter price from the existing Chainlink feed vs using WBTC/ETH (or USD), and the considerations around this considering that Aave v2 Ethereum and Aave v3 Ethereum will have different oracle references (ETH in v2 vs USD in v3).
- The proposal payload to factually do the swap.