TIP-541 & TIP-542: The Usage Optimization for Stake 2.0

TIP-541 and TIP-542 are features introduced in the Periander version. By adding 2 proposals to expand Stake 2.0, they further improve the flexibility of the TRON staking mechanism.

TIP-541

In the versions previous to Periander, after initiating an unstaking transaction through the HTTP API in Stake 2.0, the user needs to wait for a 14-day waiting period before withdrawing the corresponding funds, and the unstaking cannot be canceled.

TIP-541 proposes to allow users to cancel unstakings that have been initiated but not completed yet. When canceling unstakings, all unstaked funds still in the waiting period will be re-staked, and the resource obtained through the re-staking remains the same as before. Unstakings that exceeded the 14-day waiting period cannot be canceled, and this part of the unstaked funds will be automatically withdrawn to the owner’s account.

This feature is controlled by the №77 parameter of the TRON network, which needs to be enabled through governance voting. 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":"a37074c63b2796b04b47cbaa7daf6bb7f116292b5c601ad7726029912b37520f",
    "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

TIP-542

In the versions previous to Periander, users can choose whether to lock or not when delegating resources. If chosen to lock, the resource delegating to the recipient address could not be canceled within 3 days, which is more conducive for users participating in the resource rental market.

TIP-542 proposes to further optimize the lock time when delegating resources, changing it from the current fixed value of 3 days to a configurable length of time for users according to their needs.

This feature is controlled by the №78 parameter of the TRON network. It needs to be enabled through governance voting. 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 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.

Summary

After the proposals to enable TIP-541 and TIP-542 take effect, TRON will provide users with more options, and greatly improve the flexibility of the staking system.