xanoutas/solidity-security-findings huggingface dataset:
Setting amountOutMin to 0 results in potential loss of funds
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/mixins/VeloSolidMixin.sol#L41


# Vulnerability details

## Impact
If the amountOutMinis set to 0, it means that the trader is willing to accept any amount of output tokens in exchange for their input tokens. This could result in the trade being executed at a lower price than expected or intended, which could lead to a financial loss for the trader.

## Proof of Concept
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/mixins/VeloSolidMixin.sol#L41
it's generally recommended to set the amountOutMinparameter to a value that is higher than 0, to ensure that the trader receives a minimum acceptable amount of output tokens in exchange for their input tokens.

## Tools Used
manual
## Recommended Mitigation Steps
function _swapVelo(
        address _from,
        address _to,
        uint256 _amount,
        address _router
    ) internal {
        if (_from == _to || _amount == 0) {
            return;
        }

        uint256 output;
        bool useStable;
        IVeloRouter router = IVeloRouter(_router);
        address[] storage path = veloSwapPath[_from][_to];
        IVeloRouter.route[] memory routes = new IVeloRouter.route[](path.length - 1);
        uint256 prevRouteOutput = _amount;

        IERC20Minimal(_from)._safeIncreaseAllowance(_router, _amount);
        for (uint256 i = 0; i < routes.length; i++) {
            (output, useStable) = router.getAmountOut(prevRouteOutput, path[i], path[i + 1]);
            routes[i] = IVeloRouter.route({from: path[i], to: path[i + 1], stable: useStable});
            prevRouteOutput = output;
        }
-        router.swapExactTokensForTokens(_amount, 0, routes, address(this), block.timestamp);
+        router.swapExactTokensForTokens(_amount, prevRouteOutput, routes, address(this), block.timestamp);  
   }
Reentrancy Risk in Function report
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Vault/contracts/ReaperVaultV2.sol#L528


# Vulnerability details

## Impact
In statement ```token.safeTransferFrom(vars.stratAddr, address(this), vars.freeWantInStrat - vars.credit);```, if this token is ERC777 (extension of ERC20), receiver can register hook function which will be called when receiver send tokens, so receiver can increase state variable ```totalAllocated``` by re-entering the function ```report```, and then call the ```withdraw``` function to extract more assets with the same share.

## Proof of Concept
1. Enter the function ```report``` for the first time and execute ```token.safeTransferFrom```, which triggers the sender’s ```tokensToSend``` function.
2. In function ```tokensToSend```, sender can call the report function again to increase the ```totalAllocated```. 
3. Then sender call the ```withdraw``` function which will call function ```_withdraw```. In function ```_withdraw```, when calculating the ```value```, due to the increase of ```totalAllocated```, the value returned by ```balance()``` increases, which further causes the value returned by the ```_freeFunds()``` function to increase, resulting in an increase in the final calculated ```value```, which means the sender can extract more assets with the same share.
```
function withdraw(uint256 _shares) external {
    _withdraw(_shares, msg.sender, msg.sender);
}

function _withdraw(
    uint256 _shares,
    address _receiver,
    address _owner
) internal nonReentrant returns (uint256 value) {
    require(_shares != 0, "Invalid amount");
    value = (_freeFunds() * _shares) / totalSupply();
    ······
}

function _freeFunds() internal view returns (uint256) {
    return balance() - _calculateLockedProfit();
}

function balance() public view returns (uint256) {
    return token.balanceOf(address(this)) + totalAllocated;
}

```

## Tools Used

## Recommended Mitigation Steps
Add reentrancy lock for function ```report```.
`Single-side token` (`$OATH`) would still be used as a staking token instead of `LP token` (`$OATH LP`) within the LQTYStaking.sol
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L128
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L163


# Vulnerability details

## Impact
Staking contract (LQTYStaking) does not works as the protocol design.

