# Seaport Leverage and Deleverage

## Overview

***

### Context

This contract outlines a leverage and deleverage strategy with the following assumptions:

1. The "base asset" can be sold for the "collateral asset" on Seaport.
2. The "collateral asset" can be sold for the "base asset" on Seaport.

## **Why Seaport?**

***

* As LRTs are having a hard time bootstrapping resilient liquidity on AMMs—especially on Uniswap—we are incorporating a RFQ system that connects the user looking to sell the collateral in a deleverage scenario to a marketmaker willing to buy the collateral at a discount.
* Because RFQ’s are traditionally non-atomic, they are not compatible with a delverage strategy that relies on atomic flashloans.
* To make these RFQ’s “atomic”, we incorporate Seaport where a market maker first quotes the price offchain and signs an approval to transfer its payment asset to the deleverage contract.
* This allows the user and the market maker to agree on an exchange of assets at a specific price prior to sending a transaction. The “swap” is executed atomically when the deleverage contract is called.called.
* The goal is to facilitate an atomic sale of collateral during a liquidation or a deleverage to an RFQ system that is willing to buy the collateral. We expect this path to be more resilient than the shallow liquidity on on-chain AMMs.

{% hint style="info" %}
NOTE: Most of the complexity in the RFQ will be the responsibility of the frontend offchain system to match the users to a counterparty. The new on-chain integration that is being built out is the ability to fulfill an offer on seaport.
{% endhint %}

## Transaction Flow

***

The key idea here is incorporating an ‘atomic’ RFQ-swap through Seaport. The following is the flow for the user looking to deleverage:

1. The user requests an amount of `weETH` to sell to the RFQ. \[offchain, websocket connection—no contract interaction has been made yet]
2. The market maker quotes the amount of `wstETH` they are willing to pay for the given amount of `weETH`. \[offchain, websocket connection]
3. The market maker generates a signature and approves the wstETH amount via Seaport. The market maker creates an `offer` on seaport. \[the `offer` is created on-chain on seaport].
4. Next, the signature is sent from the market maker to the user \[offchain, sent to the user interacting on the frontend]
5. The user on the frontend now calls the deleverage contract and passes this signature along in calldata.
6. The deleverage contract will now payoff Ion loan, withdraw `weETH`, then *sell this `weETH` on seaport using the outstanding `offer`.*
7. The deleverage contract will fulfill the `offer` on seaport, transferring the `wstETH` from the market maker’s EOA and transferring the user’s `weETH` to the market maker.

It should also be noted that if the pricing is too unfavorable for the user, the deleverage may fail as it violates the max LTV requirement.

* For example, the user and the RFQ counterparty agree on the amount of `weETH` and `wstETH` to exchange.
* The deleverage sources the exact `wstETH` amount to pay off debt, but if after paying off this debt, the resulting LTV is above the maxLTV, then the contract will revert.
* The frontend will be responsible for making sure that the pricing is reasonable for the transaction to succeed before initiating any on-chain actions.
* The transaction should revert when:

$$
\frac{wstETHDebt\_{initial}-wstETH\_{amtReceived}}{(weETHAmt\_{initial}-weETH\_{amtSold})\*weETHExchangeRate} > maxLTV
$$

{% hint style="info" %}
the weETHExchangeRate converts \`weETH\` value to the \`wstETH\` value.
{% endhint %}