Redemptions and DEX liquidity

[cvalkan]

Redemptions and DEX liquidity

Problem

In a simple version of ChickenBonds that only holds and stakes "naked" LQTY, the following two invariants hold automatically:

Invariant 1 (Backing ratio can only increase)
The POL_ratio (aka backing ratio) defined as POL/sLQTY_supply can only ever increase, but never decrease.

Invariant 2 (sLQTY is 100% backed)
The system always holds enough LQTY as POL to serve all redemption requests. Bank runs are impossible.

The situation changes if we want the system to hold a portion of its POL in DEXes rather than as staked LQTY. In the following, we analyze the available options and their pros and cons.

We distinguish between two different DEX pairs:

• sLQTY/LQTY (aka Chicken AMM)
• LQTY/ETH (aka Token AMM)

The two pairs come with their own challenges. While sLQTY/LQTY starts completely empty (facilitating price manipulation attacks against LPing), the protocol can use LQTY from its POL and pair it with freshly minted sLQTY. In contrast, to build up LQTY/ETH liquidity, the protocol first needs to sell LQTY (or potentially sLQTY) for ETH, which seems more prone to sandwich attacks. On the other hand, we could incentivize 3rd LQTY/ETH liquiditity at the beginning to mitigate the risks that come with thin liquidity.

One simple solution for building LQTY/ETH liquidity would be to deploy two separate systems: one that issues sLQTY against naked LQTY (and that doesn't invest in AMMs), and a second one that takes LQTY/ETH AMM LP tokens from bonders and issues LQTY/ETH sLP tokens. While this solves the problem of the Token AMM, each system may still need its own Chicken AMM. Furthermore, it's unclear how popular LP token bonding would be general, and especially if people can bond LQTY tokens at the same time. This approach is not considered further here.

Instead we analyze the options according to the following criteria:

• Is DEX liquidity (needed for) backing the sLQTY supply?
• If yes, is it included or excluded from redemptions?
• Is the sLQTY fully backed or only partially backed?
• Is the DEX liquidity (permanently) owned by the protocol or just rented?

Approaches

DEX vs. backing

	DEX included in redemption	DEX excluded from redemption
Full backing	(1) Entire sLQTY supply is redeemable against a combined pro rata share of both LQTY POL (staked LQTY) and AMM LP tokens.	(2) Entire sLQTY supply is redeemable against the LQTY POL. AMM returns can be retained or reinvested to the LQTY POL.
Prioritized (full) backing	(3) Entire sLQTY is redeemable. Redemption is first done against the LQTY POL. If used up, redemption happens against the AMM LP tokens.	n/a
Fractional reserve	n/a	(4) Redemption is exclusively done against the LQTY POL, but only a fraction of the sLQTY is redeemable. AMM returns can be retained or reinvested to the LQTY POL.

(1) Entire sLQTY supply redeemable against a pro rata share of LQTY POL and AMM

Holders can redeem sLQTY and receive pro rata shares of both LQTY POL (which gets unstaked) and AMM LP tokens representing a fraction of the sLQTY/LQTY and/or LQTY/ETH pool.

Pros: no bank run possible since the sLQTY is 100% backed

Cons: The redemption value of sLQTY doesn’t only reflect the value of LQTY, but it also depends on the value held in the DEX pools which will vary over time (subject to impermanent loss). If the redemption value is still expressed in LQTY, it could thus decrease from natural price fluctations, breaching invariant 1.

(2) sLQTY is fully backed and exclusively redeemable against the LQTY POL

Holders can redeem sLQTY and are guaranteed to receive a pro rata share of the LQTY POL. The AMMs are separated from the core backing and not subject to redemption. They are thus not counted towards the system's POL and are irrelevant for the POL_ratio and for determining the payout cap for chicken-ins. However, the system may reinvest their returns to the LQTY POL instead of retaining them in the AMM.

To build up the DEX liquidity, the protocol cannot use its POL, but needs to take the funds from somewhere else. One approach is to divert a fraction of the bonders' payout upon chicken in/up events (e.g. 10% of the sLQTY), selling half of it to obtain the other token for the AMM. But we could also exclude a fraction of the bonded LQTY from accruing sLQTY in the first place and use it to directly feed the Chicken AMM. By combining the two methods, the protocol could provide both sides of the sLQTY/LQTY AMM.

As an alternative to acquiring permanent liquidity, the protocol could also charge a smaller fee on the accrued sLQTY (e.g. 1%) and pay it out as an incentive to third-party LPs, thus renting liquidity. This could be a particularly interesting option for the sLQTY/LQTY pool as it completely offloads the issue of price finding and manipulation to third parties.

Pros: maintains invariants 1 and 2. DEX liquidity is permanently owned by the protocol. If the AMM returns are reinvested to the LQTY POL, sLQTY should also benefit from a (permanent) price premium even if the bond market completely dries up (we could call this the "DEX premium" to differentiate it from the "bond premium" caused by outstanding bonds).

Cons: reduces the bonding APR and increases the time to break even.

(3) Redemption is done in an order of priority: first against the LQTY POL, then against the AMM

Holders can redeem sLQTY and receive LQTY as long the POL contains (staked) LQTY. When used up, the redeemer receives a pro rata share of the AMM LP tokens instead.

Pros: sLQTY will reflect the value of LQTY as long as the LQTY POL is non-empty

Cons: the sLQTY price may suddenly change once the LQTY is used up, breaching invariant 1 and potentially even triggering pseudo bank runs (though technically maintaining invariant 2 since the entire sLQTY supply is redeemable).

(4) sLQTY is partially backed and exclusively redeemable against the LQTY POL

Holders can redeem sLQTY solely against the LQTY POL, but only a predetermined fraction of the sLQTY supply is redeemable. The AMMs are separated from the core backing and not subject to redemption. However, the system may reinvest their returns to the LQTY POL instead of retaining them in the AMM.

Pros: DEX liquidity is permanently owned by the protocol. sLQTY will reflect the value of LQTY as long as the LQTY POL is non-empty. No need to divert an extra amount from the bonders as in approach (2). If the AMM returns are reinvested to the LQTY POL, sLQTY should benefit from a price premium even if the bond market completely dries up.

Cons: both invariants 1 and 2 break down in case of a bank run that fully depletes the LQTY POL.

[bingen]

Macro economic model comparison for the different approaches

(1) Entire sLQTY supply redeemable against a pro rata share of LQTY POL and AMM

On each chicken in/up event (and assuming sTOKEN price > 1), 20% of the foregone TOKENs will be diverted to the AMM. The system will pair the necessary amount of sTOKEN to pair them.

(2) sLQTY is fully backed and exclusively redeemable against the LQTY POL

On each chicken in/up event (and assuming sTOKEN price > 1), 20% of the foregone TOKENs will be diverted to the AMM. The necessary amount of sTOKEN to pair them will be diverted from sTOKEN accrued by the bonder (to avoid breaking invariant 1).

As a consequence, bonds take longer to make profits, which we can see in the charts (chicks start to chicken in later).

The main advantage seems to be that premium of fair price over redemption price is higher in proportion.

(3) Redemption is done in an order of priority: first against the LQTY POL, then against the AMM

Like in approach (1), on each chicken in/up event (and assuming sTOKEN price > 1), 20% of the foregone TOKENs will be diverted to the AMM. The system will pair the necessary amount of sTOKEN to pair them.

This one seems to be the worse. Having a lower proportion of yield generating LQTY and a higher proportion of AMM funds which are subject to impermanent loss (influenced by the price of sLQTY), seems to be worse for the system.

But with this scenario, as redemptions barely kick in, there’s little difference in practice with approach (1).