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.

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.

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$$

the weETHExchangeRate converts `weETH` value to the `wstETH` value.