Angle Protocol - Core Module V2

[Picodes]

[Note: this text can also be read here: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.]

Over the past month, the USDC depeg and the Euler hack have highlighted several vulnerabilities in our Core Module, emphasizing the need for a better model that reduces risks for agToken holders.

That being said, we would like to present the current state of our thoughts regarding the design of a “Core Module V2” for the protocol. Our aim is not to delve into technical details but rather to discuss the overall plan to ensure we are moving in the right direction.

Objectives

To begin, we will outline the key requirements that the future system must meet:

1. The design should allow for mints and burns with low slippage to allow easy usage of the stablecoin and enable smooth Borrow Module liquidations.
2. The design should be scalable.
3. The design should be able to autonomously withstand unforeseen events, such as black swan events or hacks, without requiring any governance intervention.
4. The design should treat all stablecoins holders equally in the event of a black swan event, without any bank run possibility.
5. The design should be robust enough to accept any backing denominated in Euros, including stablecoins, yield-bearing tokens, and real-world assets.
6. The design should be able to properly diversify and segregate risks among all the assets comprising its backing. This is a challenging task as the natural tendency is that automated systems are frequently left holding the weakest assets.
7. The design should not expose users to any foreign exchange risk.

Overall, these requirements will help ensure that the new Core Module V2 is reliable, resilient, and fair for all users.

Design

Now, here is the design we have in mind. Let’s explain the design we have in mind through the scope of a € stablecoin (agEUR) backed by a basket of €-denominated assets.

For example, assume there are two assets, EURA and EURB, and the current reserves are 1 million EURA and 2 million EURB, respectively, backing 3M agEUR. We denote by p_A and the EURA/EUR and EURB/EUR prices.

The system will involve three primary actions:

• Primary Action #1 - Redemption curve: Users can redeem 1 agEUR for a proportion of each reserve asset, minus a fee. For instance, in our example, redeeming 1 agEUR would involve swapping it for 0.33 EURA and 0.66 EURB. This action can be performed even during a black swan event without affecting the risk or underlying exposure of any other agEUR holder. It does not depend on the prices of the backing assets as the system simply exchanges a portion of the agEUR total supply against a portion of the reserves. A fee would be applied depending on the collateral ratio, with a peak just below 100%. This would deter users from starting a bank run as they’d have to pay slightly higher fees in case of small transitory depeg. The following figure would apply that plots how we could set the value redeemed by the Redemption Curve depending on the Collateral Ratio.

The goal of the decreasing redemption quotes as the collateral ratio starts to get below 100% is to disincentivize bank-runs and attacks on the currency peg and reward users who wait for a transitory downturn to pass in a sustainable way. This is a mechanism inspired by Gyroscope.

• Primary Action #2 - Burn: Users can burn 1 agEUR to redeem an asset worth min(1, p_A, p_B)*(1-fee). This is intended to be the most advantageous burning method if all p_i are close to 1 only. Otherwise, it should be more advantageous to use the first method. This way, the system has a good UX in its normal state but preserves its exposures in the case of black swans to treat all users fairly.

• Primary Action #3 - Mint: Users can mint 1 agEUR against a specific asset priced by bringing max(1, 1/p)/(1-fee) asset. For instance, if EURA is priced at 0.999 and the fee is 0.1%, then 1.002 EURA can be exchanged for 1 agEUR.

To set the fees we define fees functions f^{mint}_{A}(e_A), f^{burn}_{A}(e_A), etc where e is the exposure to the asset. In our example, e_A = 33.3%, e_B = 66.6%. Using these functions we can incentivize convergence toward target exposures to the underlying assets.

To set the fees, we will use the fees functions f^{mint}_{A}(e_A), f^{burn}_{A}(e_A), etc., where e_A is the exposure to the asset. For example, if there are 1 million EURA and 1 million EURB, and EURA represents 50% of the total exposure, then e_A=50%.

Assuming the system targets a 50-50 exposure, we could use the following functions as examples:

Defining such functions would naturally discourage users from minting with EURB or burning with EURA. Over time, the exposure should converge to the zone where fees are low, thereby incentivizing users to maintain an exposure of the system close to 50-50.

Furthermore, the proposed system could allow other modules to mint agEUR within a limited exposure to add liquidity to AMM pools. For instance, a Curve Deposit Module could be released, capped at 20% of the global exposure, that could mint agEUR to add liquidity to a agEUR-EURC pool on Curve. In case of a depeg of EURC, all the Curve liquidity would be swapped to EURC, but the effect would be limited to 20% of the global backing.

Here is the detailed example under the form of a spreadsheet: https://docs.google.com/spreadsheets/d/1cbwHlBVYsUoYE6pUKBsKnrpd8iFPawM4T1tK0xI8_kE/edit?usp=sharing

Properties

The system thus has the following key properties:

1. UX: The system enables minting and burning with limited fees from a wide range of assets
2. Scalability: It would work similarly with $1m TVL as with $1bn TVL
3. Resilience: All its underlying mechanisms would be fully autonomous and hence predictable by all stakeholders. In case of a black swan event, just like in the Gyroscope design, it’d provide reasons to bet on the stablecoin returning to its target price.
4. Fairness: There cannot be any bank run or case where the first users coming for a redemption end up better off than the ones coming after. This is particularly helpful in the case of a black swan of one of the stablecoins in the backing.
5. Robustness: The backing system can be diversified with multiple stablecoins like EUROC, EURe, or EUROe. It can also work with other assets in the basket like yield-bearing Euros.
6. Safety: If fees are properly set, the design provides incentives to bring the basket of reserves to a target desired allocation: this ensures that the risk of the system is properly diversified. In case of a depeg, it is unprofitable to perform trades that will leave the protocol holding the weakest asset (contrary to what happened to Maker during the USDC depeg).

