TIP-541: Support canceling unstaking in Stake 2.0

[CooperDepp]

Tip:  541
Title: Support canceling unstaking in Stake 2.0
Author: CooperDepp <cooperdepp90@outlook.com>
Discussions-to: https://github.com/tronprotocol/tips/issues/541
Status: Final
Type: Standards Track
Category: Core
Created: 2023-05-05

Simple Summary

Add an API in Stake 2.0 to allow users to cancel the unstaking transactions in the waiting period.

Abstract

To be consistent with TVM instructions in Stake 2.0, it is proposed to add an API to support canceling unstaking in Stake 2.0, which means that users can use this API to cancel unstaking in waiting period time, make the unstaking TRX restaked, and meanwhile help users withdraw the TRX expired waiting period to balance.

Motivation

Stake 2.0 has been launched on TRON mainnet, one of the changes is that there is a waiting period of 14 days after unstaking. As said in this issue, if users misoperate the unstaking transaction, or they change their mind during the waiting period and want to restake the TRX for earnings, for now, they can do nothing but wait for 14 days. This is detrimental to the user's benefit and the staking rate of TRX on the chain.

Meanwhile, as Stake 2.0 has already supported TVM instructions to cancel the unstakings in the smart contract, I think it is reasonable to add an API in Stake 2.0 to cancel the unstaking transactions.

Specifications

Add wallet/cancelallunfreezev2 API, the user can call this API to cancel all the ongoing unstaking transactions in the waiting period.

Params:

1. owner_address - address of transaction initiator, data type is string
2. visible - whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is json string

Example:

curl -X POST  http://127.0.0.1:8092/wallet/cancelallunfreezev2 -d  \
'{
  "owner_address":"TVrukxw11XrfnXuqDgbyQEgogXr1vcoWcq", 
  "visible":true
}'

Backward Compatibility

It will not influence the existed staking and unstaking related transactions.

[lxcmyf]

The reason why the system contract did not implement this interface and the smart contract was implemented is because there is a possibility of suicide in the smart contract. In order to achieve contract suicide, the unfrozen queue must be cancelled first, and the system contract does not have this concern. At present, the unfrozen delay in receiving accounts is 14 days, which may not be very convenient for some users. Adding this interface is also necessary.

[Ademillery]

Looks good, if it is going to be adopted, do you need to open a proposal for voting?

[xylophonesir]

Need to add a new transaction type to support it , I think this needs to use the proposal enable the feature.

[CooperDepp]

I am glad to get yes and thumbs from you guys, so now I will try to create a proposal to suggest the dev team adopting this TIP issue.

[lxcmyf]

I see that the implementation of the CancelAllUnfreezeV2 command in the current smart contract is to cancel all unstakings, not to specify a few to cancel, but meanwhile to withdraw the expired TRX in these unstaking operations to the balance, and the unexpired TRX will be re-added to the staking assets.

I'm not sure whether this can meet the needs of most users. Some people may prefer to specify a few of the unstakings to cancel. What do you think?

In addition, can users accept that the unstaked TRX that have expired being withdrawn to the balance? Or should these resources be re-staked regardless of whether they are expired or not?

I think these issues need further discussion, let's hear everyone's opinions.

[dmf3030]

@lxcmyf please consider adding in an option to re-allocate frozen TRX to either bandwidth or energy when cancelling an unstake. Or making a discrete api call that would allow that re-allocation. Its is difficult if a user decides they need more bandwidth or energy and need to undergo a 14 day waiting period in order to rebalance.

If it is believe there needs to be some holding period then I would propose that maybe a user could re-allocate after a 2-3 unstake period but something shorter than 14 days. Again this could be worked into the unstake cancel, where if a call to cancel an unstake is more than three days after the initial unstake call then the user would also have the option to select a resource type to freeze to.

[lxcmyf]

Thank you for your suggestion. We will preliminarily evaluate it for possible use on the chain in the future.

[ev3rest]

I see that the implementation of the CancelAllUnfreezeV2 command in the current smart contract is to cancel all unstakings, not to specify a few to cancel, but meanwhile to withdraw the expired TRX in these unstaking operations to the balance, and the unexpired TRX will be re-added to the staking assets.

I'm not sure whether this can meet the needs of most users. Some people may prefer to specify a few of the unstakings to cancel. What do you think?

In addition, can users accept that the unstaked TRX that have expired being withdrawn to the balance? Or should these resources be re-staked regardless of whether they are expired or not?

I think these issues need further discussion, let's hear everyone's opinions.

The main reason to cancel the unstaking would be to get a certain amount back to resources. It would be beneficial if we could reallocate the canceled amount to either the energy or the bandwidth.

[lxcmyf]

I see that the implementation of the CancelAllUnfreezeV2 command in the current smart contract is to cancel all unstakings, not to specify a few to cancel, but meanwhile to withdraw the expired TRX in these unstaking operations to the balance, and the unexpired TRX will be re-added to the staking assets.
I'm not sure whether this can meet the needs of most users. Some people may prefer to specify a few of the unstakings to cancel. What do you think?
In addition, can users accept that the unstaked TRX that have expired being withdrawn to the balance? Or should these resources be re-staked regardless of whether they are expired or not?
I think these issues need further discussion, let's hear everyone's opinions.

The main reason to cancel the unstaking would be to get a certain amount back to resources. It would be beneficial if we could reallocate the canceled amount to either the energy or the bandwidth.

Yes, as you said.

[lxcmyf]

In the tron network, system contracts often synchronize the implementation of smart contracts. The smart contract has already implemented cancelAllUnfreezeV2. In recent updates, the system contract will synchronize the implementation of this interface, which temporarily does not support canceling the unstaking one by one, only supporting full cancellation. The reason is that the implementation of this interface includes withdrawing expired unstaking amounts, which increases the significance for canceling the unstaking. If there is a demand for canceling the unstaking one by one in the future, The naming of interfaces will be more strictly defined, and smart contracts will be implemented first. The system contract will be updated synchronously or both will be updated together.

[CooperDepp]

In the tron network, system contracts often synchronize the implementation of smart contracts. The smart contract has already implemented cancelAllUnfreezeV2. In recent updates, the system contract will synchronize the implementation of this interface, which temporarily does not support canceling the unstaking one by one, only supporting full cancellation. The reason is that the implementation of this interface includes withdrawing expired unstaking amounts, which increases the significance for canceling the unstaking. If there is a demand for canceling the unstaking one by one in the future, The naming of interfaces will be more strictly defined, and smart contracts will be implemented first. The system contract will be updated synchronously or both will be updated together.

Yes, it is acceptable, cancelling all the unfreeze TRX in waiting period is also compatible with the TVM instructions, well enough.

[otakuinny]

@lxcmyf, the next java version should also have an endpoint to switch trx staked for energy to bandwidth and vice versa without unstaking.

[lxcmyf]

@lxcmyf, the next java version should also have an endpoint to switch trx staked for energy to bandwidth and vice versa without unstaking.

@otakuinny That is something that could be considered in the future planning.

[CooperDepp]

Close this issue as it is implemented by GreatVoyage-v4.7.2.
Check TIP detail at TIP-541
Check implementation PR at tronprotocol/java-tron#5230, tronprotocol/java-tron#5260, tronprotocol/java-tron#5279