Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: Allow Debt Swaps When LT > Current_LTV > LTV #17

Merged
merged 17 commits into from
Aug 9, 2023

Conversation

Zer0dot
Copy link
Contributor

@Zer0dot Zer0dot commented Jul 28, 2023

Addresses #13 by wrapping a collateral flashloan around the debt swap flashloan.

Note that there is a caveat where it is possible that there is a rounding error in the collateral withdrawn of ~1wei. This could lead to issues when repaying the flashloan, so it's recommended to fund the adapter with a trivial amount of the currency expected to be used for extra collateral. Open to other more elegant ways to solve this!

7. Use the remaining new debt asset (`9.9 USDC`) to repay parts of the newly created **target debt**

Notice how steps 3, 4, 5, and 7 are the same four steps from the collateral-less flow.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably would make sense to add some guidance here for integrators.

For selecting an extraCollateralAsset and extraCollateralAmount one strategy could be:

  1. if newDebtAsset is a collateral & supply cap margin allows supplying, it's the most reasonable extraCollateralAsset as even with 1 wei imprecision the swap will likely succeed
  2. else use any collateral that has a high ltv and enough cap margin to supply

The formula to calculate the minimum extraCollateralAmount is as follows:
$$c = a * b$$

....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would the swap have more odds of success if newDebtAsset == extraCollateralAsset?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because the internal flashborrow will probably create slight leftovers which can be used to pay the extra wei in case there is any needed, no?

@sakulstra sakulstra merged commit e5ca740 into main Aug 9, 2023
1 check passed
@Zer0dot Zer0dot deleted the feat/over-ltv-debt-swap branch August 9, 2023 21:50
*/
function _getReserveData(address asset) internal view virtual returns (address, address);
function _getReserveData(address asset) internal view virtual returns (address, address, address);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would better use struct tbh

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does look better with a struct but since we only use it internally and it's already correct, maybe would be increased gas for not much security/readability gain?

src/contracts/ParaSwapDebtSwapAdapter.sol Show resolved Hide resolved
src/contracts/ParaSwapDebtSwapAdapter.sol Show resolved Hide resolved
src/contracts/ParaSwapDebtSwapAdapter.sol Show resolved Hide resolved

// Execute the nested flashloan
address newAsset = flashParams.nestedFlashloanDebtAsset;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

newDebtAsset?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't be because in this scenario it's not the debt asset but the collateral, it's just the asset we flash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants