Description

In order to ensure that depositors to the OstiumVault do not front-run large trader wins with pulling out their funds (and therefore not be exposed to the corresponding losses), there is an epoch system where depositors must issue a withdrawal request first and then wait a few epochs, depending on the collateralization.

However, there is no penalty for requesting a withdrawal from the vault and then just not using it. The only cost a depositor has to pay to issue a spurious withdrawal request is the gas fees associated with the transaction, which is a constant amount.

Impact

The withdrawal epoch safety feature can be bypassed by requesting a withdrawal every epoch. This costs a constant amount of gas, and so in terms of percentage of deposit, for large depositors it is a small price to pay for the ability to front-run losses.

An enterprising third party could set up a separate smart contract that deposits on behalf of its users and then charge a small fee to continually issue withdrawal requests into the OstiumVault for the entire amount, allowing its users to withdraw through the contract whenever they wish.

Recommendations

One way to remediate this issue would be to charge users a percentage-based fee for withdrawal requests. However, that is unfriendly to the users, since it cannot be refunded if they actually proceed with the withdrawal (because then a user can just redeposit the funds to "cancel" the withdrawal).

A second way to remediate this issue would be to record the share price at the time of a withdrawal request and then, if the withdrawal is completed, use the lower of the current price and the request-time price. If the withdrawal expires without being completed, and the share price is higher, the amount of shares the user owns should be adjusted down to reflect what would have happened if they held cash through the withdrawal process.

This can be implemented without requiring a cleanup action per user for each new epoch as follows. When a user makes a withdrawal request, the amount of shares they are withdrawing is transferred elsewhere, and then both the amount of shares and the dollar amount of their current value are added to their respective withdrawRequests mappings. Later, when a user completes a withdrawal, the dollar amount is calculated, and if it is below the pro rata portion of the dollar amount in the mappings, the lower amount is used. On the other hand, if the user did not proceed with the withdrawal, at any time they can elect to cancel the withdrawal (even many epochs later), and if they do that, then they will get shares equal to the request-time dollar amount.

This is safe because it means that while a withdrawal is pending, the user effectively holds the worse of both dollars and shares from the request time until present, so users who do not complete a withdrawal over a long period of time are not exposed to any upside the vault can get.

A third way to remediate this issue would be to allow anyone to complete a withdrawal on behalf of anyone else, maybe with the collection of a token fee to compensate for gas and incentivize action. This would require making sure that the price never changes during an epoch, for safety. However, this would definitely ensure that spurious withdrawals do not happen.

Remediation