## Proof of Concept
Within the LQTYStaking#`stake()`, 
the `lqtyToken` (= `OATH`) is deposited by transferring it from a user (msg.sender) to the LQTYStaking contract like this:
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L128
```solidity
    function stake(uint _LQTYamount) external override {
        ...
        // Transfer LQTY from caller to this contract
        lqtyToken.safeTransferFrom(msg.sender, address(this), _LQTYamount); /// @audit
        ...
```

Within the LQTYStaking#`unstake()`,  
the `lqtyToken` (= `$OATH`) is withdrawn by transferring it from the LQTYStaking contract to the user (msg.sender) like this:
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L163
```solidity
    function unstake(uint _LQTYamount) external override {
        ...

        if (_LQTYamount > 0) {
           ...
            // Transfer unstaked LQTY to user
            lqtyToken.safeTransfer(msg.sender, LQTYToWithdraw);
           ...
```

According to the [explanation about key changes](https://docs.reaper.farm/ethos-reserve-bounty-hunter-documentation/#balancer-pool-staking-token), it's written about a staking token like this:
> **_Balancer Pool Staking Token_**
> _Instead of a simple ERC-20 token being used within LQTYStaking, Ethos Reserve uses an 80/20 weighted liquidity pairing of OATH and ETH, created using Balancer V2._

According to [documentation (within the "LQTYStaking" page)](https://docs.reaper.farm/ethos-reserve-bounty-hunter-documentation/contracts-in-scope/lqtystaking), it's also written about a staking token like this:
> _Holders of an OATH LP can stake their LPs in this pool to receive ERN rewards from issuance fees (fees charged whenever someone takes out new debt)_

Based on the explanation and documentation above, the `Balancer Pool Staking Token` (`OATH LP` that is the OATH-ETH pair) is supposed to be used as a staking token instead of the `lqtyToken` (`OATH`) that is a single-side token within the LQTYStaking#`stake()` and the LQTYStaking#`unstake()` above.

However, within the LQTYStaking#`stake()` and the LQTYStaking#`unstake()` above, the `lqtyToken` (`$OATH`) that is a single-side token would still be used as a staking token instead of the `Balancer Pool Staking Token` (`OATH LP`) when staking token is transferred from a user (msg.sender) to the LQTYStaking contract (OATH Staking contract).

## Tools Used
Manual Review

## Recommended Mitigation Steps
Consider using the  the `Balancer Pool Staking Token` (`OATH LP`)  as a staking token instead of the the `lqtyToken` (`OATH`) that is a single-side token within b
``LUSDTokenAddressSet`` event never emitted in contract LQTYStaking.sol
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L49-L101
https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L49-L50
https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L93-L94


# Vulnerability details

## Impact
If an event is never emitted in Solidity, then there is no log or record stored of the event in the blockchain, so no application or contract can process and utilise information about the event.

## Proof of Concept
Nothing wrong with this code at first glance 
```
function setAddresses
    (
        address _lqtyTokenAddress,
        address _lusdTokenAddress,
        address _troveManagerAddress, 
        address _borrowerOperationsAddress,
        address _activePoolAddress,
        address _collateralConfigAddress
    ) 
        external 
        onlyOwner 
        override 
    {
        checkContract(_lqtyTokenAddress);
        checkContract(_lusdTokenAddress);
        checkContract(_troveManagerAddress);
        checkContract(_borrowerOperationsAddress);
        checkContract(_activePoolAddress);
        checkContract(_collateralConfigAddress);

        lqtyToken = IERC20(_lqtyTokenAddress);
        lusdToken = ILUSDToken(_lusdTokenAddress);
        troveManagerAddress = _troveManagerAddress;
        borrowerOperationsAddress = _borrowerOperationsAddress;
        activePoolAddress = _activePoolAddress;
        collateralConfig = ICollateralConfig(_collateralConfigAddress);

        emit LQTYTokenAddressSet(_lqtyTokenAddress);
        emit LQTYTokenAddressSet(_lusdTokenAddress);
        emit TroveManagerAddressSet(_troveManagerAddress);
        emit BorrowerOperationsAddressSet(_borrowerOperationsAddress);
        emit ActivePoolAddressSet(_activePoolAddress);
        emit CollateralConfigAddressSet(_collateralConfigAddress);

        _renounceOwnership();
    }
```
###### But check again and see this: 
```
event LQTYTokenAddressSet(address _lqtyTokenAddress);
event LUSDTokenAddressSet(address _lusdTokenAddress);
```
```
 emit LQTYTokenAddressSet(_lqtyTokenAddress);
 emit LQTYTokenAddressSet(_lusdTokenAddress);
```
There is an error in line 93-94 the emit statements in the ``setAddresses`` function. The first two emit statements are supposed to be ``LQTYTokenAddressSet`` and ``LUSDTokenAddressSet``, respectively, but they are both ``LQTYTokenAddressSet``.
## Tools Used
Manual Review
## Recommended Mitigation Steps
change it to this
```
 emit LQTYTokenAddressSet(_lqtyTokenAddress);
 emit LUSDTokenAddressSet(_lusdTokenAddress);
```
loss of funds to user when withdrawing from ReaperVaultERC4626 due to cap on user share value
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L399-L402
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L364-L366


# Vulnerability details

## Impact
At the end of `_withdraw`, if  vault balance after withdrawal from strategies is not enough to cover for user share value, user share value will be capped at vault balance after withdrawal from strategies. I believe that the cap is meant to limit the maximum number of shares that user can withdraw depending on the availability of funds in vault and strategies. However, the limit is implemented incorrectly and instead causes loss of funds to user as the amount they receive is lesser than what their shares are worth. 

## Proof of Concept

In `_withdraw` for `ReaperVaultV2`, we can see here that `value` is capped at whatever vaultBalance has after withdrawing all available funds from all strategies. I believe the intention for this is to limit the number of shares user can redeem, but instead the shares are burned and the share value is capped to the available vaultBalance after withdrawal from strategies.
 
```solidity
            vaultBalance = token.balanceOf(address(this));
            if (value > vaultBalance) {
                value = vaultBalance;
            }

```

Front part of `withdraw` that shows how user share `value` is calculated. Note that `value` has the loss of the strategies being deducted from it when withdrawing from strategies.
```solidity
        require(_shares != 0, "Invalid amount");
        value = (_freeFunds() * _shares) / totalSupply();
        _burn(_owner, _shares);
```


## Tools Used

Manual Review

## Recommended Mitigation Steps

Recommend reverting in the event user tries to withdraw an amount of share that is more than what is available. Another way is to calculate the amount available from all strategies and limit the user to only withdraw the number of shares that vault and strategies can allow.
Missed "emit" keyword before ActivePoolLUSDDebtUpdated(address _collateral, uint _LUSDDebt) event in ActivePool.sol
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L190-L195
https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L197-L202


# Vulnerability details

## Impact
ActivePoolLUSDDebtUpdated(address _collateral, uint _LUSDDebt) in increaseLUSDDebt(address _collateral, uint _amount) and decreaseLUSDDebt(address _collateral, uint _amount) seems lack a "emit" keyword. This can cause the function reverted and every function call increaseLUSDDebt and decreaseLUSDDebt will revert.

## Proof of Concept
    function increaseLUSDDebt(address _collateral, uint _amount) external override {
        _requireValidCollateralAddress(_collateral);
        _requireCallerIsBOorTroveM();
        LUSDDebt[_collateral] = LUSDDebt[_collateral].add(_amount);
        ActivePoolLUSDDebtUpdated(_collateral, LUSDDebt[_collateral]);
    }

    function decreaseLUSDDebt(address _collateral, uint _amount) external override {
        _requireValidCollateralAddress(_collateral);
        _requireCallerIsBOorTroveMorSP();
        LUSDDebt[_collateral] = LUSDDebt[_collateral].sub(_amount);
        ActivePoolLUSDDebtUpdated(_collateral, LUSDDebt[_collateral]);
    }

increaseLUSDDebt(address _collateral, uint _amount) and decreaseLUSDDebt(address _collateral, uint _amount) in ActivePool.sol will emit ActivePoolLUSDDebtUpdated(address _collateral, uint _LUSDDebt) event at the end. However, "emit" keyword is missed as you can see here. All functions call these two functions can revert due to error.

## Tools Used
Manual Review

## Recommended Mitigation Steps
Add "emit" keyword before the event.
Attacker can exploit No Slippage check in swapping using Sandwich Attack
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/mixins/VeloSolidMixin.sol#L41


# Vulnerability details

## Impact

Loss of Funds due to sandwich attack by attacker.

## Proof of Concept

```solidity
File: VeloSolidMixin.sol

41:     router.swapExactTokensForTokens(_amount, 0, routes, address(this), block.timestamp);

```
[Link to Code](https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/mixins/VeloSolidMixin.sol#L41)

There is a call to `_swapVelo` from the `_harvestCore` which uses `swapExactTokensForTokens` call to swap the token.

The arguments it is taking are:

```solidity

    function swapExactTokensForTokens(
        uint amountIn,
        uint amountOutMin,
        route[] calldata routes,
        address to,
        uint deadline
    )

```

Here, the second argument `amountOutMin` is there to protect the caller against the slippage. In case the `amountOut` value is less than the `amountOutMin`, the transaction reverts.

But in the `_swapVelo` method, `0` is passed for `amountOutMin` which means any MEV Bot or any Attacker can sandwich attack the transaction first by front running and then back running to take maximum advantage of slippage. It will lead to loss of funds to caller which is strategy in our case which indirectly uses the User Funds.

## Tools Used

VS Code

## Recommended Mitigation Steps

Use the Max Slippage value as a parameter rather than zero.
MEV Bot or any attacker can make risk free profit by interacting with `ReaperVaultERC4626`
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L418-L425
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L287-L289
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L330-L336
https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L365-L410


# Vulnerability details

## Impact

MEV Bot can make huge risk free profits which can lead to withdrawal of strategies and loss of funds for normal users.

## Proof of Concept

```solidity
File: ReaperVaultV2.sol

For Deposit:

330:    _amount = balAfter - balBefore;

334:    shares = (_amount * totalSupply()) / freeFunds;

336:    _mint(_receiver, shares);

For Withdrawal:

365:    value = (_freeFunds() * _shares) / totalSupply();

366:    _burn(_owner, _shares);

410:    token.safeTransfer(_receiver, value);

Free Fund method:

287:    function _freeFunds() internal view returns (uint256) {
288:        return balance() - _calculateLockedProfit();
289:    }

calculate Locked Profit method:

418:    function _calculateLockedProfit() internal view returns (uint256) {
419:        uint256 lockedFundsRatio = (block.timestamp - lastReport) * lockedProfitDegradation;
420:        if (lockedFundsRatio < DEGRADATION_COEFFICIENT) {
421:            return lockedProfit - ((lockedFundsRatio * lockedProfit) / DEGRADATION_COEFFICIENT);
422:        }
423:
424:        return 0;
425:    }

```
[Link to code](https://github.com/code-423n4/2023-02-ethos/blob/main/Ethos-Vault/contracts/ReaperVaultV2.sol#L418-L425)

To understand this attack, we need to understand how different values of methods throughout the lifecyle of locked profit affect the shares to be minted in deposit and value to be transafered in withdraw.

|                       | _calculateLockedProfit() | _freeFunds() | shares | value  |
|-----------------------|--------------------------|--------------|--------|--------|
| At start of the Cycle | x                        | b - x        | y      | z      |
| At end of the Cycle   | 0                        | b            | y - dy | z + dz |

Here: `x` is `lockedProfit`, `b` is `balance of token`, `y` is the shares that can be minted, `z` is the `value` that can be transferred initially and `dy` & `dz` be the change throughout a complete lifecycle of Locked Profit.

Here's how Bot can earn risk free:
1. It keeps the track of new funds getting added as profit through `report`.
2. It can add deposit a large amount [Let's say `z`] as soon as profit is added in locked state.
3. As it's start of that Locked Profit cycle, shares minted to Bot will be `y`.
4. Once that cycle comes to an end, Bot can withdraw `z + dz` amount with less than `y` shares (`y` - `dy` to be precise).

This way Bot can earn without taking any risk

## Tools Used

VS Code

## Recommended Mitigation Steps

It is recommended to not use dynamic predictative value
Under certain conditions the **increaseF_Collateral()** function from the **LQTYStaking** contract will not increase the reward per unit staked
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/LQTY/LQTYStaking.sol#L181


# Vulnerability details

***Description***

Due to decimal difference not taken into account, the **increaseF_Collateral()** function from  `LQTYStaking` contract will not increase the reward per unit staked.

***Impact***

If WBTC is used in collateral ; when collecting the 0.5% fee ([here](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/RedemptionHelper.sol#L197)) or when crediting the vault yield ([here](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L299)) and under this conditions : 

$collFeePerLQTYStaked = \frac{collWBTC*1^{18}}{totalLQTYStaked} <1 ⇔ collWBTC < \frac{totalLQTYStaked}{1^{18}}$

The **`LQTYStaking`** contract will not be credited, making these tokens to be lost forever and the LQTY stakers not receiving their rewards. 

Because WBTC has 8 decimals and LQTY has 18 decimals, it’s easy to find values that satisfy this condition.

***POC***

We call `increaseF_Collateral(address _collateral, uint collFee)` because we want to increase the reward per unit staked in the `LQTYStaking`contract. 

_collFee = 0.001 WBTC = 1e5 wsatoshi

totalLQTYStaked = 1_000_000 LQTY = 1e24 wei

With these values the bug condition is verified :

$$
collWBTC < \frac{totalLQTYStaked}{1^{18}} ⇔ 1e5 < 1e6
$$

***Mitigation***

One solution could be to keep the rounding error in a variable and credit the reward to stakers when it can be apply. Similarly to the `StabilityPool` contract with the **lastCollateralError_Offset** variable. [StabilityPool.sol#L524-L541](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L524-L541)
Re-balancing the vault allocation may always revert when distributing profits : resulting of a massive system DOS  
Audit: 2023-02-ethos-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L526-L538


# Vulnerability details

## Description

**[updateRewardSum](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L486-L500)** function call **[_computeRewardsPerUnitStaked](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L493)** with **_debtToOffset** set to 0. Meaning that the assignment [L531](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L531) will revert if `lastLUSDLossError_Offset != 0` (which is likely the case) because we try to assign a negative value to an **uint**.

## Impact

**[_rebalance()](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L239)** will be definitely DOS if the profit is greater than the **[yieldClainThreshold](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L252)** ⇒ **[vars.profit != 0](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L286)**.

Because they call **_rebalance()** all these functions will be DOS :

In `BorrowerOperations` 100% DOS
    - openTrove
    - closeTrove
    - _adjustTrove
        - addColl, withdrawColl
        - withdrawLUSD, repayLUSD
In `TroveManager` 80% DOS
    - liquidateTroves
    - batchLiquidateTroves
    - redeemCloseTrove

## POC

Context : the vault has compound enough profit to withdraw. ([here](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L252))

Alice initiates a trove liquidation. **[offset()](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L466)** in `StabilityPool` is called to cancels out the trove debt against the LUSD contained in the Stability Pool.

A floor division errors occur so now **[lastLUSDLossError_Offset](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L537)** is not null. 

Now, every time **[_rebalance()](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/ActivePool.sol#L305)** is called the transaction will revert. 

## Mitigation

In [StabilityPool.sol#L504-L544](https://github.com/code-423n4/2023-02-ethos/blob/73687f32b934c9d697b97745356cdf8a1f264955/Ethos-Core/contracts/StabilityPool.sol#L504-L544), just skip the floor division errors calculation if `_debtToOffset == 0` 

```solidity
if(_debtToOffset != 0){
	[StabilityPool.sol#L526-L538](