AIP - 70: Launch a savings infrastructure for agEUR on Ethereum

Now that Transmuter is live and that the protocol has acquired some bC3M in its reserves earning a yield, this is a vote to launch a savings infrastructure for agEUR.

Context

Angle is making a revenue from people borrowing agEUR. On top of its revenue, Angle is currently earning from the tokenized Euro bonds it is owning in reserves. In fact, protocol is controlling 50,272 bC3M (38,446 on the Transmuter contract and 11,826 on the governance multisig) for a value of 5,891,963€. The yield to worst of these bC3M is 3.61% which means an estimated annual revenue for Angle on this asset of 212k€. Right now, 13,043,780 agEUR are considered to have been issued through the Transmuter (these are agEUR that were issued by the Core Module but that are now considered to come from Transmuter at the balance sheet level). This means that the return over assets used to mint agEUR the protocol is making is 1.63%. Technically all agEUR that were minted from the Transmuter could be paid a yearly yield of 1.63%.

For the exact state of Angle Protocol balance sheet, you can check this page.

The borrowing rate paid by people borrowing agEUR is something which can be controlled by governance. As such, it can be voted to be equal to the overall return over asset the protocol is making on Transmuter, and to this extent, all circulating agEUR (and not only the portion corresponding to what was issued from Transmuter) could technically be paid 1.63%.

As mentioned in the original proposal, the space of tokenized securities is growing onchain, and more and more solutions enabling people to earn the € risk free yield are coming onchain. For agEUR to remain a competitive asset people are looking to buy and hold, a savings contract paying all agEUR holders that want it with a yield (proportional to what is earned) is key. It can be a significant growth factor to attract more people towards agEUR with respect to other alternatives.

The interesting element here is that not all agEUR are going to be in the savings contract. Technically if only 50% of the agEUR are in the savings contract, the protocol could offer to the agEUR in the savings contract and without making any loss a return of 3.2%. For the sake of the competitivity of the system, we can take advantage of this to propose yields which are higher than what the protocol is effectively earning.

Proposal

Savings rate curve

Proposal is to deploy a savings contract on Ethereum that has a minting right on the agEUR contract and set its rate according to the following schedule:

The fewer agEUR in the savings contract the higher the rate, and the smaller the return over assets the smaller the rate. Here return over assets and utilization are defined as:

The numerator of the RoA is the revenue the protocol is making on its assets.

In fact, the formula simplifies to:

The parameter y is the max rate that can be set and x is in fact a buffer that the protocol is taking.

This spreadsheet can be used to simulate the shape of the curve for different values of x and y.

Here we're proposing to set it with the following parameters:

• x=0.9
• y=10%

At launch as there are going to be no agEUR in the curve, we're proposing to set the initial rate at 4%.

Borrow rates

The important question to decide on once the shape of the curve is known the borrow rates to set. There can be indeed big arbitrage opportunities if it's possible to borrow agEUR for cheaper than what the savings contract brings: like borrow agEUR at 2%, put these agEUR in the savings contract for 4% and simply get paid 2% for providing no value to the protocol.

Arbitrage are to be put in parallel with the opportunity costs there are for taking it. The arbitrage of someone putting ETH to borrow agEUR at 2%, and staking at 4%, is not the same as the one that consists in putting a liquid staking token earning 3.5% to do the same arb. In one case, the arbitrageur is giving a way a "risk-free" opportunity of 1.5%. There is a tension as well between having important borrow rates (reducing arbitrage opportunities but increasing RoA) and small borrow rates which facilitate demand for native agEUR borrowing.

With all this in mind, we're proposing the following: increasing the borrow rates on all vaults with non-yield bearing collats to 2.5% and on all other vaults to 4%. This means:

• increase borrow rate to 2.5% of: USDC vaults (Ethereum, Polygon, Optimism, Arbitrum, Avalanche), wETH vaults (Ethereum, Arbitrum, Optimism, Polygon), LUSD vault (Ethereum), wBTC vaults (Polygon, Ethereum, Arbitrum), wMATIC vault (Polygon), miMATIC vault (Polygon), wAVAX vault (Avalanche), OP vault (Optimism),
• increase borrow rate to 4% of: wstETH vault (Ethereum), bIB01 vault (Ethereum), bHIGH vault (Ethereum), cbETH vault (Ethereum-, agstk-sd-2CRV vault (Arbitrum), agstk-sd-3CRV vault(Ethereum), agstk-crvFRAX vault (Ethereum), agstk-cvx-2CRV vault (Arbitrum), agstk-cvx-2CRV vault (Arbitrum), agstk-cvx-3CRV vault (Ethereum), agstk-cvx-LUSD3CRV-f vault (Ethereum), agstk-sd-LUSD3CRV-f vault (Ethereum)

Implementation

The savings contract implementation has been audited by Code4rena. It's a simple ERC4626 contract that comes with no further composability risk or risk of funds. agEUR deposited in the savings contract are not invested in other strategies and they are just earning the rate chosen above.

The only operation the contract does is to mint agEUR based on the rate that is proposed. If 100 agEUR are deposited in the contract and the rate is 2%, then after a year, the contract will mint 2 agEUR and the share of the depositors of the savings contract will earn 2% in value, which means they’ll be able to withdraw 102 agEUR. Rate in the implementation proposed accrues on a block by block basis.

In our proposal we have defined a schedule for the rate based on the return over assets the protocol is making. This is hard to implement onchain in a non manipulative way. Here we're proposing the following set of rules to apply:

• the savings contract comes with a maxRate function that can only be set by a governor address of the protocol: this one will be set to 10%
• the guardian multisig can update the rate of the savings contract provided that it's inferior to the maxRate . Here we're proposing to make the mandate of the guardian multisig even clearer. The guardian multisig will be allowed to update the rate based on the schedule above under the following conditions:
  • last update was 7 days ago
  • or, the current rate is too high and causing the protocol to lose money based on the current utilization of the savings contract. For instance if many people come to mint with EUROC thus increasing utilization and decreasing RoA, it may no longer be profitable for the protocol to distribute at the current rate. Formally the condition for the guardian multisig to intervene in this case at a time $t$ writes:

• or, the rate based on the schedule would be different from the current rate encoded in the contract by 0.5%. This writes:

Upon launch, all essential metrics for rate computation should be made available on Angle new analytics

Value to the protocol

Beyond the advantages mentioned above in terms of attractivity for agEUR, this setup provides a high degree of clarity for future agEUR stakers in terms of what they can expect for the yield they get. While there should be some substantial variations in the first weeks, this should converge and stabilize quite rapidly.

If this goes through, a point of focus should then be to increase the system's return over assets through the acquisition of other forms of € securities (like bC3M).

Note that in this setup the protocol is still generating some revenue from its reserves and will be increasing its equity through this mechanism (thanks to the x parameter).

Risks

The risk here is the arbitrage opportunities with the protocol and the protocol paying agEUR too much with respect to what it is earning. The tightly controlled schedule here ensures that if the protocol starts losing, it will not lose for a long time and always come back to profitability. There may be transiently some arbitrage opportunities if the schedule leads to a rate greater than the borrow rate proposed here. If these are taken, this should make according to the schedule the savings rate decrease hence killing arbitrage opportunities.

Next steps

This saving system affects agEUR at the balance sheet level. As such, it could be deployed on any chain where agEUR exists. We propose to stick to Ethereum for this initial proposal.

Voting Options

1. For, deploy savings infra
2. Against, do nothing