WBTC's (and others) pricing mechanism on Aave

[bgdlabs]

TL;DR

Give some visibility to the Aave community about the pricing mechanism on Aave (oracle), specifically about WBTC, but possible to extend to similar asset types.

We don’t see any problem with WBTC at the moment, but given its importance, its pricing strategy should have visibility and be opened to discussion.

Context

As probably the broad Aave community is aware, pricing assets on Aave is done via integration with price feeds of the Chainlink network. From the protocol perspective, this integration is fairly simple: every asset address has associated with another smart contract address, in charge of providing a numeric price; this address is (generally) one Chainlink price feed smart contract for a pair ASSET/ETH (or USD).

We used “generally” before because there are exceptions. They are required when, for example, due to the complex nature of the asset, apart from querying an ASSET/ETH (or USD) feed, you also need to apply some extra numeric transformation on top. One clear case is what sometimes happens with AMM LP tokens, on which, if not possible via Chainlink directly, it is necessary to have an adapter smart contract calculating the final price of the LP token from the prices of underlying.

We could say that the requirement for adapters is the most “technical” decision side of the pricing of an asset, but there are some other aspects to consider, affecting assets like WBTC.

WBTC

Pricing becomes more complex when dealing with assets like WBTC. For context, WBTC is an ERC20 tokenization on Ethereum of locked BTC assets on the Bitcoin network, with the objective of “using” BTC on Ethereum-living applications via WBTC.

As extensively explained on the WBTC portal, the system is based on a mechanism of Merchants (entities of the blockchain space, capable of request mint/burn of WBTC) and Custodians (mainly BitGo, keeping the BTC backing WBTC safe). This system has always been working well, and there is no symptom at the moment to think it doesn’t.

But from the Aave protocol perspective, the pricing of WBTC is actually different than other assets. Aave v2 Ethereum assumes the price of WBTC is equal to the price of BTC, by using a BTC/ETH feed.

For non-expert users, this can seem legitimate: if the system of creation/redeem of WBTC works and the BTC reserves are completely secure, why the price of WBTC would not be the same as BTC?
For more expert users, a counter-argument can be easily built: fundamentally, WBTC is not BTC. There is a strictly higher risk of holding WBTC vs BTC, doesn’t matter if this risk converges to 0 in some cases on the secondary market of WBTC, it just exists.

For the Aave protocol, the rationale is actually a bit more complex, and there is good reasons to price WBTC based on BTC.

The liquidity of WBTC is not the same as the liquidity of BTC. They are actually in a completely different order of magnitude, with WBTC in the hundreds of millions daily volume, versus BTC being the most liquid crypto-asset, with tens of billions of daily volume. When WBTC was initially listed on Aave v1, this difference liquidity-wise was even bigger. Factually, it was not a good idea to price WBTC depending only on the secondary market.

But why this makes a big difference to Aave? There are ~$3.7b WBTC minted at the moment (some of them not exactly on Ethereum, but bridged to other networks). Only Aave v2 Ethereum has ~$550m of WBTC collateral. In addition, the risk parameters of WBTC are relatively highly capital-efficient, with an 82% Liquidation Threshold. This is possible because the system “assumes” that the asset listed has the liquidity not of WBTC, but of BTC.

Due to the previous reasons, the case of Aave is different to other protocols’: there is a strong rationale to keep the pricing of WBTC based on BTC/ETH, considering there is no real reason to be concerned about the WBTC security model.

That being said, all topics in the community should be opened for further discussion. And we would like the shed some extra light on the options.

---

During Aave v1 and part of Aave v2 times, there is no doubt that using BTC-based pricing was a better approach, but at the moment, if we compare with assets with similar fundamentals (like reserves-backed stablecoins), it is legitimate to at least discuss if a WBTC/ETH (or USD) is really an acceptable mechanism, even considering the size of Aave.

From our perspective, especially in these times of market down-trend, a change to a WBTC/ETH pricing (or USD) on all the Aave pools can be considered, but we think the following is necessary:

• Risk parties should evaluate how solid parameters like the Liquidation Threshold are for such a swap. Also taken into account how problematic is to lower it.
• A deeper analysis of sources of liquidity should be carried out. If the volume from the venues considered is not solid, swapping is definitely not a good idea if we compare it with the counter-party risk of the WBTC underlying system.

In addition, it is important to evaluate even deeper the underlying WBTC system, to understand the edge points of failures. This includes non-technical aspects like:

• Mint/burn historic speed.
• Legal wrappers around the system and implications for holders, Merchants, and Custodians of WBTC.

And technical ones, boiling down to:

• Does the current security setup of WBTC give good assurances?

If there are meaningful concerns with the previous points (we don’t have any reason to think that at the moment), the usage of WBTC (non BTC) based feed can be considered.

And what about other similar assets?

WBTC is actually not the only asset of a similar type on the protocol. At the moment, Aave has similar ones in nature listed, even if they superficially look quite different.

Interestingly enough, the strategy of pricing them is slightly inconsistent (but with rationale about it).

“Stable” assets, reserve-backed

The so-called stablecoins, like USDC, USDT, or DAI. Generally, these are priced based on the secondary market, so the price feeds look like USDC/ETH, USDT/ETH, or DAI/ETH.

The reason not to price them, for example, via a USD/ETH feed is that complexity and trust in the underlying system have not been so so good in past times. That, combined with their type of usage, could introduce risks not easy to calculate if priced based on USD.

Bridged assets

Factually an asset like DAI.e is a reserve-backed one, given that it is based on 1) reserves locked somewhere (in this case, a smart contract on Ethereum) 2) a security mechanism and procedure minting/burning (in this case, the Avalanche bridge mechanics) 3) some secondary market for the bridged asset itself (in this case, for example, AMMs on the Avalanche network).

Different from stablecoins on Ethereum, bridged assets are actually priced on the underlying. This is obviously inconsistent, but the reason is that, for the Aave ecosystem to expand to new networks, there was not really any other solution than pricing, for example, DAI.e as DAI, given that using exclusively DAI.e secondary market liquidity could be extremely dangerous for the protocol.

Even if this risk exists, it can be reduced by introducing extra components, like the Chainlink Proof-of-Reserve integration we are working on.

Path forward on WBTC (and others)

From the BGD technical side, we will try in the really short term to introduce as much consistency as possible with the current pricing policies of the ecosystem, obviously submitted to decisions of the community via governance. Also, we consider that applying Chainlink Proof-of-Reserve will really add better assurance on the different assets.

Regarding WBTC, we have no reason to think Aave v2 Ethereum should swap to price it based on a WBTC/ETH feed, but we also believe it can be discussed.

We hope this post initiates some discussion for if anything should be improved or changed, more on the strategic and risk layers.

[Pauljlei]

While Gauntlet does not cover oracle risk, below are our initial thoughts:

• There can be significant benefits to switching to using WBTC/BTC Chainlink oracle price instead of BTC/ETH. A potential de-peg can be even more negative if the protocol doesn’t make this change as “attackers” would be able to deposit WBTC as collateral and borrow (outsized amounts of stables) out at the BTC rate.
• We are not in a position to provide more in-depth analysis on WBTC mechanics in a way that would provide insight on the probability of a de-peg. Given this, we recommend using the market price of WBTC/BTC as the best estimator for de-peg probability.

We are already using WBTC liquidity for our risk parameter recommendations. So we do consider WBTC as an asset of its own, and as such we recommend changing the oracle to match. Of course, WBTC liquidity conditions (and thus the Value at Risk) can change drastically very quickly in the event of a WBTC/BTC depeg.

We will continue to analyze but again, we recommend switching to the WBTC oracle at the moment.

[tbm]

It would be helpful to better understand the underlying pricing sources for the relevant Chainlink BTC and WBTC feeds (and frankly all feeds used across the protocol). The limited transparency around pricing inputs makes it challenging for independent participants to have a substantive view on liquidity risk.

[bgdlabs]

Thanks for the feedback from Gauntlet @Pauljlei

@Pauljlei

We are already using WBTC liquidity for our risk parameter recommendations. So we do consider WBTC as an asset of its own, and as such we recommend changing the oracle to match. Of course, WBTC liquidity conditions (and thus the Value at Risk) can change drastically very quickly in the event of a WBTC/BTC depeg.

This is an extremely important aspect, and we agree it probably encourages swapping to price based on WBTC, instead of BTC; or at least it reduces the market-risk of doing a swap.

