The absence of a price threshold option for users can result in users obtaining assets at unexpected & undesired prices.
Summary
Buying/Selling of dShares (stock assets) is a 2-step process. (1) Users first submit a buy/sell order and (2) then the Operator executes that order. However, due to potential price fluctuations between these steps, users may experience losses if the price of dShares changes unfavorably.
Vulnerability Detail
Dinari enables the buying and selling of Stock Assets (dShares Tokens). Users can purchase dShares by placing a Market Order, which involves a 2-step process. First, users submit a buy/sell order, and then the Operator fulfills/executes that order. However, if there is a delay in the Operator's execution, users may receive the dShares at an undesired or unexpected price due to price fluctuations.
Delays can occur, that's why requestCancel() order functionality exists.
Primarily It can happen in these two cases:
Very Large Order: When a user places a large order, the Operator executes it in partial steps.
Orders placed outside of the US Trading hours: Outside of US trading hours, Orders are filled in the next trading session.
PoC:
Scenario 1: (In the case of Partial executions of the large orders)
Bob (A very expert trader) recognizes a bull flag trading pattern in the TSLA.D Stock/Token and is expecting a 5% increase in the next few minutes.
Bob places a very large order for the TSLA.D dShares.
The Operator executes Bob's order in multiple partial steps.
Bob was right TSLA.D stock shoots up 5% in just a few minutes (maybe because of the Elon vs Mark fight announcement :))
However, due to the partial execution, Bob receives some dShares after the 5% increase in the TSLA.D price.
Bob now holds tokens at the desired price, but he also acquires tokens at an unwanted and unexpected price, rendering them useless and resulting in additional fees.
Scenario 2: (In the case when a user puts an order outside of the US Trading hours)
User puts an order outside of the US Trading hours for the AAPL.D dShares when it's priced at $190.55.
Protocol executes the order in the next trading session when the AAPL.D is priced at $195.55
The user was expected to grab AAPL.D at $190.55 but he got it at $195.55
Note: Scenario 1 >>>>> Scenario 2.
I believe that in Scenario 2, the responsibility lies more with the user. The protocol already discourages and provides warnings against trading outside of the US Trading hours. However, in Scenario 1, the fault primarily lies with the protocol itself, as it may have limitations or disabilities that can potentially lead to losses for the user.
The protocol should provide users with the ability to establish a risk threshold. This can be achieved through two options:
Allowing users to set minimum and maximum price limits for the fluctuating asset that they are willing to accept.
Enabling users to define a percentage-based risk threshold, such as 1% to 2%.
If the price of the asset goes beyond the user-defined limit or threshold, the Operator should not execute that order, either in full or partially. This would help mitigate unexpected price fluctuations and protect users from potential losses.
DevABDee
medium
The absence of a price threshold option for users can result in users obtaining assets at unexpected & undesired prices.
Summary
Buying/Selling of dShares (stock assets) is a 2-step process. (1) Users first submit a buy/sell order and (2) then the Operator executes that order. However, due to potential price fluctuations between these steps, users may experience losses if the price of dShares changes unfavorably.
Vulnerability Detail
Dinari enables the buying and selling of Stock Assets (dShares Tokens). Users can purchase dShares by placing a Market Order, which involves a 2-step process. First, users submit a buy/sell order, and then the Operator fulfills/executes that order. However, if there is a delay in the Operator's execution, users may receive the dShares at an undesired or unexpected price due to price fluctuations.
Delays can occur, that's why
requestCancel()
order functionality exists. Primarily It can happen in these two cases:PoC:
Scenario 1: (In the case of Partial executions of the large orders)
TSLA.D
Stock/Token and is expecting a 5% increase in the next few minutes.TSLA.D
dShares.Scenario 2: (In the case when a user puts an order outside of the US Trading hours)
Note: Scenario 1 >>>>> Scenario 2. I believe that in Scenario 2, the responsibility lies more with the user. The protocol already discourages and provides warnings against trading outside of the US Trading hours. However, in Scenario 1, the fault primarily lies with the protocol itself, as it may have limitations or disabilities that can potentially lead to losses for the user.
Impact
Code Snippet
https://github.com/sherlock-audit/2023-06-dinari/blob/4851cb7ebc86a7bc26b8d0d399a7dd7f9520f393/sbt-contracts/src/issuer/OrderProcessor.sol#L244 https://github.com/sherlock-audit/2023-06-dinari/blob/4851cb7ebc86a7bc26b8d0d399a7dd7f9520f393/sbt-contracts/src/issuer/OrderProcessor.sol#L272
Tool used
Shaheen's Vision
Recommendation
The protocol should provide users with the ability to establish a risk threshold. This can be achieved through two options:
If the price of the asset goes beyond the user-defined limit or threshold, the Operator should not execute that order, either in full or partially. This would help mitigate unexpected price fluctuations and protect users from potential losses.