Withdrawing

There are four conditions under which a user can withdraw their stake from a dataset: the expected time for data changes, the dataset is cancelled, the dataset goes stale, or the data source goes down (so the user has to mark the dataset as being unavailable).

i) If a user stakes for a dataset and then the dataset is postponed for some reason, then the user can withdraw without any penalty up until the pre-data staking period. Alternatively, the user can choose to stay in the dataset and their lateness timer won’t start again until the dataset is open for data.

ii) If the dataset is cancelled, then the staked user has no choice but to withdraw since the dataset cannot be completed.

iii) If a dataset goes stale, then a user who has provided can withdraw their stake.

iv) For all other issues while the dataset is open and accepting data, the user should mark the dataset as unavailable.

Since the unexpected can happen and plans change, it is important to be able to have a certain amount of flexibility when staking, while still pushing users towards sending in the data on-time.

i) Since a user can stake at most 25 minutes before they’re late, staking and endorsing are generally close together, if not performed in the same sitting. When a dataset is postponed, the user could have to wait days before the dataset opens back up. Since this could end up getting the user slashed if they forget, giving the option to withdraw without penalty seemed natural.

ii) There’s no other option but to lock the collateral in the contract indefinitely, so withdrawing is the only thing that makes sense here.

iii) The idea behind staleness is to combat the poor experience a user could have by staking and providing data early and, for some reason, have no one else show up. It is bad practice to allow the first user’s collateral to be locked indefinitely waiting on either the creator to cancel the dataset or other endorsers to show up. So, the first user gets the best of both worlds. They get to stake and provide as soon as they’re ready and not be stuck due to a lack of action by the creator and other users, and they also still get paid if the dataset ever completes (provided they sent in the correct data).

iv) In the case of marking the data as unavailable, the idea is that if a staked user is going to go through the trouble of sending a transaction that isn’t the data, the data probably really isn’t available (because otherwise they could send the data for just as cheaply, get paid, and potentially have their stake locked for less time). Because of this philosophy, and because a withdrawn user no longer occupies a spot (denying anyone else from taking the spot), it is safe to pause the timer. This design always encourages someone to restake if they withdrew for a legitimate reason, which should lead to a better user experience and potentially better system liveness (getting the data faster).