A rounding error when computing settleAmounts could lead to a small amount of PnL will be lost each time. Since this is a trading protocol, it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.
Root Cause
Rounding error when computing settleAmounts
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
The settleAmounts is computed based on the following formula:
$\frac{(updatedPrice - openedPrice) quantity}{1e18}$ OR $\frac{(openedPrice - updatedPrice) quantity}{1e18}$
The issue is that in an edge case where the difference between updatedPrice and openedPrice is small, coupled with small quantity (LibQuote.quoteOpenAmount(quote)), the numerator of the equation will be larger than the denominator, leading to settleAmounts being rounded down to zero.
In this case, no PnL is settled to PartyA or PartyB's allocated balance (because settleAmounts is zero) , yet the quote's openedPrice is being updated to the updatedPrice at Line 77 below. When openedPrice is set to updatedPrice, this effectively means that the PnL has settled successfully and users have received the settled PnL to which they are entitled. However, that is not the case here due to rounding error.
A small amount of PnL will be lost each time the rounding error occurs. Since this is a trading protocol, and it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.
Lost of assets. A small amount of PnL will be lost each time the rounding error occurs. Since this is a trading protocol, it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.
PoC
No response
Mitigation
Consider reverting the function and skip updating the quote.openedPrice if the settleAmount ends up being zero. If settleAmount is zero, there is also no point proceeding with the rest of the settleUpnl execution since there is nothing to settle anyway (The allocated balance of either PartyA or PartyB will not increase at the end).
xiaoming90
High
Rounding error when computing
settleAmountsSummary
A rounding error when computing
settleAmountscould lead to a small amount of PnL will be lost each time. Since this is a trading protocol, it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.Root Cause
settleAmountsInternal pre-conditions
No response
External pre-conditions
No response
Attack Path
The
settleAmountsis computed based on the following formula:$\frac{(updatedPrice - openedPrice) quantity}{1e18}$ OR $\frac{(openedPrice - updatedPrice) quantity}{1e18}$
The issue is that in an edge case where the difference between
updatedPriceandopenedPriceis small, coupled with small quantity (LibQuote.quoteOpenAmount(quote)), the numerator of the equation will be larger than the denominator, leading tosettleAmountsbeing rounded down to zero.In this case, no PnL is settled to PartyA or PartyB's allocated balance (because
settleAmountsis zero) , yet the quote'sopenedPriceis being updated to theupdatedPriceat Line 77 below. WhenopenedPriceis set toupdatedPrice, this effectively means that the PnL has settled successfully and users have received the settled PnL to which they are entitled. However, that is not the case here due to rounding error.A small amount of PnL will be lost each time the rounding error occurs. Since this is a trading protocol, and it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.
https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/libraries/LibSettlement.sol#L69
Impact
Lost of assets. A small amount of PnL will be lost each time the rounding error occurs. Since this is a trading protocol, it is expected that there will be users who are active traders or entities that perform high-frequency or algorithmic trading, resulting in the loss accumulating to a significant amount.
PoC
No response
Mitigation
Consider reverting the function and skip updating the
quote.openedPriceif thesettleAmountends up being zero. IfsettleAmountis zero, there is also no point proceeding with the rest of thesettleUpnlexecution since there is nothing to settle anyway (The allocated balance of either PartyA or PartyB will not increase at the end).