Problem
Opening a short decreases the share reserves. We currently have a check that ensures that the share reserves are greater than the amount of longs outstanding divided by the open long share price; however, if there are no open longs, the share reserves can become zero during openShort: #384. Since we can't compute the proportional update to the bond reserves when the share reserves go from zero to non-zero (it results in a division by zero), we have a special case in _updateLiquidity that simply skips updating the share and bond reserves if the share reserves are equal to zero. In the context of all of the liquidity being removed from the pool by removeLiquidity, this _updateLiquidity edge case is safe; however, when the same edge case appears because the share reserves are reduced to zero by openShort, then we can get into situations where funds are lost.
Consider the following example:
- Alice initializes the pool.
- Celine shorts 100 DAI bonds.
- Alice removes all but 1e5 of her LP shares.
- 99% of the term passes.
- Bob opens a short that brings the share reserves to 0.
- The remainder of the term passes.
- Celine closes her short.
When Celine closes her short, the share reserves are 0. Closing a short at redemption should increase the share reserves by the bond amount (because the LP is redeeming a long that is equal in size to the short); however, the edge case in _updateLiquidity means that the share reserves will not be updated. Since the share reserves aren't updated but Celine receives the correct payout, the LPs funds become accounted for and can't be recovered.
Solution
A potential solution is to enforce a minimum share reserve balance. If we enforced this anytime capital left the system, then we could ensure that the share reserves never become zero which would prevent this bug from manifesting.
Problem
Opening a short decreases the share reserves. We currently have a check that ensures that the share reserves are greater than the amount of longs outstanding divided by the open long share price; however, if there are no open longs, the share reserves can become zero during
openShort: #384. Since we can't compute the proportional update to the bond reserves when the share reserves go from zero to non-zero (it results in a division by zero), we have a special case in_updateLiquiditythat simply skips updating the share and bond reserves if the share reserves are equal to zero. In the context of all of the liquidity being removed from the pool byremoveLiquidity, this_updateLiquidityedge case is safe; however, when the same edge case appears because the share reserves are reduced to zero byopenShort, then we can get into situations where funds are lost.Consider the following example:
When Celine closes her short, the share reserves are 0. Closing a short at redemption should increase the share reserves by the bond amount (because the LP is redeeming a long that is equal in size to the short); however, the edge case in
_updateLiquiditymeans that the share reserves will not be updated. Since the share reserves aren't updated but Celine receives the correct payout, the LPs funds become accounted for and can't be recovered.Solution
A potential solution is to enforce a minimum share reserve balance. If we enforced this anytime capital left the system, then we could ensure that the share reserves never become zero which would prevent this bug from manifesting.