functions lack slippage protection

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0xdca2cb75cae14bac4ac7744b79281929eef1c25c2faec691bc6cff97e630efdf Severity: medium

Description: Description\ Like any other share-based system, Intuition has varying share values, which can increase and decrease depending on user and vault actions. For example, deposits and withdrawals can charge small amounts of fees, increasing the value of shares.

However, slippage is not taken into account when users make deposits or withdrawals, whether with depositTriple, redeemTriple, depositAtom, or redeemAtom. This oversight can worsen the user experience and cause them to lose small amounts of funds.

Attack Scenario

1. Alice sends a deposit transaction when the share price is 100 USD, but she is not willing to pay more than 101 USD per share.
2. Due to heavy mempool activity, Alice's transaction is executed one day later.
3. When the deposit is finally executed, the current share price is 105 USD.

Notice that the user doesn't have an option to set a maximum share price or a deadline for the transaction. The time and price difference in this example are small, but without such mechanisms, users can lose significant portions of their balances.

Recommendation

Implement slippage and deadline checks for deposits and withdrawals.

[mihailo-maksa]

The reported issue is invalid. The protocol’s current design ensures that users cannot lose funds through the scenarios described. The existence of entryFee, exitFee, and protocolFee discourages any frontrunning attempts due to the associated costs. Additionally, the logic within the protocol ensures that users cannot be adversely affected by delayed transactions or changing share prices.

In our case, sandwich attacks would actually benefit the user, as the attacker would need to pay higher prices, resulting in the user gaining more from the transaction. The protocol's fee mechanisms inherently protect against the negative impact of slippage, making additional slippage protection redundant.

Therefore, the current implementation works as intended, and there is no need for further slippage checks or deadline mechanisms.

[0x3b33]

Thanks for the heads up, however I think this issue stands some ground.It's based on the fact that share price changes and some people will not want to buy it at a certain price (i.e. if they thing that share price above X is overvalued).

With the example scenario I gave a normal interaction between a user and the system where our user (Alice) submits a TX at share price X, but buys them at share price Y.

The existence of entryFee, exitFee, and protocolFee discourages any frontrunning attempts due to the associated costs.

In our case, sandwich attacks would actually benefit the user, as the attacker would need to pay higher prices, resulting in the user gaining more from the transaction.

As stated in the report (or more precisely the lack of stating) there doesn't need to be a front-running or a sandwiching scenario in order for this to be a problem.