[ARC] Risk Parameter Recommendations for Aave V2 ETH (2022-11-22)

As we have seen during the 2 different rounds of liquidations, this is not really true, almost certainly.
In the first round, liquidations even if in relatively not so big size, push the HF above 1. This was supported in good part by the price of CRV pushing down while the liquidation happen.
On the second important round (leading to bad debt), the price while liquidating was not bouncing down in parallel, but slightly going up, kind of expected from buy pressure. What happened then is that the over-collateralization percentage was progressively going down, until the position started to be undercollateralized and, luckily, remain in controlled levels (due to CRV’s price not getting out of control, which shows a pretty healthy liquidity market).
So, if the Liquidation Threshold would have been lower, especially on the strategy that was executed by the shorter, the margin on top of over-collateralization would have been 4% higher (to put things in perspective, the bad debt at the end is on the order of 1.something% of debt position of the shorter just pre-liquidation).
Liquidation Bonus is another aspect that could have helped, but this is more sensitive. If it would have been slightly higher, it is possible (but no certainty) that on a critical moment at the start of the second round of liquidations, the size of debt getting liquidated would have pushed again over 1 the HF, in practice “calming” the price up-trend, same as with the first round. This didn’t happen as we know, as it is understandable that liquidators can’t simply go in size if the bonus doesn’t cover their hedging.
Still, Bonus is complicated, because if that critical moment would have failed with higher, once undercollateralized, the growth of bad debt would have been accelerated.

In a more fundamental layer, the issue is not that 1 year ago the LT was 85%, the issue is that maybe it should not have been.

I find pretty problematic this line of reasoning. Sure, I understand that quantitative there is clear trade-offs, but it is not only about quantitative measures. The Aave protocol strategically has always been both strict and secure on listings, together with welcoming new communities, if the asset is healthy.
Freezing assets that were only enabled to borrow (stables) I assume because of some risk on the upside price on borrowings, doesn’t look good to me.

If there is no alternative proposal submitted in the following hours, it is pretty obvious that people should support proposal 121. But it is extremely concerning that we are in the situation of doing this kind of decision.
I’m deeply involved via BGD on the movement forward of Aave v3 Ethereum, and of course, I agree that a full v3 ecosystem is Aave’s future. But I completely disagree with the policy of “we have Aave v3 upcoming, let’s just freeze almost everything to be on the safe side”.
For sure it is something that de-risks, but I expect a bit more effort.


Chaos Labs supports the proposal made by @eboado and @llama, to disable borrowing of volatile assets on v2, reflected in the table above.

Given the current market conditions and the current level of risk parameters, this is a risk-off and prudent approach. However, this is a temporary mitigation and not a long-term solution.

It would be our preference not to completely prevent users from borrowing these assets, but unfortunately, major changes in LTV & LT would be necessary for adequate risk protection. For example, reducing USDC/DAI liquidation thresholds will trigger liquidations of currently healthy positions and cause unnecessary harm to users that do not pose a risk to the protocol

Reducing Liquidation Thresholds

The proposal to reduce liquidation thresholds for USDC and DAI effectively mitigates the risk of high liquidation thresholds. However, this is a significant change and we wanted to present data to quantify and visualize the effect of such reductions on protocol users. Specifically, we want to surface data around the liquidations this would trigger as some are sizable and warrant a discussion of how these should be handled. We’re focusing on 3 LT levels:

  • Decrease LT by 3% → as voted upon as the Rate of Change Consensus.
  • Chaos identified LT → This is a reduction in LT that aims to find a balance between minimizing fund loss while still reducing LT in a significant manner.
  • LT = 80% → This significantly reduces protocol risk but incurs liquidations and user fund loss.

Main Insight

While a liquidation threshold of 80% is the most effective in de-risking the protocol it incurs large liquidations across USDC and DAI. Updating the USDC LT to 84% and DAI to 83% respectively, present a significant LT reduction while minimizing user losses (if the DAO is willing to consider this as an option) and give users the ability to incrementally top up or wind-down positions as we aim to move LTs to 80% ultimately.

USDC Effects of Reducing Liquidation Thresholds


$USDC LT = 86% LT = 84% LT = 80%
Accounts Liquidated 168 174 331
Liquidation Value ~1.15M USDC ~2.2M USDC ~18.3M USDC
User loss (penalty) ~50K USDC ~100K USDC ~790K USDC

DAI Effects of Reducing Liquidation Thresholds


$DAI LT = 87% LT = 82% LT = 80%
Accounts Liquidated 11 18 34
Liquidation Value ~$1.3K DAI ~$20K DAI ~$890K DAI
User loss (penalty) ~50 DAI ~800 DAI ~$35K DAI

Note → We’ve queried this data from the officially maintained Aave v2 subgraph. There are several known discrepancies with data returned from v2, similar to issues we’ve discovered and fixed for v3. If the community agrees with this as a next step, we can validate all the data via an on-chain simulation and follow up with a targeted governance proposal. An incremental reduction can give users the opportunity to top up or unwind positions.

Looking Forward

We are eager to reactivate these markets with sensible supply and borrow caps on V3 (like the supply caps proposed yesterday) to be accessible to users while maintaining a high-security threshold against potential exploits. However, since the current priority is finding a sustainable solution for these assets on V2 we believe that after disabling borrowing of risky assets, the DAO should address incrementally decreasing risk parameters until they reach acceptable levels. The goal for new parameters for these more volatile assets would be to reactivate them for borrowing more aligned with prevailing market conditions and liquidity.

We are concurrently reviewing all v2 markets to confirm whether or not we view any other assets at risk or if there are opportunities to simply reduce liquidation thresholds and associated parameters instead of disabling borrowing, but may prefer that to be a second-stage decision when reactivating markets as to not impede the near term protection of the protocol via more conservative measures.


  1. Chaos Labs supports disabling borrows, as suggested by eboado in the above table.
  2. Follow up with community investigation into how to:
    1. incrementally decrease risk parameters to enable borrowing without triggering liquidations of currently healthy positions
    2. utilize parameter changes (and potentially treasury incentives) to sunset v2 markets and move positions to v3 in short order

If the bank has bad debts, will it close the bank and not lend to others? If we fall when walking, will we not walk after the fall?Directly closing these virtual currency loans will cause the following problems:

  1. Reduce the number of people using AAVE. It is difficult for people to come back after they leave. When V3 comes online, can you ensure that these people who have left come back? People who do not know the situation will think that there is something wrong when they see the decline of AAVE deposits? Cause herd effect.
  2. The influence of AAVE in DEFI is reduced
  3. Recently, there have been so many events of centralized exchanges. Now, in this event of AAVE, everyone is waiting for the solution of AAVE and the decentralization of DEFI to be better than the traditional centralized exchanges. If this solution is to close the loans in these currencies, then it is easy to understand that our AAVE project is not good, and DEFI is not good either?

Each of the above points is more important to the AAVE project than the loss of 1.6 million dollars. If it is not handled properly, the price of AAVE tokens will plummet, and if it is handled well, the price will soar.

The problem is simple: there are too many other virtual currencies that can be lent out by mortgage, which makes it impossible to quickly complete the liquidation when the market fluctuates sharply.

The solution is simple: reduce the proportion of mortgage loans, that is, reduce LTV.
If the problem is solved well, everyone will rebuild their confidence in decentralization and DEFI

Use your brain to solve problems, not your emotions.

1 Like

Here are my thoughts around what can be done if full freeze is not preferred (aligned with @eboado and @Llamaxyz)

YFI Disable Borrowing
CRV Disable Borrowing , Reduce LTV
ZRX Freeze
MANA Disable Borrowing, Reduce LTV
1inch Disable Borrowing
BAT No Change s
USD No Change
ENJ Freeze ! OR Reduce LTV
AMPL Freeze & RF to 100%
RAI Freeze
USDP No Change
LUSD No Change
xSUSHI No Change
DPI No Change
renFIL Freeze & RF to 100%
MKR Disable Borrowing , Reduce LTV
ENS Disable Borrowing
LINK Disable Borrowing, Reduce LTV
UNI Disable Borrowing , Reduce LTV
USDC Decrease LTV, LT and increase LP (please discuss)
DAI Decrease LTV, LT and increase LP (please discuss)

The community should review also how much LTVs, LTs decreases and LP increases could be done at this point without causing liquidations. The risk parameters including LTVs should correspond the changed market conditions.

Would also be good to review the interest curves to make it more costly to borrow at close to full utilization rate as well down the line.

Also during these times would like to see increase of RF across the protocol and markets.

Other markets should be reviewed (saw that @gauntlet already opened discussions on those markets as well recently)

Actions should be taken for new proposal immediately as the consensus within the community is forming.


As the market risk levels have been constantly increasing, we have been shown some actors are willing to use irrational unprofitable strategies to threaten the protocol.

In this context, it is necessary to fully review the risk calibrations and agree on a risk tolerance for the DAO. Is <.1% of excess debt within the risk appetite? What should be an acceptable break even cost to threaten the protocol? This requires a rigorous review of assets, not just fast reactive adjustments.

The DAO’s current risk-off framework, aproved a maximal reduction of 3% of liquidations thresholds, which implies significant time would be required to derisk de protocol. Furthermore as pointed by @omergoldberg significant parameter reductions are required to derisk the protocol which will generate many liquidations.

On the other hand freezing these assets, allows to immediately derisk the protocol, without negatively affecting users with liquidations. The DAO can then optimise its risk model and progressively reduce risk parameters ensuring maximal user protection at all times.


Swift action is key!

Proposal to Disable Borrows for Long Tail Assets

Hey all - happy to see a constructive discussion regarding the next steps. Reading through the thread, with proposals and support from @eboado, @llama, @stani, and ourselves, it seems that a consensus is forming around the following parameters changes:

Asset Status Proposed Action
$YFI Borrowing Enabled, Collateral Enabled Disable Borrowing
$CRV Borrowing Enabled, Collateral Enabled Disable Borrowing
$ZRX Collateral Enabled, Borrowing Disabled Freeze
$MANA Borrowing Enabled, Collateral Enabled Disable Borrowing
$1inch Borrowing Enabled, Collateral Enabled Disable Borrowing
$BAT Collateral Enabled, Borrowing Disabled No Change
$sUSD Borrowing Enabled, Collateral Disabled No Change
$ENJ Borrowing Enabled, Collateral Enabled Disable Borrowing
$GUSD Borrowing Enabled, Collateral Disabled No Change
$AMPL Borrowing Enabled, Collateral Disabled Freeze, RF to 99%
$RAI Borrowing Enabled, Collateral Disabled Freeze
$USDP Borrowing Enabled, Collateral Disabled No Change
$LUSD Borrowing Disabled No Change
$xSUSHI Collateral Enabled, Borrowing Disabled No Change
$DPI Collateral Enabled, Borrowing Disabled No Change
$renFIL Borrowing Enabled, Collateral Disabled Freeze, RF to 99%
$MKR Borrowing Enabled, Collateral Enabled Disable Borrowing
$ENS Borrowing Enabled, Collateral Enabled Disable Borrowing
$LINK Borrowing Enabled, Collateral Enabled Disable Borrowing
$UNI Borrowing Enabled, Collateral Enabled Disable Borrowing

Next steps

We’ll follow up shortly with a proposal. After these changes are approved, the community should discuss amendments to LT and LTV of different assets, allowing some of the above changes to be relaxed without compromising healthy user positions. We’ll be adding data regarding this soon so we can understand the associated implications of parameter reductions to user positions.

Thank you @Llamaxyz and @MatthewGraham for collaborating on this proposal.


There is some misalignment within the community, based on the variation in prescriptions in the posts above. I want to point out that there are essentially two paths forward here:

  1. Continue supporting tail markets in v2.
  • What are the goals of this when considering oracle manipulation attacks? Enable supplying and usage as collateral but not borrowing? Is borrowing important at all? If so, then we need to decrease LTVs and capital efficiency of all the major assets (USDC, DAI, ETH, WBTC, stETH) significantly to avoid incidents like we saw with Curve.
  • It is worth noting that if these assets are supported, we believe that it is needed to significantly lower the LT of all major assets
    • While USDC was used as collateral in this scenario, if the LT was lower, then a profitable strategy would simply have used the major with the next highest LT as collateral instead
  1. Freeze tail assets and migrate to v3 where there are more appropriate risk controls. (Our recommended option)

Ultimately, the community needs to decide which approach it wants to take. We can help by providing parameter recommendations to ensure that this is done safely and efficiently. Below I will provide some comments on why we prefer option 2, which would involve freezing all long-tail markets now and migrating them to V3, but as mentioned before, the decision and responsibility is ultimately with the Aave community.

