Skip to content

Instantly share code, notes, and snippets.

@0xngmi
Last active June 2, 2024 15:43
Show Gist options
  • Save 0xngmi/c92ce3fce377a0e72c1e90052db98bf1 to your computer and use it in GitHub Desktop.
Save 0xngmi/c92ce3fce377a0e72c1e90052db98bf1 to your computer and use it in GitHub Desktop.
Lending protocol optimized for redeemable assets

Optimized lending protocol for redeemable assets

Currently a significant portion of usage across all lending markets comes from carry trades between an asset and their derivatives.

To explain how this works let's assume that on AAVE borrowing ETH costs 1%, but stETH yields 3%. This opens up a trade where you deposit stETH, borrow ETH, swap it for stETH and repeat the trade again, looping the position and arbing the rates. In this position you earn 3% but pay only 1%, so you're earning 2% net.

Some examples of these trades in the wild are:

  • Flux finance, a compound fork purely focused on borrowing stablecoins against treasuries for carry trades
  • AAVE, which has a 5.8bn stETH and ~1bn weETH, both used for looping against ETH. Together, these account for ~45% of aave's TVL
  • Morpho, which hosts users looping sUSDe against DAI
  • Compound, which hosted large arb trades against cbETH
  • Fluid, where almost all usage is carry trades between weETH and ETH, which account for ~94% of it's TVL
  • Gearbox, that got a lot of traction due to looping LRTs for points farming
  • CIAN or InstaDapp Lite are protocols built around looping LSDs against their underlying

Together, all these bring a significant amount of TVL and revenue to these lending markets and thus are a core part of their business. In on AAVE v3 alone, there's 2.2bn ETH borrowed paying an APY of 2.31%, almost all of it going to LSD/LRT looping, with a reserve factor of 10%, so it's earning 5M/yr for AAVE in fees.

All these assets: treasuries, LSDs, LRTs, eigenlayer deposits, sUSDe... share the pattern that at some point in the future they will be redeemable for their underlying asset.

However, most lending markets were designed for the general case, which is borrowing an asset against an unconnected asset, such as borrowing DAI against ETH to leverage long on ETH. This makes sense since this the general case and it encompasses all borrowing, including that of redeemable assets.

But what if you focused on serving only borrows of redeemable assets? By restricting the type of assets it becomes possible to apply new optimizations that allow for the creation of protocol that's more capital efficient while being safer. It's similar to how curve developed an AMM algorithm optimized for stable swaps vs uniswap's algorithm, which was more general.

For example, all lending protocols operate on the assumption that they need to liquidate positions asap to avoid bad debt if the liquidatable coin keeps going down in price. However that's not the case for reedeemable staked assets such as stETH as they will eventually be redeemable, and thus you can build better protocols without having to enforce that assumption.

How it works

At the basic level it will work like any other lending market, with the following differences:

  • Only has two assets: ETH that can be borrowed and stETH (or any other derivative) as collateral asset
  • ETH can be borrowed with 97% LTV and looping is done very efficiently gas-wise (like in euler)
  • Loans get liquidated at 98% LTV

You'll likely think: wow that's very degen, 97% LTV is insanely high, what if loans can't be liquidated on time?

The magic here is that if no liquidator liquidates a loan and it reaches 99% LTV, the liquidation is taken over by a contract that just takes the stETH and unstakes it to get ETH. If this happens, depositors will likely not be able to withdraw instantly and will need to wait till the ETH is finally unstaked, but it guarantees and nobody will lose any money.

This system will provide higher APRs than other lending markets thanks to higher capital efficiency, while also being safer because it is impossible to get bad debt.

Other mechanisms

A market with very high LTVs will be vulnerable to attacks where an attacker could withdraw the available free coins and cause borrow APRs to spike to their max, increasing their own yield and forcing borrowers to pay a lot.

This attack is already possible in current yield markets but those just defend against it by requiring a lot of of capital to pull this attack.

