Stable Credit: Understanding automated positive sum liquidations

First, lets look at the current liquidation landscape. There are two core things;

• Collateral
• Debt

Most simplistically put, when debt > collateral a liquidation occurs. So to keep things simple, lets use 100% values.

If you provide 1 ETH as collateral (and for the sake of this article, lets assume 1 ETH = 1000 USD), you can borrow 1000 USD.

If the value of 1 ETH falls to 900 USD, you are a liquidation candidate since debt > collateral

The mechanism of liquidation can vary significantly from system to system.

In a margin based system (or any system where the system owns the borrowed (debt) asset). it can simply close your position. Return the 1000 USD and take your 1 ETH. In systems where the debt is outside of the system, liquidators needs to be incentivized to repay on your behalf. In these cases, a liquidator would repay your 1000 USD debt and claim your 1 ETH.

As can be noted from the above, it doesn’t make economical sense for a liquidator to repay 1000 USD debt for 900 USD worth of ETH. For this reason, most systems use higher collateralization values. Often you will see systems have 150% collateral value. What this means, is that your 1 ETH is viewed as 6.667 ETH for purposes of calculating its USD value. But as 1 ETH for purposes of liquidation. So you can borrow 667 USD worth of debt for 1 ETH.

I never liked liquidations.

Primarily, because they are annoying to code. You have to create individual positions per user and each position needs to be iterated through and calculated. When it comes to smart contract development, I’m probably an on-chain purist. I hate when I have to do things off-chain. So building an on-chain solution that is reliant on off-chain systems, just annoys me. (mostly because my devops is atrocious). So I’ve been obsessed for the last year with how to get around position based liquidations.

My first attempted design was a debt based system similar to how yearn tokens work. Yearn tokens are agnostic from any specific users position, and it manages funds as a group instead of as an individual. You can do the same with debt if you give everyone the same fixed collateral ratio. This design however was fairly off-putting from a UX perspective, since all users were penalized a proportional share of the liquidation. While this worked on a programmatic level, it was a bad design for good user flow.

My next attempt was using liquidity shares from an AMM instead. If you look at a pair such as DAI-WETH, and you assume healthy markets, then DAI-WETH keeps its DAI value. If you start with 1000 DAI and 1 WETH, you have a pair valued at 2000 DAI (since 1 WETH = 1000 DAI). If WETH doubles in value, your pair is valued at ~3000 DAI, since you would have > 1000 DAI and < 1 WETH (~2000 DAI and 0.5 WETH). So trading with stable coin pairs, keeps the stable coin value at least. (oversimplified, since this ignores fees and impermanent loss)

When the user withdraws, they have 2000 DAI and 0.5 WETH, they could sell the 1000 DAI for another 0.5 WETH, and have 1 WETH. But if they had not been an LP, they would have had 2 WETH (valued at 4000 DAI).

The above design in practice worked, but for users wanting to use WETH as collateral, not so much. If you provide 1 WETH as collateral, you expect the following conditions;

1. If WETH value decreases and I get liquidated, I would have < 1 WETH
2. If WETH value increases, I would have 1 WETH

So the AMM pair design worked to avoid liquidations, but it meant collateral providers could never enjoy the upside of their asset.

The above design however does allow for automated liquidations.

Another constant obsession of mine, was impermanent loss (IL) hedging. With the research we did with yswap, we saw that we could offset (not mitigate) the IL by not linking pairs directly, but instead using a minted representation as a transfer token.

So using the above example again, the user had to provide 1000 DAI and 1 WETH to start with. Now what if instead, they started with 2 WETH, and the 2000 DAI was minted for them, and provided to the pair. WETH doubles in value again, as per above, when they withdraw they have, 1 WETH and 4000 DAI. The 2000 DAI debt is settled (4000–2000), and the remaining 2000 DAI is converted to WETH. The users net end result is 2 WETH. Same as when they started. (+ trading fees)

Now lets look at the inverse. WETH value halves. We have 1000 DAI and 4 WETH. You withdraw, 2000 DAI debt is settled with 1000 DAI, 2 WETH is sold for 1000 DAI and the remaining 1000 DAI debt is settled, and you receive 2 DAI. (+ trading fees)

This design allows for automated positive sum liquidations instead of manual position based subtractive liquidations.