We would like to know the opinion too of Chaos Labs, the other active risk contributor. cc @omergoldberg

In parallel, could be really useful if Gauntlet & Chaos Labs do a networks/pool-wide analysis of assets of similar nature. For example, BTC.b is in a similar situation, but in that case way more supporting on using BTC, given the size of BTC.b itself (still, open for constructive discussion).

[omergoldberg]

Definitely - we’re wrapping up an initial risk analysis of WBTC/ETH oracle migration and will be sharing it shortly.

Agreed, a mapping of these assets and oracle assessment/ and network/pool-wide analysis will be impactful. Will share more here soon.

[OriN]

BTC vs. WBTC Oracle Analysis

Disclaimer: This is an initial analysis conducted by the Chaos Labs team with primary consideration on oracle manipulation costs and the market liquidity for WBTC. We are continuing to investigate potential concerns and areas of analysis to better inform the community with regards to switching the oracle from BTC/ETH to WBTC/ETH.

Risk Assessment Methodology

Our primary objective for this analysis was to understand the risk involved with switching the oracle feed for WBTC pools on Aave from BTC/ETH to WBTC/ETH, specifically:

1. Research WBTC-specific attack vectors
2. Identify the liquidity sources behind the WBTC/ETH Oracle
3. Estimate the cost of attack in each scenario
4. Determine if the attack is feasible under the current state of liquidity

Motivation

Historically, the WBTC/BTC has been relatively stable at 1:1, but recently it has begun to decouple. We have no reason to believe there is a risk of the underlying assets held with Bitgo, but the gap in price impacts the economics for users interacting with the asset on Aave.

If a depeg were to occur, it would likely happen too fast for the protocol to appropriately respond if using the BTC/ETH oracle price. Together with the risk to the protocol (infinite supply of worthless WBTC as collateral based on incorrect prices, which could, in theory, allow a user to drain all assets from the protocol), it has a low probability but a huge impact.

WBTC/ETH Oracle Migration Considerations

High volatility that converges back to the peg can cause WBTC collateralized position to get liquidated when the peg is broken for a short time significantly enough, e.g., supply WBTC, withdraw USDC if we assume that the BTC rate stays relatively unchanged and position health is 1.1. If WBTC/BTC falls to 0.85 and then returns to 1, in the short period the peg broke to 0.85, the position would be liquidated.

The primary risk of switching is from oracle manipulation due to the relatively lower volume than BTC (as @ebaodo noted above). Oracle manipulation has become a higher-priority concern in the market due to falling market caps and depressed liquidity. Still, it is not one that we view to be very likely. Unfortunately, the details are hard to assess precisely because AAVE uses Chainlink Oracles, whose composition needs to be clarified. We assume the Chainlink Oracle uses a volume-weighted average price across the different CeFi and DeFi venues with the deepest liquidity.

WBTC Daily Trading volumes have been ranging around $100M-$500M during the past six months with minor exceptions.

Oracle Risk

We would appreciate more community feedback around the risk appetite for these types of attacks, but we can provide data to help quantify the risk of oracle manipulation:

1. We can see there’s little liquidity on CeFi vs. DeFi for WBTC.
2. Moreover, the constant product of the v3 infinite-range position on uni v3 makes it hard to manipulate, as described by Seraphim in his post on the Euler forum. Because the oracle price is a weighted average of the most liquid venues, to manipulate the oracle price, the attacker must manipulate the DEX price, so it is most relevant in the case of WBTC.

Lack of WBTC liquidity in CeFi Venues

It is easy to see that there is not much depth in CeFi:

Binance WBTC/BTC is centralized exchanges’ only truly active pair (>$1m in daily volume).

Below we can see the Binance WBTC/BTC Order Book, which is the most liquid CeFi order book of WBTC. There is a cumulative sum of 677 BTC bids and around 1.2K BTC asks within a range of 7.6% from the current price (pegged). This is thin liquidity and the price can be shifted drastically up or down with $10Ms demand or supply.

Conversely, we can find more liquidity with around 7.3% slippage on Ethereum Uni V3:

But also liquidity beyond the range. As we can see below, there is wide liquidity in the UNI V3 Pool WBTC/ETH covering the entire price range.