For both approaches, we feel that applying a security threshold for guarding against potential attacks is the right methodology when providing guidance and context on specific parameter changes.

All ‘mango squeeze’ strategies (e.g. the strategy against Mango markets and CRV) rely on an agent who is willing to provide enough upfront capital to manipulate prices in multiple markets to manipulate an oracle price. The question of what enough means is the hard part and you can view this as a form of a security budget for each market in a lending protocol like Aave. Given a security budget S for an attacker who is willing to lose money if the attack doesn’t work, one can measure the cost of oracle manipulation by computing the optimal places to spend S to cause a price increase. However, we did not post the security budget that we used in our previous analyses in order not to directly tell an attacker how much money they need to attack a market profitably (in expectation). A month ago, as part of our risk-off framework, we polled a number of community members (including the Aave team and BGD) about how much they thought the security budget of each market needed to be and came to a median number of roughly $100M. This number was also corroborated by looking at the size of the safety module (roughly $300M, at the time) and the maximum slashing limit (30%). We then constructed an optimization problem to measure the minimum cost for manipulating each market such that you are profitable and made alerts for this:

In the table above, `value’ refers to the cost of manipulation divided by security budget, i.e. $100M. However, choosing the particular security budget and the assumption that the attacker is rational (e.g. wants to be expected value profitable) changes the threshold at which one needs to make an adjustment. Our recent proposal to freeze the REN market was driven in part by this type of analysis, as the FTX attacker had over $300M in assets related to REN and the Ren bridge. The posts in this thread and other threads suggest that the community has implicitly decided to lower the security budget. As a community, there needs to be some concrete consensus on this budget before anyone, whether it be us, @monetsupply, or Chaos Labs, can properly decide whether to delist an asset. We agree that the budget should be lower as we now know there are irrational actors (to @Alex_BertoG’s point) willing to execute the strategy at a loss. We note that borrow and supply caps, which exist within V3, allow for the community to precisely control the security budget S (which is effectively a function of the caps and the liquidation thresholds and LTVs of all assets). Having only the coarse controls of V2 implies that there is much more variance in any estimate of the true security budget unless LTs and LTVs for all assets (including all major assets) are lowered.

I also want to address a few points made above:

@eboado: So, if the Liquidation Threshold would have been lower, especially on the strategy that was executed by the shorter, the margin on top of over-collateralization would have been 4% higher (to put things in perspective, the bad debt at the end is on the order of 1.something% of debt position of the shorter just pre-liquidation).

While this is true, there are three nuances to this point:

  1. This is only true if all major assets (USDC, DAI, ETH, WBTC, stETH) have their LTs lowered. As mentioned above, the strategy still works (especially if the agent is irrationally unprofitable) if any LT is sufficiently high. As we saw during the stETH/ETH deviation from par incident, the community has historically been averse to large changes to LTs across the board on majors.
  2. The point of any lending protocol with risk is to have a non-zero Value-at-Risk (after all, that is why you can generate revenue in the protocol). As @Alex_BertoG also mentions, if the community has had a large change in disposition to the maximum allowable VaR, then it is safer to disable the assets and re-enable them with either supply and borrow caps or add them after liquidation thresholds are lowered. These actions are not commutative — there is more VaR in the system if you lower the long-tail asset parameters and then lower LTs of major assets versus if you go the other way (freeze the assets first, lower the LTs of the major asset and subsequently readd the assets).
  3. A higher liquidation threshold generates excess revenue for the protocol — this excess revenue is generated precisely to cover insolvencies and the goal is for the revenue to be higher than the insolvency quantity. We are working on a precise post mortem to do the accounting for this, but I do really want to be clear that “LTs should always be low” is not at all an accurate model here. Another way of stating this is: the dependence of the security budget (if you account for revenue generated to offset insolvencies) on LT is not monotone.

@eboado: Freezing assets that were only enabled to borrow (stables) I assume because some of the risk on the upside price on borrowings, doesn’t look good to me

The point of freezing here, again, does not have to do with the upside price risk as much as it has to do with the security budget. While I, like @tokenbrice and @stani, philosophically like LUSD due to its decentralized, parameterless nature, the fact of the matter is that there is simply not enough liquidity to support a reduced security budget without supply and borrow caps. Being quantitative about the security budget required for delisting assets, even if they were assets that previously provided significant growth to the protocol (and the community has a historical attachment to them), is important for safety (in our opinion).


Also adding a poll here as a temperature check to gauge support for LT reductions across $DAI and $USDC. This would be separate from the proposal to disable borrows above. These recommendations propose to reduce LT by 3%, in line with the Rate of Change Consensus Framework. If sentiment is positive this reduction should include several days notice to give users the opportunity to top up or unwind positions.

$USDC LT = 86%
Accounts Liquidated 168
Liquidation Value ~1.15M USDC
User loss (penalty) ~50K USDC
  • Reduce Liquidation Threshold to 86%, LTV to 84%
  • No Change

0 voters

$DAI LT = 87%
Accounts Liquidated 11
Liquidation Value ~$1.3K DAI
User loss (penalty) ~50 DAI
  • Reduce Liquidation Threshold to 87%
  • No Change

0 voters


Given that we see the possibility of having multiple proposals running in parallel affecting the same or a subset of the same assets, need to clarify some technical aspects of that.
Any on-chain governance proposal approved will be executed on the state of the protocol exactly at the time of execution.
To explain what this means, let’s assume there is a Proposal A with voting running affecting CRV and LINK (freezing), and then a Proposal B is created, affecting the same assets (not freezing them, but disabling borrowing). For the sake of the example, we assume CRV and LINK, before Proposal A creation are both non-frozen and enabled for borrowing. The timeline will be as following (assuming both proposal pass):

  • Time 0. Proposal A gets created.
  • Time 1. Proposal B gets created.
  • Time 5 (1-day delay + 3 of voting + 1 of timelock). Proposal A gets executed. The proposal freezes both CRV and LINK.
  • Time 6. Proposal B gets executed. The proposal disables borrowing on both CRV and LINK, but this doesn’t change factually anything, because at this point, they are already frozen. The nuance here is that, if the assets will be later on unfrozen, they will be disabled for borrowing.

At the current moment, given that the actions proposed involve disabling borrowing, freezing, and raising Reserve Factors, we can confirm there is no possibility of harm to the protocol even with parallel proposals passing. But even if usually the protocol has good protections on the smart contracts against edge cases, better to always be mindful of these nuances.


I fully support @Pauljlei’s proposal, in this situation it is better to cut deep and ‘early’ than to continuously react a posteriori. As a measure of caution and a timely incentive for migration to V3 when deployed, it is worth freezing all the ‘long tail’ assets listed.

We can agree that the assets in that list have different fundamentals, it is worth exploring these differences when the time comes on a case by case basis.

Whilst freezing and unfreezing ‘long tail’ assets at every market downturn is not a sustainable risk management strategy, the recent market events certainly justify it.

In my opinion the downstream effects of all of this have not yet fully played out.
The most obvious one is that in the past weeks liquidity in general has dried up and as expected disproportionately impacted ‘long tail’ assets, introducing higher risk in the protocol which materialized this week.

Disabling only one side of the trade is not enough

The CRV short highlighted only side of the trade and the surprisingly small size of the excess debt seems to have reduced the appetite for a swift response. On the other side of the trade an attacker could still create any fictitious collateral position in one of these ‘long tail’ assets and cheaply manipulate the price and borrow stables, leaving toxic collateral in the protocol. Freezing ‘long tail’ assets that can be used as collateral will at a minimum cap the risk at its current level and over time reduce it as users repay their loans.

Reducing liquidation thresholds is worth exploring on a case by case basis if:

  • it does not materially impact users, if at all, in the short run.
  • it does not significantly increase the likelihood of cascading liquidations given the current levels of liquidity.

Better safe than broke.


The issue with borrowing to start with was that 87% LTV (with liquidation starting at whooping 89) is not small enough when borrowing long-tail assets. It fascinating how well liquidation worked despite that.

But on supply side, LTV is much lower, so should be fine. An extreme example would be the recent CVX price action (though CVX has a significantly smaller liquidity than CRV). I discussed that with Aave team - it looked extreme but not terrible. For the future - would be good if borrowing against a volatile asset would have LTV based on min(chainlink, moving_average) price for collateral (so one wouldn’t be able to borrow much in a temporary price spike)


Looking at the extensive community discussion over the last few days in light of the CRV mango squeeze attack, we appreciate that there are two paths forward for the Aave community:

  • As proposed by Gauntlet in this proposal, freeze tail assets in Aave V2 and encourage migration to V3, where borrow and supply caps enable granular management of risk.
  • Continue supporting tail markets in V2 and change risk parameters on an asset-by-asset basis, i.e., do not be as conservative as in Option #1 above.

Having considered all the arguments in favour of and against this proposal, we have decided to vote YES in favour of this proposal for the following reasons:

  • Market conditions have evolved; liquidity has reduced across the board, causing these long-tail assets to have greater risk than they would have had even weeks ago. Therefore, in today’s market conditions, freezing tail assets that represent only 5% of Aave’s TVL and pose much higher risk is prudent.
  • Freezing assets does not meaningfully impact existing user positions and does not lead to liquidations of healthy positions as reducing the LT for major assets like USDC/DAI would do.
  • The risk profile of attackers has changed. Attacks are not only being done where the expected value is profitable; rather, as in the case of the CRV attack, traders are willing to risk substantial amounts of their own capital even if it is not profitable for them, which can cause insolvency on Aave. This fundamentally changes the security threshold for each asset.
  • The proposal is not one that has arbitrarily decided to freeze all V2 assets, as can be demonstrated by UNI and LINK not being initially included in the list of assets. It aims to protect Aave against numerous market risks, as highlighted by @Pauljlei - insolvency risk from liquidation cascades, price manipulation, traders borrowing stables against volatile assets to avoid slippage, and high utilisation impacting atomic liquidations. Over the past few weeks, we have seen examples of how all of these attacks can potentially be implemented on Aave, and therefore out of an abundance of caution, agree with the proposal to broadly de-risk V2.
  • Freezing the Aave V2 pools will provide additional incentive to migrate to the V3 contracts once those launch. V3 has additional features around supply caps, borrow caps, isolation mode, e-mode, etc. that can help defend against future attacks.

With regards to the proposals to change the LT of USDC and DAI, as outlined by Chaos Labs, we are in broad agreement to incrementally reduce the LT and attempt to protect healthy users from liquidations.

Lastly, with regards to the points made against this proposal, we agree that there must be more granular decision-making in V3, where supply and borrow caps and other features allow for more bespoke decisions. However, continuing to maintain long tail assets on V2 exposes Aave even more to bad debt and to reduce the probability of insolvencies, will require the LT of major assets like USDC, DAI, ETH, wBTC, and stETH to be reduced, which will lead to liquidations for many users across Aave.


Given that the community does not have a parallel proposal for granular risk mitigation and given the recent support for more conservative approach and that time is essence, I will vote YAE for proposals 121, 122, 123 and 124.


Hi Everyone :wave:

@Llamaxyz and Chaos are actively preparing a proposal in line with the conversation above. We hope to have the proposal up for voting shortly.

For those favouring Disable Borrowing over Freezing Reserves, this option will be coming to governance shortly. Thank you for your patience, we will be doing peer reviews (@bgdlabs & Chaos) and ensuring the payload is double checked prior to submitting to an on-chain vote.

Voting YAE or NAE on AIP-121, AIP-122 and AIP-123 will not affect this proposal. The earlier comment from bgdlabs clarifies this.

The AIP will propose the following amendments:


Is that borrowing BAT proposed Enabled a mistake? The current status is actually borrowing Disabled

Correct. Typo has been corrected. Nice work picking that up.

1 Like

Hi all,

We’ve recalibrated our model to additionally relax the attacker rationality factor. The final result and ARC can be found here.


After thinking a bit about both sides - disable borrowing vs freezing, it’s clear the latter isn’t optimal from a UX perspective. However, this proposal despite being conservative makes sense and is justified given the level of activity of these assets and the risk they pose to Aave.

We will be voting in favour of this proposal as 1) it’s a needed and important safety measure under current time constraints and 2) assuming a second alternative proposal does not pass, this proposal will serve as the base case.

Regarding 2), we will also be voting in favour of the proposal by @Llamaxyz & Chaos Labs which reverses the freezing of assets and instead disables borrowing.

Both alternatives are critical to mitigating short-term risks spurred by insufficient liquidity and vulnerable parameters. While we have no strong opinion on which is better as there are solid arguments for both, we do acknowledge that disabling collateral provides a more lenient yet risk-aware solution.


Hey all,

The AIP for disabling borrows on select assets is live here.

1 Like