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

fix: facade functions revert on no-ops #272

Merged
merged 1 commit into from
Sep 1, 2024

Conversation

@StErMi
Copy link

StErMi commented Aug 28, 2024

@lekhovitsky the partiallyLiquidateCreditAccount function executes the _addCollateral and _withdrawCollateral functions that do not perform the check that would revert if amount == 0.

Is this behavior intended? This is the only case in the whole CreditFacadeV3 that skips those checks.

Other than that, the code seems good and implements the recommendations from the findings.

@lekhovitsky
Copy link
Collaborator Author

@StErMi If amount passed to partiallyLiquidateCreditAccount is 0, the code would revert inside _manageDebt. This looks safer compared to reverting inside _withdrawCollateral if feeAmount rounds down to 0 for some reason.

if (amount <= 1) return;
unchecked {
--amount;
if (amount >= 1) {

Choose a reason for hiding this comment

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

Wouldn't that cause a revert if the balance of the credit account is 1? What about previous gas optimisations used here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I guess the point is to avoid no-op withdrawals when the balance is <= 1 (one can still specify exactly amount == 1 if this 1 wei is of any value).

Copy link

Choose a reason for hiding this comment

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

That's the main reason why I do not like to have custom logics like this one.

As @lekhovitsky said, people can just specify the exact number of tokens to withdraw to avoid this revert, and definitely it's an edge case (given that you have to have just 1 wei in the balance of your CA for this token) but still...

@lekhovitsky with gas as low as 0.805 gwei like we have right now, is it really worth having this custom behavior?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@StErMi Still don't see a single an issue with it, tbh

@@ -707,6 +700,7 @@ contract CreditFacadeV3 is ICreditFacadeV3, ACLNonReentrantTrait {
uint256 forbiddenTokensMask
) internal returns (uint256, uint256) {
(address token, int96 quotaChange, uint96 minQuota) = abi.decode(callData, (address, int96, uint96)); // U:[FA-34]
if (quotaChange == 0) revert AmountCantBeZeroException(); // U:[FA-34]
Copy link
Collaborator Author

@lekhovitsky lekhovitsky Aug 30, 2024

Choose a reason for hiding this comment

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

@StErMi probably for completeness this line should go after quotaChange is rounded; something like

quotaChange = quotaChange != type(int96).min
     ? quotaChange / int96(uint96(PERCENTAGE_FACTOR)) * int96(uint96(PERCENTAGE_FACTOR))
     : quotaChange;
if (quotaChange == 0) revert AmountCantBeZeroException(); // U:[FA-34]

Copy link

Choose a reason for hiding this comment

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

Yes, I think it makes sense

Base automatically changed from spearbit-53-54 to spearbit-fixes September 1, 2024 10:28
@lekhovitsky lekhovitsky merged commit ef9267a into spearbit-fixes Sep 1, 2024
3 checks passed
@lekhovitsky lekhovitsky deleted the spearbit-96-106 branch September 1, 2024 10:31
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