By properly diversifying risk, the system should be safer than any of the assets in the backing alone. The system should be more resilient than any of the asset in the backing alone.

[Sebastien]

Very good design. At @steakhouse , we provided an allocation framework (USD stablecoins) for MakerDAO. If I understand correctly, the design takes a target allocation as input and incentivize people to keep the allocation.

A few points:

• A bank run is still possible if there is a lag in the oracle, would probably need some volume limitation (while action #3 already have some strong fees to avoid too many deviation).
• For action #1, I’m not sure this is scalable. If you have some tokens which have a big spread. Less liquid RWA, even ERC-20, will also be easier to manipulate Oracle wise (low liquidity and/or delayed Oracle). Could be fixed by putting a penalty fees and assuming the full redemption is only an emergency mechanism.
• To continue on the pervious point, a stablecoin should have a liquidity buffer (e.g. stablecoins) and an investment buffer. The liquidity buffer should be depleted before starting to have to impact the investment buffer (for which, buying and selling might have more complicated implications, e.g. high fees).
• If EURA depeg to 0.80, wouldn’t that lead to put high fees on EURB minting and low fees on EURA minting?

Let’s say you have an asset which is EUR-RWA which doesn’t have strong liquidity and transaction fees of 5%. The target is 33% EURA, 33% EURB and 34% EUR-RWA. If there is a sell pressure, very quickly the burn fees on both EURA and EURB (when they are at 30% each) will be high leading to a bad peg. Yet, the allocation between EURA and EURB remain very good. Maybe there is a need for tierer approach.

[sogipec]

Thanks for your thoughts @Sebastien!

You’re right on your understanding: the design takes a target allocation that’s defined by how the mint and burn fees are set, and it maintains this target allocation passively (no rebalancing of any sort) by like forcing people to mint or burn for one of the stablecoins in reserve.

On your points:

• The lag in the oracle is definitely a point. Fees would need to be set according to the deviation thresholds. Note however that if someone arb-s the protocol, it would only be able to do this up to the protocol’s limit allocation. Like let’s say that there are 50% EURA and 50% EURB, and EURB depegs, then in the worst case, because of how minting and redemption happen, the protocol could only end up with 40% EURA and 60% EURB, if it does not catch the depeg immediately. The volume limitation probably provides more guarantees, but it can also be an overhead.
• The full redemption is conceived as an emergency mechanism, but that never needs to be activated manually by any governance, because it is always there. The redemption curve also needs to apply some basic fee (like 0.5%).
• Excellent point on the liquidity buffer. The interesting thing here is that if fees are well set, people when redeeming could essentially come to burn for stablecoins before redeeming for the more illiquid asset. The redemption curve is built such that if there are EUR-RWA in the reserves, then these wouldn’t have to be sold to anything in the redemption process, they’d just be transferred to the addresses redeeming.
• For EURA depeg, normally it should only make minting from EURA more expensive. 1 EURA gives 0.8 agEUR + fees. And the higher the exposure to EURA (if beyond targets), the higher the fees.

Understand your point on the tierer approach, I’ll think of ways with which we could solve that. Usually if redemption for EURA and EURB come too expensive, but the protocol is still well collateralized. Then, people can still use the redemption curve and redeem 30% EURA, 30% EURB and 40% EUR-RWA.

[gnrv]

Thank you, @Sebastien, for your feedbacks as always.

For the moment, I am assuming that oracles are reliable, with deviation thresholds .

I tend to see the whole system as an ETF design. I recently learned, the only interaction possible on an ETH “primary market” is redemption against the full basket (in proportion). Otherwise you need to buy/sell on a secondary market.

If we look at the above design, #3 is exactly how you redeem an ETF (modulo some added fees in our case). Note that this method doesn’t worsen the state of the protocol, as they exit proportionally, leaving the same collateral ratio.
#1 and #2 are facilitators and plays the role of a “secondary market”. But instead of letting agents creating the markets, the protocol uses its reserves to make them. This is an additional risk compare to ETFs, because the protocol will sell/buy assets from the basket. The model tries to reduce the risk by enforcing a worst execution price than by going through #3. So protocol accept to trade individual assets instead of the full basket only if it increase its NAV. This is riskier from a protocol perspective, but more likely short term than market makers creating markets on AMMs and arbitraging between those markets and #3.

Fair point on liquidity, what most surely will happen is that non-sophisticated agent will tend to exit more with liquid assets, as redeeming EUR-RWA may not be obvious, leading to having too high reserves in EUR-RWA. But more sophisticated agents may indeed prefer withdrawing EUR-RWA as it has more return value.
Another thought, some of the ERC20 may have restriction on receiver address (KYC), and so may not be redeemable by everyone. How do we handle this case in #3?

Back on the oracles, you are right the model is highly dependent on oracles, and if corrupted, the protocol trades could become unprofitable. It would for sure stop when protocol fees are at 100% though. DAO could set mint fees=100% when ratio is above X% forcing the attack to stop. However, this doesn’t work if two assets are manipulable, as you can alternatively mint from manipulable asset 1 up until it represents X% of the protocol, then mint from manipulable asset 2 until it represents X%, repeat, ending up mostly with the manipulable assets.