Partial vs. flash chicken-ups

[cvalkan]

Partial vs. flash chicken-ups

Being more profitable than chicken-ins in many cases, chicken-ups will be the dominant strategy for most (long-term) bonders. However, bonders may be subject to capital constraints that make it difficult for them to bring up the extra amount of LQTY needed for the topup. To offer an escape hatch to such bonders, the system could enable partial chicken-ups where the bonder can select the amount to withdraw, reducing the required topup.

Let b be the bond size, P the POL, s the accrued sLQTY and S the total sLQTY supply. In case of a full chicken-up, the bonder has to pay s/S*P - b LQTY. If the bonder only wants to withdraw d < s sLQTY, the topup is proportionally reduced to d/s*(s/S*P - b). After the partial chicken-up, the bond is reduced to (1-d/s)*b, and the accrued sLQTY to s-d. See this sheet for numbers.

After receiving the payout in sLQTY, the bonder could immediately exchange it for LQTY, and use it to withdraw the next portion of the bond, and so on, until the entire bond is chickened up.

Unfortunately, such a series of transactions could be quite gas-inefficient and expensive. It would be nicer if the system would offer a direct route. In theory, this doesn't seem too hard: the system could first flash-mint and exchange the total accrued sLQTY for LQTY using the sLQTY/LQTY AMM, use the proceeds to top up the bond, and pay out the remaining LQTY to the bonder. Depending on the current size of the sLQYT/LQTY AMM and the size of the bond, this could be a more attractive alternative to (small-scale) bonders.

Since the slippage is faced by the bonder (as the transaction would revert if the exchanged LQTY is smaller than the required topup), the protocol as such wouldn't suffer if the transaction gets sandwiched. To mitigate the risks for bonder, the user could specify a maximum slippage tolerance against the current spot or TWAP price.

[bingen]

The use case is interesting, but I’m not sure it’s worth the extra complexity. I think those users could flash mint themselves (for instance using a DSProxy and a DeFiSaver recipe).

[cvalkan]

How could other protocols flash mint sLQTY if they don't have access to sLQTY's mint() function?

Other protocols could offer sLQTY flash loans and we could leave the rebonding to 3rd party tools like DeFiSaver, but I don't see how this could be a full fledged replacement for flash minted sLQTY for the top up as such.

[bingen]

Yes, sorry, I meant flash loan, not flash mint, and I was thinking of LQTY to top up and chicken up. If there’s no LQTY available, they can flash loan any other thing and exchange it.

[bingen]

There’s no chicken-ups anymore.