Gauntlet - Synchronicity Price Adapter "Killswitch" Functionality for LST Emode

Gauntlet - Synchronicity Price Adapter “Killswitch” Functionality for LST Emode

As highlighted previously, the CSPA 2.0 solution would guarantee synced price updates between LSTs and their BASE tokens. Moreover, BGD is in the initial phases of preparing the oracle update for implementation. Currently, for many LSTs, LST/BASE ratios have a lot of natural variance due to the oracle implementation. CSPA 2.0 smooths out this variance, which is necessary for enhanced capital efficiency on emode.

Severe dislocations (i.e. extreme variance) between LST market price and LST smart contract price are extremely rare and unpredictable and could hurt the viability of the CSPA 2.0 solution. To further improve on CSPA 2.0, Gauntlet recommends that the Aave protocol limit LST borrowing power when these abnormal dislocations occur. This can prevent bad agents from taking advantage of extreme market conditions to create insolvencies on Aave. We give our initial thoughts below on how LST “Abnormal” Emode could function, in order to best balance optimized capital efficiency in normal conditions and risk mitigation during abnormal conditions. Due to Aave protocol technical setup, these solutions may not be immediately implementatable; moreover, they may significantly impact user experience. Nevertheless, we provide a vision on how these solutions could look to bring the community together to find the best path forward.

In summary:

  • If LST liquidity dries up, we recommend IR curve changes to the BASE asset
  • If LST market price depegs (market price becoming very different from smart contract price), we recommend a tiered approach to lower pool LT to liquidate the riskiest users.

What to consider? Liquidity deterioration, price deterioration, dex staleness

1. Sufficient liquidity supports enhanced emode. Without the necessary liquidity, LST price variance increases. We don’t want large emode positions with high LTV when liquidity is low, since it is much easier for those positions to become insolvent with higher volatility.

  • If: LST DEX liquidity declines by 30% over a 24 hour period
    • Recommend: adjustment to IR Curve for BASE adjustment, double slope 1.

Screen Shot 2023-05-26 at 12.49.16 PM

The above chart suggest that LST liquidity decrease substantially, almost by 50% preceding “icepick” dislocations (May 13), or pool liquidity decreases hand in hand with longer duration LST dislocations (June 9 to June 11, June 12 to June 13), roughly 33%. Outside of LST, the USDC → USDT 3 pool suffered extreme loss in liquidity preceding the USDC depeg.

Increasing slope 1 could decrease the size of LST collateral upon liquidity crunches, significantly reducing the risk of mark to market insolvencies should LST market price drop.

2. Depeg events are preceded by smaller price drops. If LST market price dislocates by 5% relative to its smart contract rate, it must first dislocate by 2.5%. Severe dislocations often occur suddenly, sometimes after market price has already slightly moved away from smart contract rate.
Because the primary pricing mechanism for the CSPA 2.0 solution is the smart contract rate * BASE, if the market price deviates from the smart contract rate, liquidations will not occur, because the price of the LST on Aave has not changed. If LST/BASE has dislocated significantly, we want to reduce high LTV emode positioning ahead of further depeg. We present a tiered approach, with different criteria to activate the next level of intervention.

  • If: LST/BASE market price has deviated by (1-LT)/2 from smart contract rate

    • Recommend: Set LST LTV to 0, Lower LT to LT - (1-LT)/2
    • For instance, suppose hypotetically stMATIC LT is 97.5%. If stMATIC/MATIC market price decreases 1.25%, automatically drop stMATIC LT to 96.25%.
  • If: LST/BASE market price has deviated by (1-LT) from smart contract rate

    • Recommend: Freeze LST supply and borrowing, Lower LT to LT - (1-LT)
    • For instance, suppose hypothetically stMATIC LT is 97.5%. If stMATIC/MATIC market price decreases 2.5%, automatically drop stMATIC LT to 95%.

Afterwards,

  • If: LST/BASE market price has deviated by x*(1-original LT) from smart contract rate
    • Recommend: Freeze LST supply and borrowing, Lower LT to 100 - 2x*(1-LT)
    • For instance, suppose hypothetically stMATIC LT is 97.5%. If stMATIC/MATIC market price decreases 10%, automatically drop stMATIC LT to 80%.
LST/BASE dislocation % LT
1.25% 96.25%
2.50% 95%
5% 90%
10.00% 80%
20% 60%

The goal here is to prevent any mark to market insolvency from materializing by opening up the riskiest positions at each depeg stage to liquidation, since under the CSPA with only primary pricing, these potentially underwater positions would not be getting liquidated.

The graph above shows collateral balances at each LTV level (Debt / Collateral) for Polygon v3 MATIC-correlated Emode pool. Notice most users enact a buffer between their LTV and the pool LT, in this case, 95%. If LST/BASE market price is indeed depegging from the smart contract rate, then we want to remove the riskiest positions at the tail end. Other BASE-correlated pools on other chains exhibit similar patterns.


A final consideration we would like to bring up is regarding excessive DEX data staleness. If there has been no price action or other update to the LST DEX pool beyond a heartbeat time, we recommend pausing this LST market because the data staleness could be due to some potential unforeseen event affecting this LST. We recommend a heartbeat time of 24 hours, given the frequency of DEX updates for LSTs. Should an LST market be paused due to data staleness, a new swap on DEX can trigger the market to unpause.


Ultimately, with the above automated strategies in place, LST Emode can support more aggressive params for higher capital efficiency.

When to return to normal mode?
The emode pool can return to normal functioning when liquidity and/or price recovers.

  • Liquidity: After a 24 hour cooldown, LST liquidity has increased since the start of the cooldown.
  • Price: If LST/BASE market price has recovered, we can increase pool LT to the next “depeg level” up, as shown by the above table.

Options
Gauntlet preliminarily provides a few options regarding how this “killlswitch” market price feature could work for CSPA.

Option 1 - only liquidity dislocation automated intervention
Option 2- only price dislocation automated intervention
Option 3- both liquidity and price dislocation automated intervention
Option 4- no secondary market price based killswitch for CSPA (not recommended)

We welcome community feedback.

2 Likes

Hello @Gauntlet and thanks for this proposal,

At the Aave-Chan Initiative, we firmly believe that the secondary market should not be the crucial focus for LSTs. This is primarily because every LST onboarded on Aave is an asset with a functioning primary market (with ETH being the most recent since the Shapella upgrade). Consequently, the secondary peg will always have inherent market forces working towards its restoration in the event of a depeg.

As a protocol, it’s also essential to distinguish between excess debt and bad debt, with the former being temporary in nature or not necessarily turning into bad debt.

For instance, with large volumes of stETH can be minted in the primary market within seconds, the secondary market for acquiring stETH has become less relevant post-Shapella., it’s also possible to redeem large volumes of ETH from stETH, as evidenced by the 440k stETH redemption event from Celsius.

In the case of Polygon, one stMatic or maticX equates to a MATIC in three days via the primary market.

These observations lead us to a firm conviction that, barring smart contract risks, the worst-case scenarios for LSTs are likely scenarios where the Aave protocol has excess debt, which is likely to be resolved with little to no bad debt after a few days.

The proposed killswitch adopts a more aggressive approach by using the Liquidity Threshold (LT) as a tool and triggering user liquidations. We believe this may not be the optimal approach. Forcing users into a position of potential liquidation, when it’s highly likely their position Health Factor (HF) would have been safe a few days later without any action, does not align with our commitment to safeguarding our user base. Moreover, we are concerned that the killswitch could trigger a self-fulfilling prophecy effect on the secondary market depeg and potentially incite unnecessary market panic. Lastly, it could potentially create opportunities for malicious actors with substantial resources to artificially maintain “artificial” depegs to benefit from liquidations, acquire cheap LSTs, and gain liquidation bonuses.

Despite these primary concerns and observations, we do acknowledge that a “killswitch” to freeze markets and slow down processes might have benefits. Such mechanisms exist in traditional finance, and while DeFi is harder to “control”, it might limit damage in extreme market scenarios.

If a lighter Killswitch is not an option, we’re currently leaning toward Option 2 without the first trigger at 1.25% price derivation which seems too sensitive for us.

2 Likes

:+1: :+1: :+1:

BlockquoteForcing users into a position of potential liquidation, when it’s highly likely their position Health Factor (HF) would have been safe a few days later without any action, does not align with our commitment to safeguarding our user base. Moreover, we are concerned that the killswitch could trigger a self-fulfilling prophecy effect on the secondary market depeg and potentially incite unnecessary market panic. Lastly, it could potentially create opportunities for malicious actors with substantial resources to artificially maintain “artificial” depegs to benefit from liquidations, acquire cheap LSTs, and gain liquidation bonuses.

First, really appreciate Gauntlet’s contribution in initiating the discussion, as we agree that being as precise as possible on pricing LSTs is one of the main challenges these next months and a quite complex topic.

From our side, we agree that some kind of “killswitch” mechanism could be important to implement on assets like LSTs, but we have doubts about the proposed options.


Adjustment of borrowing asset’s rates when secondary market liquidity “dries”

The objective of the first part of the proposed kill-switch is to reduce the size of the LST collateral in the protocol, whenever a de-peg event is noticed on the “secondary market”, due to low liquidity. Our feedback is:

  1. By raising the slope 1 in order to break the “leverage loop”, users get quite hurt, and in a way that could make them migrate away and not migrate back.

  2. If liquidity is low, this can (and is as explained in the second part of the proposal) mean that liquidations are not really attractive on Aave. So increasing the slope just accelerates positions entering liquidation that would not in other cases.

  3. If we trust “primary market” pricing (exchange rate), there should not really be much reason to believe that with the standard slope 1, positions entering in liquidation due to interest accumulation will not be liquidated, as with current configurations would take months to accrue even 2-3%.

    If the peg doesn’t recover for months, the assumption of the primary rate is broken.

So on this part of the proposal, yes, we see the rationale of reducing the exposure of the protocol, but by accelerating debt accrual of positions that most likely won’t be profitable to liquidate already, the mechanic hurts the user and increases the likeliness of bad debt accrual.


LTV0 and LT lowering when primary/secondary price de-peg is detected

Regarding the second part, for us, it feels similar to the first, a bit counter-productive, for the following reasons:

  1. If there is a meaningful dislocation of price on secondary versus exchange rate, that directly implies that liquidating in Aave is most probably not worth it compared with acquiring the LST on DEXes. By lowering LT, in practice, the protocol is swapping the pricing method to some kind of hybrid between primary and secondary, but not really repricing the incentive of the liquidator, because LB stays the same.
  2. Consequence of the previous, if we assume that precisely in those situations of de-peg no extra liquidations will happen, then adding more liquidatable positions doesn’t sound like a good idea. Even more, if we assume the de-peg is temporary (which we should, following the reasoning of using the exchange rate), there could be even problems with “safe” positions once it recovers, if the LT doesn’t change up dynamically too.

So in summary, by lowering LT, liquidations don’t seem to get more attractive for the liquidators - it just increases the number of accounts that can be liquidated. If a user doesn’t liquidate before he likely won’t get liquidated after. Therefore the lowering of LT will likely only show an effect when the peg recovers and healthy positions get liquidated due to temporarily lowered LT.


If we go to the core of the rationale of a “kill-switch”, these protections based on slight adjustments are not really aligned with the main assumption of the system: exchange rate pricing is fair pricing. In practice means, if we see a meaningful risk of permanently de-peg on an LST, the right LT is not 93% or 97%, it is 0; not listing it as collateral.


For us, a kill switch should be more on the side of the proposed LTV0, freezing, and pause actions, combined with some type of Proof-of-Reserve which we are studying to expand from the current use cases on Aave (bridged assets).