Our protocol would be specially vulnerable because the high LTVs would reduce the float by a lot and the low liquidation liquidation margins would make it easier to push borrowers into liquidation.

To prevent this, the borrow APR will use a delayed weighted average, so imagine the current APR is 4% and then someone withdraws all money, which would spike APR to 100% normally, instead what will happen is that:

  • After 1 hour: APR 5%
  • After 2 hours: APR 7%
  • After 3 hours: APR 11%
  • After 4 hours: APR 19%

This will give time for other borrowers to close their positions or for depositors to deposit more to take advantage of the APR, it basically just slows down changes to allow market to react faster. We could also cap max APR to make it less dangerous, or slow it down even further.

Liquidation mechanism will be like euler's to maximize the recovery rate upon liquidation for borrowers.

Oracles

There's 2 types of protocols you can build here: one with oracles and the other without.

If you add oracles it will work like a normal lending market, where if price of stETH drops you get liquidated. This will make it more dangerous for borrowers and will add a dependency on oracles, but will ensure that lenders stay liquid.

The other possibility is to make the protocol work with no oracles, instead price will be hardcoded to 1 (an oracle will prevent opening new loans when price is not 1 to prevent arbs but that oracle don't have impact on system).

Since there's no oracle the only way borrowers can be liquidated is if ppl withdrawing cause borrow APR to be higher than stETH APR and then debt from that accumulates to the point where you'll be liquidated.

Pros/cons:

  • Protocol will be extremely immutable, like liquity on steroids. It will have no dependencies on anything external and that will make it very safe and impossible to manipulate
  • Protocol will be very predictable, eg borrowers will be able to know that they'll have 1 week since APR turns negative. This will make it very easy to keep your positions safe and makes borrowing more comfy since you don't need to act instantly.
  • Safe against oracle failures or people manipulating oracle.
  • It's possible that there are periods when borrowers just choose to not close their positions even with 100% utilization, and lenders have their money locked.

It's easy to dismiss oracle issues, however these are very important in high LTV systems because of what happened in Gearbox, where a timing difference in the oracle updates for ETH and stETH led to a user being liquidated even tho the stETH/ETH price didn't move.

Benefits

Risk

The risk of using this will be way lower than using something like AAVE, since instead of being exposed to all assets that are supported by the protocol, you are only exposed to stETH and ETH. Coupled with the liquidator of last resort it makes something like the bad debt that arised from CRV impossible.

Plus you can heavily reduce all the variables involved so you end up with a system that is very basic, and that makes it very resistant to all types of attacks.

If you go for the no oracle version then you end up with a system that has no external dependecies and is just a structure on Ethereum, remove any kind of admin controls and you end up with something like uniswap, which is extremely decentralized and resilient against all types of attacks.

Why use it?

  • Borrowers will use it because they can get high APRs with low risk, that's the easy leg.
  • Depositors will use it in order to remain liquid at the expense of earning a lower APY.

A useful mental model for this is that this creates 2 tranches, a senior tranche taken by borrowers where you get outsized APY but need to take the risk against depegs, and a junior tranche used by depositors where APY is lower but you have less risk and in most cases you'll stay always liquid.

Downsides

ETH on aave might not come from simple ETH lenders but instead from ppl who are borrowing against ETH (eg to leverage long against USDC), these depositors wouldn't come to our protocol.

It might be possible to lessen this problem by pairing the protocol with a generalized lending protocol that accepts LP deposits into their pool.

If there's a huge sudden drop in prices depositos might end up temporarily illiquid, but they'll never lose money.

Oracle vs no oracle

Smol note: Even if you choose to use an oracle, oracle can't impact ETH lenders and if it ever was compromised all it could do was just wrongfully liquidate borrowers. This is unlike other lending protocols like aave, where if oracle is compromised the whole protocol can be drained. This is pretty cool because it further reduces the risk for lenders, you don't even need to trust the oracle!

To consider the changes that an oracle might bring let's use an example: A borrower is borrowing at 97% LTV and liquidation is at 98% LTV, and then stETH depegs by 1%. If there's an oracle what will happen is that the borrower will get liquidated and ETH will be returned to the protocol, if there's no oracle what will happen is that all lenders will withdraw their ETH and interests will spike to max utilization, raising interests to something like 100%. In this scenario, if borrower unwinds their position and repays the loan they will lose 33% of their money, however they can choose to keep paying max interest of 100% and keep the position open for 3 more days until interest pushes them over liquidation, hoping that in those 3 days either other borrowers will repay first or depeg will be closed.

If that happens, users will not be able to withdraw their ETH during all that time (they'll only able to sell their receipt tokens, but that market will likely be illiquid) as utilization is 100%, and if by the time borrower gets liquidated stETH depeg is higher than 2%, it will be impossible to sell at market and instead it will need to be unstaked, making users wait longer to withdraw.

On the flipside, no oracle makes it very hard to manipulate the system to get users liquidated.

The big question is that, if you see this protocol as a tranching system where lenders are the junior tranche (low risk), and they are depositing to get lower risk and more liquidity than holding stETH directly, will the possibility of being illiquid during times of market distress (since that's when stETH depegs, eg 3AC liquidation), which is when ppl usually want to swap their coins, be a deal-breaker for lenders?

So, wrapping up, whether to use an oracle or not is mostly a decision of favoring lenders vs borrowers. If you use an oracle you expose borrowers to manipulation, oracle compromise and force them to manage their positions much faster in a way that is less predictable but increase chances of lenders being liquid faster. If instead you eschew the oracle, then system becomes safer and very predictable for borrowers (eg: can leave for a weekend and i'll be certain that even in worst case i won't be liquidated since liquidations take >=3 days after utilization hits 100%) but at the cost of lenders ending up illiquid.

Conclusion

By optimizing our lending protocol for redeemable assets we achieve:

  • Both borrowers and depositors earn more because the higher LTVs mean that less capital will be left unused/idle
  • Protocol is immune to bad debt, depositors can NEVER lose money
  • If no oracle: no oracle risks and protocol is extremely predictable, no need to be on alert all the time for margin calls
  • Lower risk from APY spikes for borrowers

In other words, higher APY for less risk, the holy grail, possible only thanks to restricting assets supported to a very concrete subset.

@johnquid
Copy link

johnquid commented May 28, 2024

I really enjoyed your writing because I felt it aligns closely to my train of thought. I'll start with your primary point:

All lending protocols operate on the assumption that they need to liquidate positions asap to avoid bad debt if the liquidatable coin keeps going down in price. However that's not the case for redeemable staked assets such as stETH as they will eventually be redeemable, and thus you can build better protocols without having to enforce that assumption.

This is similar to saying all bread is water and oaths to stay above water (instead of oats).
What happens when they don't? More or less, half of marriages end in divorce,
and half of trades are at the expense of the other half. By mass, water is 89% oxygen.

The "magic" you mention is based on liquidation with a very low latency. While preserving this invariant,
as well as the core objective ("provide higher yields than other lending markets thanks to higher capital efficiency"),
"I like my business hushed and Bentleys custom." If you are familiar with how Euler's disk works,
imagine the same in reverse (speeding up increases the amplitude of the delta instead of decreasing it):

liquidate a constant % of the position (but as the position gets smaller,
the value of that % increases until the position is fully liquidated). Meanwhile,
prices have a chance to recover, and since the position is still open, it's "redeemable"
in the sense of able to be saved. Only instead of 3 days, we stretch it over a longer period.

"Liquity on steroids" is actually our legacy C++ repo (deployed in 2019).

"whether to use an oracle or not is mostly a decision of favoring lenders vs borrowers"

their redemption algorithm is also such a decision.

Speaking of disks,
QU!D's latest CD is based on the same underlying root as
your money tree thesis about clipping "bad leaves":
What is the holy grail? It's a chalice, like the one Kali uses
to catch the blood of liquidated demons before they hit
the ground (i.e. get factored into solvency).

Having noted the similarity, I will point out one primary difference around
how we treat the two proverbial "tranches": outsized APY doesn't pay APR
"out-of-pocket"; it's factored into the earnings.
Who gets what APY is a simple function of first-come-best-served
(assume that MEV protection prevents sniping).

We have 3 pools (maybe 4 if you count MKR's mom.sol
because after all, Triforce has 4 triangles, only one of them a different color),
the primary pool (a.k.a. Piscine in 🇫🇷) being carry:
not only in the sense of accrued (carried) interest,
but also in the sense that blood carries oxygen around the body.
Before PCV became a popular term in DeFi, it meant packed 🩸cell volume
wind is what delivers oxygen, and work is derived from harmony between the 3.

There are some constraints on redemptions (see README;
re-purposed a couple of your quotes from this post).

price will be hardcoded to 1

this invariant is common across all stablecoins
(or in QU!D's case, stable futures),
similarly to the liquidation invariant:
(1 as in 100 LTV, or as you say, 99...
originally, this invariant is from Proverbs 11)

I do think 99 makes a lot of sense because soap kills 99% of bacteria.
Soap Capital is a solid meme, but I won't get into that here.

"borrowing an asset against an unconnected asset, such as borrowing DAI against ETH to leverage long on ETH."

Doesn't seem like the right example. DAI's value is directly connected to ETH's value (the same is true for every token
on Ethereum, but DAI makes this relationship very explicit with CDPs). On a separate note,
another example of the so-called carry trade is arb on GMX:
e.g. hold 100k spot (let's say SOL token); take 10k more SOL (on top of the 100)...and finally,
do a 10x short with the 10k. Market exposure is 0 (fully funded never get liquidated no need to rebalance);
funding fee on short is pretty high (it's positive, means you receive it, negative means shorts pay longs)

This will give time for other borrowers to close their positions or for depositors to deposit more to take advantage of the APR, it basically just slows down changes to allow market to react faster. We could also cap max APR to make it less dangerous, or slow it down even further.

This chain reaction seems very predictable, and could probably play itself out without human reaction.
(positions can be netted automatically in bulk).

The following two quotes support each other by implying the same thing

"Coupled with the liquidator of last resort it makes something like the bad debt that arised from CRV impossible."

"Protocol is immune to bad debt, depositors can NEVER lose money" and "less capital will be left unused/idle"

Some basic physics can inform us about "bad debt":
in thermodynamics, bad heat is also known as friction lost to the environment
(as such, it's not usable as work...force times distance...aka...leverage)
The first law of thermodynamics states that work and heat are equivalent, but the second law
points out the obvious (that work is more valuable, it's like useful heat). Similarly, in some situations,
1 unit of DAI is worth more than its corresponding debt unit, like with stable nuclides and radionuclides:
a liquidatable position is radioactively decaying (in a sense), so it's debt units are "bad" because
it places a higher value on their opposite...relative to positions that are not in a "threatening" situation.

@intothemist
Copy link

Feels like the design relies on two important assumptions - that significant slashing will not occur, and that ignoring information contained in the spot market can be net beneficial for the lender.

In practice, ETH staking yield is not a pure monetary policy tool like interest rate earned on central bank deposits. Staking is a reward for performing work that involves risk, however rarely it materialises. When it does eventually materialise on significant scale, classical lending protocols will have the protection of lower LTV and (hopefully) early warning signals from spot markets (i.e. oracles). Without these defense mechanisms, liquidity providers could well lose money.

There will of course be LPs who are happy to deposit into the procol, but they are likely to demand an interest rate premium in return for taking on additional risk. This, in turn, will impact the profitability of the leveraged stETH-ETH position. I would even be tempted to hypothesise that, in an efficient market, profitability of this position would be very close across different lending protocol designs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment