When filling an order, the fillAmount (asset or payment token) and receivedAmount (shares) are calculated off-chain.
While full fillAmount is the same as the orderAmount, receivedAmount can differ.
There are some checks in place for fillAmount but not for receivedAmount.
It's the same as inputting a minReceived/ expectedReceive value when swapping assets as uniswap
When submitting an order, the user specifies the orderAmount (of paymentToken) and the price.
It is then up to the off-chain component to determine what the amountReceived will be.
The problem is, due to the fact that the user can't specify a min expected amount to receive, the user is subjected to what the off-chain component calculates.
This could result to the user receiving less than expected.
Impact
When an order is filled, the user could receive less than expected.
Code Snippet
provided
Tool used
Manual Review
Recommendation
implement a minReceived value that is checked when the order is being filled.
Delvir0
medium
Order fill process does not check minReceived
Summary
When filling an order, the fillAmount (asset or payment token) and receivedAmount (shares) are calculated off-chain. While full fillAmount is the same as the orderAmount, receivedAmount can differ. There are some checks in place for fillAmount but not for receivedAmount. It's the same as inputting a minReceived/ expectedReceive value when swapping assets as uniswap
Vulnerability Detail
https://github.com/sherlock-audit/2023-06-dinari/blob/main/sbt-contracts/src/issuer/OrderProcessor.sol#L272
Fill amount is checked for the following: https://github.com/sherlock-audit/2023-06-dinari/blob/main/sbt-contracts/src/issuer/OrderProcessor.sol#L278 https://github.com/sherlock-audit/2023-06-dinari/blob/main/sbt-contracts/src/issuer/OrderProcessor.sol#L284 An additional check is that full fillAmount eventually equals the orderAmount, otherwise the user is able to cancel the order and receive the remaining amount.
When submitting an order, the user specifies the orderAmount (of paymentToken) and the price. It is then up to the off-chain component to determine what the amountReceived will be. The problem is, due to the fact that the user can't specify a min expected amount to receive, the user is subjected to what the off-chain component calculates. This could result to the user receiving less than expected.
Impact
When an order is filled, the user could receive less than expected.
Code Snippet
provided
Tool used
Manual Review
Recommendation
implement a minReceived value that is checked when the order is being filled.