core-contracts
core-contracts copied to clipboard
staking-pool: `unstake_all` will lock up the tokens that are already available to withdraw
Consider a situation like this:
- Stake 5 near with some pool;
- Unstake 1 near, and wait for the token to be released, so that it is available to withdraw;
At this point calling the unstake_all
method will move the 1 token that was available to withdraw back to the pending release state. Upon brief reading of the code around this area https://github.com/near/core-contracts/blob/dad58eb5f968c25913e746028ad63980506f5890/staking-pool/src/internal.rs#L154-L157 it seems like the behaviour would be the same for the regular unstake
method with the amount too.
I’d argue that this behaviour is super unintuitive. Now, some ideas on how it could be improved:
- Maintain a separate variable with the number of tokens that are available to withdraw. Any time
account.unstaked_available_epoch_height
is increased, the contract would move the tokens that are already available for withdraw to this new variable;- This still has a problem where the tokens would never become available to withdraw if
unstake(amount: 1N)
was called every 24 hours, for example (at least as long as the staked balance is available).
- This still has a problem where the tokens would never become available to withdraw if
- Maintain a log of pending unstakes?
- Sounds potentially pretty expensive on storage.
- Maintain a list of tokens pending to release for the upcoming
NUM_EPOCHS_TO_UNLOCK
epochs of interest.- Constant storage per account, that scales with
NUM_EPOCHS_TO_UNLOCK
rather than the number of operations. - Has the "intuitive" behaviour in all cases in that as tokens are unstaked they are always made available to withdraw
NUM_EPOCHS_TO_UNLOCK
epochs later, no matter what other operations have been executed before withdrawing.
- Constant storage per account, that scales with
Not sure if any of these changes are feasible or possible though (upgrading contract data sounds like it’d be non-trivial…)