We are happy to keep the discussion going, as by itself will provide enormous value to the community and DeFi in general.

2 Likes

Thank you @bgdlabs @MarcZeller for your constructive analyses. We are continuing to ingest your feedback and will come back with more thoughts. We’ve also discussed setting LTV to 0 and freezing the market in the post above within our price deviation automatic intervention; in the meantime we are also considering incorporating options for the community snapshot that contain only these LTV → 0 and LST market freezing levers (separate from the algorithmic LT reduction). We will keep the community updated and welcome more thoughts from the community.

1 Like

We appreciate the initiated discussion and recommendations proposed to address the risks associated with price deviation between the secondary markets and LSD contracts. After careful consideration, Chaos Labs would like to offer our analysis and recommendations:

  1. Freezing Markets: We stand in agreement on the implementation of a killswitch function that reduces the LTV to zero and freezes new supply and borrowing in cases of a price deviation. Such a killswitch would act as a temporary risk mitigation measure to limit the protocol exposure at an early stage of an extreme market scenario without compromising user funds in the more likely scenario of a temporary depeg, or “excess debt” as described by @MarcZeller.

  2. Enabling Proof of Reserve Trigger: Rather than adopting the suggested LT reduction above, we propose the initiation of a proof of reserve trigger that would compel an LT decrease. This alternative methodology leverages reserve depletion as a more accurate and dependable gauge of the LST’s price. In instances where reserves are depleted, we advise a corresponding reduction in the LT, mirroring the losses in the reserve and more accurately reflecting the real price of the LST.

  3. Lowering of Liquidity Thresholds (LTs): We do not support reducing LT as an automated mechanism due to a price divergence between secondary and primary market prices.

Marc Zeller: These observations lead us to a firm conviction that, barring smart contract risks, the worst-case scenarios for LSTs are likely scenarios where the Aave protocol has excess debt, which is likely to be resolved with little to no bad debt after a few days. The proposed killswitch adopts a more aggressive approach by using the Liquidity Threshold (LT) as a tool and triggering user liquidations. We believe this may not be the optimal approach. Forcing users into a position of potential liquidation, when it’s highly likely their position Health Factor (HF) would have been safe a few days later without any action, does not align with our commitment to safeguarding our user base. Moreover, we are concerned that the killswitch could trigger a self-fulfilling prophecy effect on the secondary market depeg and potentially incite unnecessary market panic. Lastly, it could potentially create opportunities for malicious actors with substantial resources to artificially maintain “artificial” depegs to benefit from liquidations, acquire cheap LSTs, and gain liquidation bonuses.

To add to the above, we foresee the liquidation process to be riddled with uncertainty due to the unpredictable profitability and market conditions and believe this could lead to unnecessary liquidations and potential loss of user funds if and when the price of the LST recovers, as observed in the case of the USDC depeg.

In the graph above, we observe the top E-Mode accounts causing the bad debt on Aave V3 Avalanche during the USDC depeg between 03.10.2023-03.13-2023.

The red horizontal line marks the point at which USDC started regaining its peg, followed shortly by the first instances of liquidations (represented by the maroon plot, showing the accumulated amount liquidated). Although accounts were already eligible for liquidations several hours prior, the grand majority of liquidations occurred when the price was recovering, leading to the accumulation of bad debt for the protocol.

Reducing the LTs for LSDs in a similar event of a depeg, could create a similar phenomenon at a much larger scale. Moreover, this could create a cascading effect, pushing markets prices even lower.

  1. Near-term Parameter Updates:
  • E-mode LT and LTV Adjustments: We would advise against increasing the LT and LTV for the current E-modes until the proof of reserve oracle, or other trigger mechanism is fully implemented and tested. It’s essential to ensure that all risk mitigation measures are fully functional before considering any increase in LT and LTV that could potentially expose the protocol to additional risk.

  • Supply Caps: We believe the increase in supply caps for LSD should be evaluated individually on a case-by-case basis, taking into account the unique market conditions and risk tolerance of the community for each asset. Recognizing the strategic importance and the pivotal role of LSTs in Aave’s revenue generation, we do not wish to restrict potential future increments to the implementation of the aforementioned mechanisms. Instead, we commit to appraising any proposed enhancements to the cap as they are presented.

