Malicious user can frontrun withdrawals from Insurance Fund to significantly decrease value of shares
When a user withdraws from the insurance fund, the value of their shares is calculated based on the balance of vUSD in the fund. Another user could deliberately frontrun (or frontrun by chance) the withdrawal with a call to `settleBadDebt` to significantly reduce the vUSD returned from the withdrawal with the same number of shares.\\nWhen a user wants to `withdraw` from the insurance pool they have to go through a 2 step withdrawal process. First they need to unbond their shares, and then they have to wait for the pre-determined unbonding period before they can `withdraw` the vUSD their shares are worth by calling `withdraw`.\\nWhen a user calls `withdraw` the amount of vUSD to redeem is calculated as:\\n```\\namount = balance() * shares / totalSupply();\\n```\\n\\nwhere `balance()` is the balance of vUSD in the contract and `totalSupply()` is the total supply of share tokens. Therefore, if the balance of vUSD in the contract were to decrease, then the amount of vUSD redeemed from the same number of shares would decrease as a result.\\nThis occurs when a trader's bad debt is settled when calling `settleBadDebt` in `MarginAccount.sol` as this calls `insuranceFund.seizeBadDebt` under the hood, which in turn calls `settlePendingObligation` which transfers vUSD out of the insurance fund to the margin account:\\n```\\nvusd.safeTransfer(marginAccount, toTransfer);\\n```\\n\\nThe result is now that the balance of vUSD in the insurance fund is lower and thus the shares are worth less vUSD as a consequence.
One option would be to include a slippage parameter on the `withdraw` and `withdrawFor` methods so that the user redeeming shares can specify the minimum amount of vUSD they would accept for their shares.\\nWhen depositing into the insurance fund, the number of shares to mint is actually calculated based on the total value of the pool (value of vUSD and all other collateral assets). Therefore, the withdraw logic could also use `_totalPoolValue` instead of `balance()` to get a "true" value per share, however this could lead to withdrawals failing while assets are up for auction. Assuming all the assets are expected to be sold within the short 2 hour auction duration, this is probably the better solution given the pricing is more accurate, but it depends if users would accept failed withdrawals for short periods of time.
A user withdrawing from the insurance fund could receive significantly less (potentially 0) vUSD when finalising their withdrawal.
```\\namount = balance() * shares / totalSupply();\\n```\\n