In conjunction with the @bgdlabs team, Gauntlet wants to highlight an important improvement to the current pricing mechanism for LSTs on the Aave protocol. This involves using the Chainlink Synchronicity Price Adapter (CSPA) for a calculated price for LST assets. Other solutions were considered, and the trade-offs in terms of complexity and utility will be discussed. Back-tested data will be provided to support the proposed solution. The changes will impact Gauntlet’s risk parameter recommendations and Emode methodology, and ultimately unlock capital efficiency for the protocol!
Tl;dr Due to differences in oracle price updates for LST and base assets which have fundamental underlying relationships, unintended liquidations can occur. Our suggested solution provides a fix to this issue and drastically changes the risk profile for these assets on the Aave protocol.
Current BGD solution: Chainlink Synchronicity Price Adapter
To briefly summarize the current solution above: the proposed solution will take two Chainlink price feeds, 1.) Asset/USD and 2.) ETH/USD to smooth out price updates for ETH/USD updates. Please read the forum post for more details.
Context around liquid staking tokens (LSTs) and pricing
The current CSPA solution could be slightly improved for LSTs. For the sake of simplicity, we will focus on stMATIC, maticX, and WMATIC for this post. One of the concerns is that a market downturn in the value of WMATIC, the native token of the Polygon network, could result in a price deviations in the value of stMATIC and maticX, two liquid staking tokens (LSTs) used by Aave. The pricing and protocol of these tokens are both tied to the value of WMATIC, and a decrease in the value of WMATIC could result in liquidations of stMATIC and maticX. There has been significant conversation in the community about how risk parameters should be set for LSTs. There is a balance between the desire to grow the protocol through LST collateral usage and the potential risks associated with increased usage. Our stance has been more conservative and cautious than other market participants. One of the main reasons is that we observed the price variance between assets such as stMATIC and WMATIC are more extreme that others assumed.
Gauntlet has been exploring the potential risks of liquidations in an MATIC correlated eMode. This transaction shows that price differences between LST and base asset COULD lead to liquidation. In addition, these are the stMATIC price update delay compared to WMATIC in the last month. The largest difference between updates was 2 minutes, or roughly 60 blocks. We will discuss this impact on price below.
Updated price adapter solution for LSTs: Chainlink Synchronicity Price Adapter 2.0
Note: For all USD denominated assets on V3, please ignore the P_{ETH/USD} term. An example is P(stMATIC/USD) = CL(MATIC/USD) * SC_rate(stMATIC/MATIC) or
P(stMATIC/USD) = 0.864 * 1.07 = 0.92448
To address these risks, Aave has proposed a solution that involves oracle synchronization and monitoring. Oracle synchronization refers to the synchronization of the stMATIC/USD and MATIC/USD oracles, such that updates to the price of MATIC in USD will result in simultaneous updates to both oracles. This would ensure that the price of stMATIC and maticX remain correlated with the value of MATIC, and reduce the risk of liquidations due to market downturns.
In the specific case of stMATIC, the exchange rate (P_{L/B}) could be found at this contract. The proposed solution should look similar to what is currently deployed for the Chainlink stMATIC oracle, with some key differences. As stated above, variance in the oracle updates on-chain allows for increased variance in price updates. In the specific numerical example above, the syntax is identical to the current Chainlink oracle. However, we will show that the actual price updates observed on the Aave protocol will be significantly different.
Historical Visualization
The redline indicates what the expected stMatic rate on the Aave protocol would look like using the updated solution and blue line is the current price updates in the last month.
Additional Potential Solutions
Potential Solution 1: Updated calculated values from Chainlink by altering parameterization
One potential solution we considered was having either the heartbeat or price deviation bands on stMATIC changed such that updates in either stMATIC or WMATIC would be sequentially first. There’s two reasons why this would not work: 1.) You can not ensure that price updates will not lead to liquidations and 2.) This ignores blockchain specific nuances and potential adversarial attacks.
Problem 1a: Price update ordering
Imagine a scenario where the price deviation value for stMATIC is always strictly smaller than MATIC. This would mean that you would expect stMATIC price updates before WMATIC. In extreme market downturn events, this could lead to unnecessary liquidations because stMATIC price is the first to drop. The heartbeat is less relevant in this case because the focus is on situations with large price updates.
Problem 1b: Transaction ordering and potential adversarial attacks
For Polygon in particular, reorgs are a concern. "Reorgs occur when network nodes fall out of sync with each other, and two distinct chains of blocks are produced concurrently. This may be due to a bug, network latency, or even malicious activity. When nodes sync once again, one canonical version of the chain is kept, and the blocks included in the invalid ‘fork’ are ignored.
Potential consequences of reorgs can include delays in achieving transaction finality, reverted transactions, or theoretically, a 51% attack on a (reduced) validator set.
Reorgs of a few blocks are not uncommon, and generally have no effect on users. But this case caused concern due to the ‘depth’ of the reorganization, which included 157 blocks. This could potentially have affected hundreds of users’ transactions." In general, price transaction ordering has a significant impact on liquidations and even insolvencies on the Aave protocol.
The CPSA 2.0 solution mitigates both of these concerns for Potential Solution 1.
Potential Solution 2: Unique Chainlink oracle for LST asset
Another potential solution could be having a unique Chainlink oracle that isn’t calculated for each LST asset. The benefit of this solution would be that need to get quicker market price updates that would not need a smart contract (SC) exchange rate update nor MATIC/USD update. In the proposed solution, the Aave protocol has exposure to SC risk.
Problem 2a: Illiquid primary and secondary markets
The current average daily volume (ADV) for stMATIC is 0.30% of total supply. In order for there to be effective monitoring of the fair market price from both DEX and CEX venues, the traded volume would need to increase. In the absence of trading data, the “fair value” as determined by base price and the exchange rate (the proposed solution) should be strictly better than Potential Solution 2.
Potential Solution 3: Combine proposed solution with unique Chainlink oracle for LST asset
Another potential solution could involve having different weightings for our proposed solution and some unique Chainlink oracle that takes in primary and secondary market trading activity. In this solution, an attacker would need to attack the exchange SC AS WELL AS manipulate the price of the LST on primary markets, which would make an attack far more expensive and less profitable. One potential concern with the proposed solution is that traders could front-run an update on slashing. Let’s take the condition where there is an extreme slashing event of 5% (the value is just for hypothetical purposes). The assumption is that market participants would rather trade against DEXs and CEXs that are pricing stMATIC at 1.07 to MATIC, rather than lend stMATIC at an incorrect price and borrow. This would lead to a primary oracle update far sooner than manual intervention (such as freezing an asset). Therefore, the chances that someone could take advantage of a mispriced exchange rate or oracle is far lower.
This solution faces the same problem as Potential Solution 2.
Impact to Gauntlet emode methodology
Below are the explicit ways that Gauntlet is analyzing risk for LST emodes.
The proposed changes would enable 1.) Higher LT values for each LST/base pair, 2.) increased borrow and supply caps, 3.) more aggressive considerations for our methodology in general as a result of price deviation smoothing. This unlocks tremendous capital efficiency as a result of smoothed price updates. We want to emphasize the we only support more aggressive risk parameters for LSTs if these changes are implemented. More aggressive recommendations from other market participants relied on these incorrect assumptions, but the suggested changes will correct those assumptions.
Next Steps:
- Welcome feedback and questions from the community.
- Move to Snapshot for Chainlink Synchronicity Price Adapter CPSA 2.0