2 Likes

Thanks all again for the feedback and thoughts regarding the potential killswitch implementation. We provide the updated options below and plan to move to snapshot. Given Proof of Reserve is still in development and the timeline is unclear, we recommend moving forward without a Proof of Reserve trigger. Once the Proof of Reserve solution has been formalized, the community can then align on the optimal implementation for it.

The space of possible causes and magnitude for depeg is inherently unknown. Gauntlet’s position is to minimize insolvency risk for Aave in the face of an LST depeg - as a result, some of our proposed solutions necessarily trade user experience to preserve overall Aave solvency.

Killswitch levers

We provide the following levers that can be pulled in the event of a depeg.

Lever Description Implementation Effect Reverts when Tradeoff
A (market depeg) Dynamic, auto LT reduction 1. Activated when LST/BASE market dislocation > 2.5% 2. LB applied on market rate if user is healthy, otherwise applied on smart contract rate 1. Prevent insolvencies of the riskiest accounts with highest LTV, 2. Avoid realizing insolvencies for accounts already unhealthy When LST price increases, auto increase LT Some positions that ultimately are healthy can be liquidated, hurting user experience
B (market depeg) Freeze LST + LTV → 0 Activated at LST/BASE dislocation of 2.5% Prevent additional risky borrow when LST exhibits abnormal behavior When LST/BASE dislocation goes below 2.5% Can prevent users opening positions, affecting user experience
C (liquidity decrease) Double BASE IR Curve Slope 1 Activated if LST DEX liquidity decreases by 30% over 24 hour period, incentivizes risky position closure Incentivize risky position closure When DEX liquidity is no longer decreasing over 24 hr period Can reduce profitability for traders executing leveraged LST loops
D (liquidity decrease) Lower LTV to non emode params Activated if LST DEX liquidity decreases by 30% over 24 hour period, incentivizes risky position closure Prevent risky borrows When DEX liquidity is no longer decreasing over 24 hr period Can prevent users from opening positions

Implementation for Lever A above. For context, stMATIC market dislocation has not breached the 2.5% barrier since the start of 2023.

LST/BASE dislocation % LT
1.25% 97.50%
2.50% 95%
5% 90%
10.00% 80%
20% 60%

Options

We provide the following set of options to the community.

Market / Smart Contract depeg protection Market / Smart Contract depeg protection Liquidity decrease triggered protection Liquidity decrease triggered protection
Option Lever A - dynamic, automated LT reduction Lever B - freeze LST + LTV → 0 Lever C - double slope 1 of BASE Lever D - lower LTV to non emode LST params
1 (Gauntlet choice) x x x x
2 x x
3 x
4 (NAY - no killswitch)

Again, Gauntlet’s position is to minimize insolvency risk for Aave in the face of an LST depeg - as a result, some of our proposed solutions necessarily trade user experience to preserve overall Aave solvency. Thus, we recommend Choice 0, the choice that offers the most protection. We aim to be transparent about the benefits of all the levers and the impacts on the user experience they bring. It is up to the community to align on potential killswitch options based on its risk preferences.

We recommend Lever A in addition to lever B because Lever B is a weaker lever that prevents additional insolvency risk during a permanent depeg, but does not reduce existing insolvency risk.

  • Without LT reduction, all positions with User LTV > final LST fair value price are insolvent, whereas Lever A provides the opportunity for those riskiest positions to be liquidated. Here, the riskiest positions that can still be safely liquidated have a chance to be derisked with LT reduction.
  • The key is that the reduction is dynamic. As we noted in our previous post, should the LST market price begin repegging, the LT increases back to the next tier. This means that sufficiently collateralized positions can no longer be liquidated.

