The borrowingCollateral is the margin deposit which is included in the borrowedAmount, therefore, it is only lost when the price moves in an unfavourable direction. In other cases, upon closing, after liquidity is restored, the remaining balance of borrowedAmount (including borrowed collateral) is returned to the trader (borrower).

Escalate

As the code suggests, both borrowedAmount and borrowingCollateral are included into holdTokenBalance (as per #86). borrowedAmount is calculated as a single-sided position and holdTokenBalance is the borrowedAmount + swapped saleTokens. If the position is in the current tick range, only those holdTokens would be a part of borrowedAmount which were extracted from the position BEFORE swap was made, and those holdTokens that were received through swapping would not be accredited to anything in the system and they would be lost.

At first I thought that borrowingCollateral was this missing part of holdTokens that were swapped and which were not attributed to the borrowedAmount. I understand now that the borrowingCollateral is the margin deposit and that it should have been included in the borrowedAmount as per design. Hovewer, as per case explained above, the holdTokens that were swapped should be added to borrowedAmount still. Otherwise, the restoredLiquidity would be lower than the liquidity.loan, the repayment would revert and tokens would be stuck in the vault.

Escalate

As the code suggests, both borrowedAmount and borrowingCollateral are included into holdTokenBalance (as per #86). borrowedAmount is calculated as a single-sided position and holdTokenBalance is the borrowedAmount + swapped saleTokens. If the position is in the current tick range, only those holdTokens would be a part of borrowedAmount which were extracted from the position BEFORE swap was made, and those holdTokens that were received through swapping would not be accredited to anything in the system and they would be lost.

At first I thought that borrowingCollateral was this missing part of holdTokens that were swapped and which were not attributed to the borrowedAmount. I understand now that the borrowingCollateral is the margin deposit and that it should have been included in the borrowedAmount as per design. Hovewer, as per case explained above, the holdTokens that were swapped should be added to borrowedAmount still. Otherwise, the restoredLiquidity would be lower than the liquidity.loan, the repayment would revert and tokens would be stuck in the vault.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

@cvetanovv @fann95 what do you think?

and holdTokenBalance is the borrowedAmount + swapped saleTokens.

This is incorrect. holdTokenBalance - these are the tokens received during liquidity extraction (including the result of the swap).
borrowedAmount = holdTokenBalance+marginDeposit
borrowedAmount is the maximum amount calculated on the border of the position range(single mode).

Hi @fann95
Yes, excuse me for this confusion. My main point is that nowhere in the code this part of holdTokenBalance that was received as the result of the swap is added to borrowedAmount, which makes the borrowedAmount less than intended.

It should not be added, it is part of borrowedAmount. That is, this is what you actually received. borrowedAmount.will be more than holdTokenBalance or equal if the position is outside the current tick and swap will not occur

If the position is outside, that is correct. But if the position is inside the current tick range, which would be in 90% of the cases, and the swap will occur, these swapped tokens are just sent to the Vault, where they would be stuck and lost as they are not represented anywhere in the system, which is a loss of liquidity for LPs.

If the position is outside, that is correct. But if the position is inside the current tick range, which would be in 90% of the cases, and the swap will occur, these swapped tokens are just sent to the Vault, where they would be stuck and lost as they are not represented anywhere in the system, which is a loss of liquidity for LPs.

No, these exchanged tokens are part of the borrowedAmount . Because if the position is inside a tick, the result of extracted+swaped tokens will be less than the borrowedAmount. extracted+swaped+marginDeposit=borrowedAmount (which is stored)

borrowedAmount is calculated single-sidedly (only as amount0 or amount1, depending on the zeroForSaleToken flag):

                // Calculate borrowed amount
                borrowedAmount += _getSingleSideRoundUpBorrowedAmount(
                    zeroForSaleToken,
                    tickLower,
                    tickUpper,
                    liquidity

        borrowedAmount = (
            zeroForSaleToken
                ? LiquidityAmounts.getAmount1ForLiquidity(
                    TickMath.getSqrtRatioAtTick(tickLower),
                    TickMath.getSqrtRatioAtTick(tickUpper),
                    liquidity
                )
                : LiquidityAmounts.getAmount0ForLiquidity(
                    TickMath.getSqrtRatioAtTick(tickLower),
                    TickMath.getSqrtRatioAtTick(tickUpper),
                    liquidity
                )
        );

But both amount0 and amount1 are borrowed from LP's position during liquidity extraction if the position is in the current tick range. Hence my reasoning that those tokens are not part of the borrowedAmount.
Moreover, my issue #86, which is deemed valid and was confirmed by you, also explains why borrowedAmount in this case is less than extracted+swapped

Probably such a fantastic case is possible with positive slippage when the extracted+swaped tokens will be slightly more than the borrowedAmount, but in this case this dust will remain on the contract and it will be taken by the first one who calls the repay. We did not process these cases because they are unlikely and we wouldn't want to complicate the code and waste extra gas. The number of tokens in the single-side position will be more than on the current tick even if you exchange the second token.The price of a token will be worse in single positions.That is why borrowedAmount is calculated at the worst price that can be. I accepted #86 problem since it was possible to get DOS simply by sending a small number of tokens to the contract.
P.S. It would be great to receive more tokens when extracting liquidity on the current tick than after extracting in a single position.))

@seeques would you agree with the above?

@fann95 can you elaborate on what do you mean by "positive slippage" and "dust"? Does "dust" imply that the loss is constrained to a small amount? In what way?

Yes, I agree. I would argue though that any dust would not remain in the contract, but as a part of holdTokenBalance would be transferred to the Vault. And upon repayment this dust would not be taken as it would not be tranferred back to the contract from the Vault.

@seeques does it mean that this behavior doesn't present a high/medium severity issue?

It does not. I misinterpreted initially amounts calculation, but now I can see where my problem was.

Great that consensus has been achieved. Will be rejecting the escalation and keeping the issue invalid.

Result:
Invalid
Unique

Escalations have been resolved successfully!

Escalation status:

• seeques: accepted