-
Notifications
You must be signed in to change notification settings - Fork 1
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
Implement UndercollateralizedPosition error #79
Conversation
2. preLCF1 <= preLCF2; | ||
3. WAD <= preLIF1 <= preLIF2. | ||
|
||
Note that `preLCF1 <= WAD` and `preLCF1 <= WAD` is not mandatory. |
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.
Note that `preLCF1 <= WAD` and `preLCF1 <= WAD` is not mandatory. | |
Note that `preLCF1 <= WAD` and `preLCF2 <= WAD` is not mandatory. |
The PreLiquidation smart-contract enforces: | ||
1. preLltv < LLTV; | ||
2. preLCF1 <= preLCF2; | ||
3. WAD <= preLIF1 <= preLIF2. |
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.
Note that this will create a silent merge conflict with #77
3. WAD <= preLIF1 <= preLIF2. | ||
|
||
Note that `preLCF1 <= WAD` and `preLCF1 <= WAD` is not mandatory. | ||
Indeed without this, the close factor can reach 100% when the position LTV is less than LLTV allowing additionnal pre-liquidation close factor configurations. |
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.
Not sure that this sentence is really understandable as it is
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.
Agreed, what do you mean in this very context by "allowing additional pre-liquidation close factor configuration"? Do you want to say close factors that make no sense? that are not covered by this contract? that are not safe?
oraclePrice = bound(oraclePrice, 1, ORACLE_PRICE_SCALE / 2); | ||
OracleMock(preLiquidationParams.preLiquidationOracle).setPrice(oraclePrice); | ||
|
||
uint256 collateralPrice = IOracle(preLiquidationParams.preLiquidationOracle).price(); |
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.
oraclePrice = bound(oraclePrice, 1, ORACLE_PRICE_SCALE / 2); | |
OracleMock(preLiquidationParams.preLiquidationOracle).setPrice(oraclePrice); | |
uint256 collateralPrice = IOracle(preLiquidationParams.preLiquidationOracle).price(); | |
uint256 collateralPrice = bound(oraclePrice, 1, ORACLE_PRICE_SCALE / 2); | |
oracle.setPrice(collateralPrice); |
@@ -139,6 +139,9 @@ contract PreLiquidation is IPreLiquidation, IMorphoRepayCallback { | |||
|
|||
uint256 collateralPrice = IOracle(PRE_LIQUIDATION_ORACLE).price(); | |||
uint256 collateralQuoted = uint256(position.collateral).mulDivDown(collateralPrice, ORACLE_PRICE_SCALE); | |||
|
|||
require(collateralQuoted > 0, ErrorsLib.UncollateralizedPosition()); |
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.
Remark that this corresponds to ltv = +infinity and that #77 already prevents ltv > LLTV.
I think that it's possible to do the check of #77 in a way that also prevents the division by zero that this PR prevents: check that borrowed <= LLTV.wMulDown(collateralQuoted).
This is because borrowed is rounded up so it is >= 1
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 really like your solution, wdyt @colin-morpho does it help for FV ?
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.
See de168dd. So now there shouldn't be any division by zero
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 Quentin's suggestions is the right way to go!
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.
Agree too, closing it then
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.
Few comments to imporve the README, perhaps we should consider @QGarchery's porposition.
|
||
### Pre-liquidation parameters restrictions | ||
|
||
The PreLiquidation smart-contract enforces: |
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.
The PreLiquidation smart-contract enforces: | |
The PreLiquidation smart-contract enforces the following properties. |
2. preLCF1 <= preLCF2; | ||
3. WAD <= preLIF1 <= preLIF2. | ||
|
||
Note that `preLCF1 <= WAD` and `preLCF1 <= WAD` is not mandatory. |
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.
Note that `preLCF1 <= WAD` and `preLCF1 <= WAD` is not mandatory. | |
Note: it is not mandatory that `preLCF1 <= WAD` and `preLCF1 <= WAD` hold. |
Replaced by #77 |
Reopened for the changes on the readme, but we should remove the new require |
I'll just create another PR for the readme |
Should we close this PR then? |
replaced by #82 |
collateralQuoted = 0
to simplify FV (cfpreLiquidate
may revert unexpectedly #49)preLCF > WAD
in readme (cf PRE_CF_2 > WAD #52)