Lever C can help reduce existing positions before potential depegs occur, likewise Lever D can help prevent additional positions from being added before potential depegs occur.

Next Steps

We welcome community feedback and we will put up a Snapshot on Monday, July 17.

Appendix

We walk through how Lever A will prevent additional insolvencies relative to Lever B. Lever A enables the ability to liquidate the riskiest positions that are still healthy, which reduces potential insolvencies.

Let Screenshot 2023-06-22 at 5.49.54 PM represent the price trajectory of the depeg of the LST at time t.
Let Screenshot 2023-06-22 at 5.50.42 PMrepresent the minimum price realized during the depeg, and Screenshot 2023-06-22 at 5.51.59 PMis the final fair value smart contract price, which should equal the final stabilized market price.

OnceScreenshot 2023-06-22 at 5.49.54 PMconverges to Screenshot 2023-06-22 at 5.53.11 PM, Lever A can reduce insolvencies for all accounts with Screenshot 2023-06-22 at 5.55.34 PM, which lever B cannot.

  • If at time t, Screenshot 2023-06-22 at 5.56.10 PM, liquidation bonus is applied on the market rate. Otherwise, liquidation bonus applied on the smart contract rate.
    • This provides sufficient incentive to derisk currently healthy positions, but at risk to become unhealthy, while avoiding liquidations on already unhealthy positions that can further drive them into insolvency.

Again Screenshot 2023-06-22 at 5.56.47 PM can be unknown during the depeg. Thus iteratively derisking excessively risky positions - positions with the highest chance of becoming insolvent - during a depeg can prevent insolvency, especially in the initial stages of the depeg, when liquidity has not considerably deteriorated.

AsScreenshot 2023-06-22 at 5.49.54 PMcontinues to decrease, we know that during the course of the depeg, there will exist some time Screenshot 2023-06-22 at 5.57.50 PMwhere for Screenshot 2023-06-22 at 5.58.24 PM, liquidation volume will decline dramatically due to excess slippage. However, onceScreenshot 2023-06-22 at 5.49.54 PMstabilizes and begins recovering fromScreenshot 2023-06-22 at 6.00.23 PM, liquidation volume will increase, as seen during the USDC depeg. Here, the following take place.

  • automated LT increase to the next tier prevents sufficiently collateralized users from liquidation
  • liquidation based on the current smart contract rate prevents damaging liquidations for positions with Screenshot 2023-06-22 at 6.01.08 PM, if current smart contract rate >Screenshot 2023-06-22 at 5.49.54 PMhas not yet been updated based on chain uncertainty.
  • accounts with LTV just under Screenshot 2023-06-22 at 5.49.54 PM, in other words, the riskiest accounts still solvent, are able to be liquidated.
    • This can prevent additional insolvency because Screenshot 2023-06-22 at 5.49.54 PMis inherently unknown for future t and could further decrease. Screenshot 2023-06-22 at 6.03.38 PMcan be less thanScreenshot 2023-06-22 at 5.49.54 PMfor any t, even while LST market price is “recovering”. In this case, liquidating positions where Screenshot 2023-06-22 at 6.05.16 PMcan prevent additional insolvency, relative to only freezing the LST.

AsScreenshot 2023-06-22 at 5.49.54 PMconverges to Screenshot 2023-06-22 at 6.07.18 PM, with Lever A some initial accounts with Screenshot 2023-06-22 at 6.07.23 PMhave been safely liquidated, which Lever B is unable to do.

We put the snapshot up here. Voting begins in 24 hours and lasts for 3 days.

Thank you to everyone who participated in the discussion and voting for the Killswitch Snapshot. As an update, Option 3 was approved (reached quorum), which implements Lever B above. Option 1 received support as well but did not reach quorum.

We will follow up on the next steps. In a community as decentralized as Aave, it is great to see the collaborative effort to continuously innovate Aave in risk management and beyond.

3 Likes