-
Notifications
You must be signed in to change notification settings - Fork 5
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
Conversation
… margin, debug logs still present
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. | ||
|
There was a problem hiding this comment.
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:
- if
newDebtAsset
is a collateral & supply cap margin allows supplying, it's the most reasonableextraCollateralAsset
as even with 1 wei imprecision the swap will likely succeed - 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:
....
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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?
*/ | ||
function _getReserveData(address asset) internal view virtual returns (address, address); | ||
function _getReserveData(address asset) internal view virtual returns (address, address, address); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
|
||
// Execute the nested flashloan | ||
address newAsset = flashParams.nestedFlashloanDebtAsset; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newDebtAsset
?
There was a problem hiding this comment.
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
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!