Conclusion

As we can see, the majority of liquidity is in Uniswap and any oracle pricing should be significantly based on DeFi venues, not CeFi. We will confirm that this is the case with the Chainlink oracle for WBTC.

Ideally, we believe that using UNI V3 TWAP Oracle would be the best solution in this case, as it further mitigates the risk of manipulation by looking at the DEX pool only. If chainlink oracle also relies on CeFi books, manipulating them could affect the aggregated price. There are more technical considerations to this change that need further exploration, but it would provide a healthy alternative to CEX-dependent Oracles depending on the Chainlink configuration.

Attack Analysis and Profitability

Dump Attack

The maximum losses AAVE can suffer from a WBTC price drop to zero can be $400M (total available borrows). However, the cost of manipulation on Uniswap v3 is very high, as shown below:

• Dropping the price of WBTC 80% down will incur a $320M loss to the protocol ($400*0.8)
• The upfront cost of such a dump is $20K BTC (>$320M at the time of writing).

Therefore, such an attack will likely be unprofitable for the attacker as they will only liquidate other positions but not make any personal gains. We can assume such an attack will be carried out as part of a price manipulation that profits from a leveraged short position elsewhere and AAVE is used as a proxy to increase capital efficiency, i.e. - borrow a huge amount of an asset, dump the asset, then profit from the short position and withdraw nearly all collateral when he borrowed asset price drops.

Pump Attack

The losses that AAVE can suffer from a WBTC pump attack is the depletion of assets from the protocol. Still, the cost of manipulation on Uniswap V3 is much higher than other assets, which makes the attack not likely. As we can see, pumping WBTC 90% will cost over $600M.

The Risky Scenario

In the case of a WBTC depeg, a depletion of liquidity is possible, leaving the asset susceptible to manipulation. However, AAVE is better off with a WBTC Oracle than with a BTC Oracle that will provide inaccurate prices.

Conclusion

In summary, we believe a WBTC/ETH Oracle is less vulnerable to manipulation than most price oracles used by the AAVE protocol currently. For example, using Uniswap V3 as a cost benchmark, we can estimate the following:

• ~600M to pump WBTC 90%
• ~$330M to dump 80%

Despite the small likelihood of a black swan event (WBTC de-peg), we believe the benefits of migrating to a WBTC oracle are advantageous to retaining a BTC/ETH price feed and therefore support migration to the WBTC/ETH oracle.

[monet-supply]

Is there any case where the protocol should use a WBTC/BTC price above 1? Seems like this would not provide additional safety (any short squeeze / pump on WBTC should be quickly eliminated through minting, and even if minting is temporarily paused the fundamentals of WBTC will not sustain a price above 1:1 for any length of time), while opening up the possibility of price manipulation using WBTC as collateral to drain other assets. I think if Aave chooses to use WBTC/BTC oracle along with BTC/ETH to determine WBTC value, the WBTC/BTC leg should probably be calculated as min(WBTC/BTC, 1).

Even for the WBTC/BTC<1 downside price case, I find the risk/reward of using WBTC price to be unclear. In the case where manipulation is not taking place and the price fall reflects realistic loss expectations (due to WBTC being hacked, etc), how much insolvency losses would Aave be able to avoid by attempting liquidation of WBTC collateralized positions? This depends on how quickly and far price falls but I would guess Aave could still end up with significant realized losses. And in the alternate case where the price crash is the result of baseless fud or market manipulation, Aave could realize significant losses needlessly.

As an alternative, I think it could be suitable to continue using BTC/ETH price for WBTC, and then use the WBTC/BTC price feed as a sort of circuit breaker to reduce risk of insolvency without immediately liquidating positions. Eg. if WBTC/BTC<0.9, Aave could automatically pause borrowing across all assets, pause supply of WBTC, and potentially reduce WBTC liquidation threshold, which would prevent additional liquidity from being removed from the protocol while the situation becomes more clear. On the flip side, if WBTC/BTC>1.1 Aave could automatically freeze WBTC borrowing to prevent excessive borrowing from this pool. While this sort of circuit breaker mechanism would require additional time and development work compared with updating the price feed, I think it may offer greater protection against both WBTC solvency risks and market manipulation.

[CL_Michael]

@tbm

It would be helpful to better understand the underlying pricing sources for the relevant Chainlink BTC and WBTC feeds (and frankly all feeds used across the protocol).

@OriN

We assume the Chainlink Oracle uses a volume-weighted average price across the different CeFi and DeFi venues with the deepest liquidity.

Happy to help shed some light here. Chainlink Price Feeds incorporate three layers of data aggregation (data sources, node operators, oracle networks) to ensure accurate market prices are available for DeFi apps like Aave. Each oracle node in a feed sources data from multiple premium data aggregation firms that provide market-wide pricing derived from combining data from a wide range of established CEXs and DEXs.

Data from providers usually take the form of a Volume-Weighted Average Price (VWAP), or similar data aggregation methodology, to ensure broad market coverage. Additional data quality measures are also commonly employed, such as outlier exclusion, so the final aggregated data point is not impacted. Chainlink’s WBTC feeds follow this approach and provide adequate coverage of the Uniswap V3 WBTC markets.

To learn more, check out our blog post on the 3 levels of data aggregation as well as How Chainlink Price Feeds Secure DeFi for a more holistic overview.

@OriN

Ideally, we believe that using UNI V3 TWAP Oracle would be the best solution in this case, as it further mitigates the risk of manipulation by looking at the DEX pool only. If chainlink oracle also relies on CeFi books, manipulating them could affect the aggregated price. There are more technical considerations to this change that need further exploration, but it would provide a healthy alternative to CEX-dependent Oracles depending on the Chainlink configuration.

Thanks for your in-depth analysis. However, we would advise against the use of on-chain TWAP oracles due to such oracles providing delayed market pricing (which could increase risks of toxic debt during high volatility) and a lack of sufficient market coverage by sourcing market data from only a single trading market. Liquidity for assets like WBTC can rapidly and unexpectedly shift across DEX/CEX venues, potentially putting the protocol and users at risk. As mentioned, Chainlink feeds provide market-wide coverage for assets (CEXs+DEXs), so such liquidity shifts are taken into account before a final aggregated value is produced.

If the community is interested in additional risk mitigation techniques around WBTC, I would also like to note that Chainlink does provide a WBTC Proof of Reserve feed on Ethereum mainnet, as well as a WBTC/BTC feed which could be used in the manner @monet-supply described if desired. In any case, we’re open to supporting any direction the Aave community decides to take regarding WBTC.

[tbm]

Thank you for the additional information - it would be helpful to have the specific data sources ultimately outlined so that there is no guesswork required for independent participants. As it relates to WBTC, is it possible to weight BTC and WBTC oracle prices to provide a combined price which helps mute the all-or-none recovery/default tradeoff? The risk of permanent impairment from manipulated default or cascading liquidations would seem to support BTC pegged pricing, but the lack of transparency into centralized counterparties and limited legal precedent presents recovery and duration risk. Proof-of-reserve is certainly helpful, but by no means sufficient as it is blind to liabilities and liquidity runway, exposing participants to legal and process risk even if the centralized entity is a qualified custodian. To be clear, this is not an indictment of WBTC participants but rather just stating the obvious that under the assumption participants are good actors, recovery in a tail risk event may not be par and almost certainly will not be immediate, implying that a BTC peg price is suboptimal for even a manageable drawdown scenario.

[bgdlabs]

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:

1. They must (and do) include the most liquid venues on-chain (in this case the Uniswap V3 WBTC pools).
2. 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.

@monet-supply

As an alternative, I think it could be suitable to continue using BTC/ETH price for WBTC, and then use the WBTC/BTC price feed as a sort of circuit breaker to reduce the risk of insolvency without immediately liquidating positions.

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.

[bgdlabs]

Following the previous discussion, and as we think this decision is fundamental to be done before the Aave v3 Ethereum activation, we have created a Snapshot vote for the community to decide which is the best approach to follow from now on what respects WBTC pricing.

The proposal will be open to vote in 24h on https://snapshot.org/#/aave.eth/proposal/0x2b95df8c7b2141acdead83beb4cdede9624bb2a4c74f873a5727e2a54f322525 and given that its decision will be applied for the Aave v3 Ethereum setup, we think it is mandatory to have the same requirements as Level 1 on-chain: 320k on the “winning” option, and 80k differential between both