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:
- 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
- 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:
- 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.
- 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).
- 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).
