# Simple Summary

In order to further improve the accessibility and flexibility of Stake 2.0, it is proposed that after the mainnet is upgraded to the Periander version, the Stake 2.0 extension will be enabled, please refer to [TIP-541](https://github.com/tronprotocol/tips/issues/541) and [TIP-542](https://github.com/tronprotocol/tips/issues/542).

# Motivation

Stake 2.0 is a new milestone of the TRON network, which has fully upgraded the staking mechanism. Compared with Stake 1.0, Stake 2.0 is more flexible, efficient and intelligent, it significantly improves the flexibility of TRON network resources and voting management.

Since Stake 2.0 was enabled on the mainnet for more than two months, the community has put forward some suggestions for improvement:

- There is a waiting period of 14 days after unstaking in Stake 2.0, 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.

- Currently when users initiate a resource delegating transaction, if the `lock` parameter is set to `true`, the resource can not be undelegated within 3 days. However, the solid lockup time of 3 days can not meet all the scenarios and is not conducive to the two parties to agree on a lease time in advance. Making the lockup time a customizable time will enhance the flexibility in delegation transactions.

Therefore, GreatVoyage-v4.7.2(Periander) introduces [TIP-541](https://github.com/tronprotocol/tips/issues/541) and [TIP-542](https://github.com/tronprotocol/tips/issues/542). [TIP-541](https://github.com/tronprotocol/tips/issues/541) added a new governance proposal to allow users to cancel the unstaking that has been initiated but not yet completed, and [TIP-542](https://github.com/tronprotocol/tips/issues/542) added a new governance proposal to allow users to specify the resource delegating lockup time according to their needs.

# Specification

Propose to modify the No.77 and No.78 TRON Network Parameters to enable the Stake 2.0 extension,

- getAllowCancelAllUnfreezeV2 (No.77)
The No. 77 network parameter is set to 1, it means that the function of allowing cancellation of unstakings is enabled.

- getMaxDelegateLockPeriod (No.78)
The No. 78 network parameter is set to a value larger than 86400, it means that the function of allowing specification of resource delegating lockup time is enabled. The value indicates the maximum value of the lock time that can be set, unit is block interval (3 seconds). So setting the value as 144000 means maximum locking time is 5 days (144000*3/24/60/60).

# How to initiate the voting request
Enable the usage optimization for Stake 2.0,
- createProposal 77 1 78 864000

# Analysis
After it is enabled, the nodes will support a new transaction type, and users can use the `wallet/cancelallunfreezev2` API to create an unstaking canceling transaction:

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

The return value in the above example is an unsigned transaction, it should be signed and broadcasted then.

After the above transaction is successfully on chain, you can use `wallet/gettransactioninfobyid` to query the amount of unstaking TRX that canceled and the amount of unstaked TRX withdrawn to the account:

curl -X POST http://127.0.0.1:8090/wallet/gettransactioninfobyid -d \
'{"value":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
  "visible":true
}'

{
    ...
    "cancel_unfreezeV2_amount":[
        {
            "key": "BANDWIDTH",
            "value": 2000000000
        },
        {
            "key": "ENERGY",
            "value": 3000000000
        },
        {
            "key": "TRON_POWER",
            "value": 0
        }
    ],
    "withdraw_expire_amount": 1000000000
}

* `cancel_unfreezeV2_amount`: the amount of unstaking TRX that canceled, the unit is sun
* `BANDWIDTH`: `cancel_unfreezeV2_amount[0].value` is the amount of TRX re-staked to obtain bandwidth, the unit is sun
* `ENERGY`: `cancel_unfreezeV2_amount[1].value` is the amount of TRX re-staked to obtain energy, the unit is sun

* `withdraw_expire_amount`: the amount of unstaked TRX withdrawn to the account, the unit is sun

When enabling the proposal, a time parameter needs to be specified, indicating the maximum value of the lock time that can be set. Once enabled, a new parameter, `lock_period`, will be added to `wallet/delegateresource` API:

curl -X POST http://127.0.0.1:8090/wallet/delegateresource -d \
'{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "receiver_address": "TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1",
  "balance": 1000000,
  "resource": "ENERGY",
  "lock": true,
  "lock_period": 86400,
  "visible": true
}'

* `lock`: whether to lock the delegating
* `lock_period`: lock time, only when `lock` is `true`, this field is valid. The owner cannot cancel the delegating before the lock time is up. The unit of `lock_period` is block interval(3 seconds). This field indicates the time of how many blocks will be produced from the moment the transaction is executed. So the above `86400` means locking for 259200 seconds (3 days). `lock_period` cannot exceed the maximum lock period (value of the No.78 network parameter).

The default value of `lock_period` is 86400, which is 3 days. That is, when `lock` is `true`, if `lock_period` is not specified or set to `0`, `lock_period` will be set to `86400` by default, which will ensure the compatibility before and after TIP-542 takes effect.

In addition, the minimum value of `lock_period` cannot be lower than the remaining lock time of this type of resource that was previously delegated to the same recipient address，and the value will overwrite the remaining lock time of the previous delegating.

For example, user A delegates 100 energy shares to B, and `lock_period` is set to `57600` (2 days), and the remaining lock time after 1 day is `28800`. At this time, when A delegates energy to B again, if choose to lock,`lock_period` should be set to at least `28800` (1 day), otherwise, an exception error will be thrown when creating the delegating transaction: `The lock period for ENERGY this time cannot be less will be thrown when creating a proxy transaction than the remaining time[9600000ms] of the last lock period for ENERGY!`. If A choose to lock `86400`, this will overwrite the remaining lock time from 1 day to 3 days.

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