What is Stake 2.0?

TRON Core Devs
TRON
Published in
18 min readJan 6, 2023

--

Stake 2.0 is a brand-new stake mechanism proposed by the TRON community, please refer to TIP-467. Compared with the current Stake 1.0, Stake 2.0 improves the flexibility of stake, reduces the complexity of user operations, and improves resource delegating efficiency and resource utilization. Stake 2.0 also realizes the seamless integration of the staking system and TVM, supports the execution of staking and resource delegate operations in smart contracts, and enriches the application scenarios to TRON smart contracts.

In this article, we will introduce how Stake 2.0 works in detail to TRX holders, TRON developers, and DAPP users.

How to adapt to Stake 2.0, please refer to: Stake 2.0 Adaption FAQ.

Why do we need Stake 2.0?

First of all, let’s review Stake 1.0 again. In Stake 1.0, the users stake TRX to obtain voting rights (TRON Power), and at the same time obtain either bandwidth or energy as they wish, and the obtained resources can also be delegated to other addresses, only if the receiving address is specified during the stake operation. When the staking is completed, the unstaking is not allowed within 3 days. The users can perform the unstaking after 3 days and immediately obtain the staked TRX, in the meantime, all votes will be automatically revoked and the voting rights will be reclaimed.

The resource management in Stake 1.0 lacks flexibility. Since the staking and the delegate operation are bound together, if you need to change the receiving address, you need to unstake first, then re-stake and specify the new receiving address. Since the 3-day unstaking policy, the resources obtained by the staking will not be able to be delegated to other addresses within these 3 days, which greatly reduces the efficiency of resource delegating. If the user has already voted before unstaking, the unstaking will also revoke the votes. Therefore, the voting operation needs to be performed again after re-staking, which greatly increases the complexity of user operations.

In addition, since TVM does not support staking and voting-related instructions in Stake 1.0, developers cannot implement staking, delegating, voting and other operations in smart contracts, which limits the applications related to staking and resource delegating, such as staking tokenization and decentralized resources lending and so on.

Therefore, we need a new stake mechanism to address these problems, separate the low-frequency stake operation from the high-frequency resource delegate operation, support the reallocation of resources in the staked state, and improve the flexibility of resource management. TVM adds staking and voting-related commands to provide richer application scenarios for the ecology. The new mechanism should support the delayed arrival of unstaked TRX when unstaking, improve the stability of the stake model in fierce market environments, and build a more anticipated future of the entire network circulation for the network participants.

Difference between Stake 1.0 and Stake 2.0

The difference between Stake 2.0 and Stake 1.0 is mainly reflected in the following aspects below,

Below is a detailed description of the differences between Stake 1.0 and Stake 2.0.

Operation of Staking and Resource Management

In Stake 1.0, staking and delegating are combined in one transaction. The resource recipient should be specified when performing the stake operation. After a staking is done, the resource will be delegated to the designated resource recipient address. And unstaking and undelegating are also combined in one transaction, If you want to cancel the delegating, you must unstake the corresponding TRX.

Stake 2.0 separates staking and delegating into two transactions. The user first performs the stake operation. After completing the staking, the resource is first allocated to the user’s account, and then the user can perform the delegate operation to delegate the resource to others. If the user wants to undelegate the resource to a certain recipient, the user can directly perform the undelegate operation without unstaking and then can delegate the resource to other recipients as needed.

Separation of staking and resource delegating simplifies user operations and improves the efficiency of resource delegating.

Resource Management

In Stake 1.0, if you stake TRX and delegate the resources to other addresses, unstaking cannot specify an amount, you can only specify the resource type and the recipient address, then unstake all correlated TRX. This is optimized in Stake 2.0, you can specify the type of resource and the amount to unstake.

In Stake 1.0, once you make an unstaking, all the votes you have made would be revoked, and you have to make the votes again with the TRON Power left in your account to avoid the loss of voting reward. This is also optimized in Stake 2.0, partial unstaking would not revoke all votes, it releases the spare voting rights first, and if the spare voting rights are insufficient, then it would revoke a certain amount of votes as needed.

In Stake 1.0, to cancel a certain type of resource delegating for a certain address, you can only cancel all of them at once, and you cannot cancel by specifying an amount. This is also optimized in Stake 2.0, we can only cancel part of it as needed, which improves the flexibility of resource management.

Unstaking Lock Period

In Stake 1.0, each time after specifying a type of resource to stake for a certain recipient address, all the staked TRX corresponding to such resource type for that recipient address will be locked for three days before unstaking.

In Stake 2.0, after staking TRX, unstaking can be done anytime and will be not affected by any new staking transactions. After unstaking, you only need to wait for a short period and then withdraw the unstaked TRX.

TVM Supporting Stake and Delegate Instructions

In Stake 1.0, the TVM does not support any stake and delegate related instructions. In Stake 2.0, the TVM supports all Stake 2.0 related instructions, and users can perform TRX staking and resource delegating related operations in smart contracts. More application layer protocols can be implemented based on smart contracts, bringing richer application scenarios to the TRON smart contract ecosystem.

How Stake 2.0 Works?

In Stake 2.0, the relevant logic of user stake and unstake is as follows,

  • The user calls /wallet/freezebalancev2 to stake TRX and obtains a specified type of resource, either energy or bandwidth. After the staking is completed, the resource will be allocated to the owner’s account. In addition, users can also obtain voting rights (TRON Power), and 1 TRX for 1 TRON Power.
  • After staking, the user may call /wallet/delegateresource to delegate the resources to other accounts in batches. The time lock is an optional parameter of the /wallet/delegateresource API. If the time lock is not used, undelegating can be performed immediately after the resource is delegated. If the time lock is used, it needs to wait for 3 days before undelegating is performed. During the waiting period, if the user performs resource delegating again for the same address, the 3-day waiting time will be reset.
  • When a user wants to undelegate a specific amount of resources to an address, they can call the /wallet/undelegateresource API to perform an undelegate operation.
  • Users can call /wallet/unfreezebalancev2 to unstake. This API supports specifying a specific amount of TRX to unstake, but the TRX corresponding to the delegated resources cannot be unstaked since the resources obtained by this part of TRX are still in use, this part of TRX is considered locked.
  • After the user performs the unstake operation, he needs to wait for N days, and call /wallet/withdrawexpireunfreeze after N days to withdraw the assets to his account.

The above mainly introduces the process of user operations under the Stake 2.0 mechanism. Below we refer to the resource recovery, unstake times, and how to deal with TRON Powner resources in the account after unstaking involved in the above process, and make some supplementary explanations.

Resource Recovery

When a resource recipient has used part of the delegated resource and the owner of the resource cancels the delegate and withdraws the resource to delegate to a new recipient, only the spare part of the resource is available to be delegated to the new recipient since the part used by the last recipient are still in recovery state, which cannot be delegated to others. For example,

Assume that A has 1000 units of energy and A delegates 1000 energy to B. When B uses up 400 energy, A cancels the delegate to B. After the cancellation is completed, A’s account will have 600 units of energy available, and the 400 units used by B is in recovery. If A wants make delegate again at this time, he can only allocate the 600 units to others.

Number of Unstake

Stake 2.0 supports unstaking in batches, but only allows a maximum of 32 unstake operations at the same time. That is to say, when a user initiates the first unstake operation, before the TRX of the first unstaking arrives and is ready to be withdrawn to his or her account, he or she can only initiate another 31 unstake operations. This can prevent malicious attacks. For example, if a user stakes 100,000 TRX, if there is no such restriction, a user can initiate 100,000 unstakes in a short period of time, since the expiration time of each unstake is different, the network needs to record all these unstaking, which requires a large number of storage resources. Such a situation may pile up and will eventually make unbearable storage to the network.

TRON Power Reclaim

Like Stake 1.0, after staking TRX in Stake 2.0, in addition to energy or bandwidth, the users can also get TRON Power (TP). TP is voting right, and 1 TRX is staked to get 1TP. In Stake 2.0, the user will lose the same amount of TP resources after unstaking TRX, but Stake 2.0 will give priority to reclaiming idle TP resources (not voted yet). If the idle TP is insufficient, it will continue to reclaim the used TP. If the user has voted for multiple super representatives, a certain number of votes will be withdrawn in proportion from each super representative, and the corresponding voting rights will be recovered. The calculation formula for withdrawing votes for each SR is,

Number of votes for the current Super Representative * (Number of votes to be withdrawn / total number of votes)

For example,

Suppose A staked 2,000TRX and obtained 2,000 TRON Power, of which 1,000 TRON Power voted for 2 super representatives, 600 votes and 400 votes respectively, and 1,000 TRON Power remained in the account. At this time, A unstakes 1,500TRX, which means that 1,500 TRON Power needs to be reclaimed from A’ account. In this case, the idle 1,000 TP in A’s account will be withdrawn first, and the spared 500 TP will be withdrawn from the voted TP,
which is 300 TP and 200 TP respectively from the two super representatives. Here's how the votes are calculated:

Number of votes withdrawn by Super Representative 1 = 600 * (500 / 1,000)
Number of votes withdrawn by Super Representative 2 = 400 * (500 / 1,000)

How to Prepare for Stake 2.0?

Stake 2.0 needs to be opened through on-chain governance voting. After Stake 2.0 is opened, staking can be only done through Stake 2.0. The resources already obtained under Stake 1.0, including the voting on the chain are still valid and will not change. All the assets can be still redeemed using the unstaking method of Stake 1.0.

Developers should check whether their business involves on-chain staking. If so, they should make preparations for adaptation before Stake 2.0 is launched, and ensure that they switch to the new stake API in time after Stake 2.0 is launched.

Stake 2.0 will be deployed and opened on the test network in advance before the mainnet. It is recommended that developers who need to adapt do full testing on the test network in advance to prepare for the Stake 2.0 adaptation on the TRON mainnet.

Stake 2.0 HTTP API

To implement the new mechanism, 10 HTTP APIs have been added. Please check the following for details of the new APIs,

wallet/freezebalancev2

Description: stake TRX to obtain TRON Power (voting rights) and bandwidth or energy.

Params:

  1. owner_address — Address of transaction initiator, data type is string
  2. frozen_balance — Amount of TRX to be staked, unit is sun, data type is uint256
  3. resource — Resource type, “BANDWIDTH” or “ENERGY”, data type is string
  4. visible — Whether the address is in Base58 format, data type is bool

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST  https://api.nileex.io/wallet/freezebalancev2 -d  \
'{"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"frozen_balance":1000000,
"resource":"BANDWIDTH",
"visible":true
}'


{
"visible": true,
"txID": "c47d24499b6e1aa24b1fde87538bf6ef617b6bb14188756b063ed017775fa02d",
"raw_data": {
"contract": [{
"parameter": {
"value": {
"frozen_balance": 1000000,
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM"
},
"type_url": "type.googleapis.com/protocol.FreezeBalanceV2Contract"
},
"type": "FreezeBalanceV2Contract"
}],
"ref_block_bytes": "0f9b",
"ref_block_hash": "dd6ad8232cea90db",
"expiration": 1676433468000,
"timestamp": 1676433410855
},
"raw_data_hex": "0a020f9b2208dd6ad8232cea90db40e0d4e299e5305a57083612530a34747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e467265657a6542616c616e63655632436f6e7472616374121b0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d70a796df99e530"
}

/wallet/unfreezebalancev2

Description: Unstake TRX to release bandwidth and energy and at the same time TRON Power will be reclaimed and corresponding votes will be revoked. After executing this transaction, the users need to wait for ’N’ days, then they can call /wallet/withdrawexpireunfreeze to get back their funds.

Params:

  1. owner_address — Address of transaction initiator, data type is string
  2. unfreeze_balance — Amount of TRX to be unstaked, unit is sun, data type is uint256
  3. resource — Resource type, “BANDWIDTH” or “ENERGY”, data type is string
  4. visible — Whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is json string

Example:

curl -X POST  https://api.nileex.io/wallet/unfreezebalancev2 -d  \
'{"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"unfreeze_balance":1000000,
"resource":"BANDWIDTH",
"visible":true
}'

{
"visible": true,
"txID": "0ae214ece4018868bd114bce1eb208c3848320fee86bd505179f37d9d4299795",
"raw_data": {
"contract": [{
"parameter": {
"value": {
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"unfreeze_balance": 1000000
},
"type_url": "type.googleapis.com/protocol.UnfreezeBalanceV2Contract"
},
"type": "UnfreezeBalanceV2Contract"
}],
"ref_block_bytes": "1c62",
"ref_block_hash": "2e7109b917cc2abf",
"expiration": 1676443383000,
"timestamp": 1676443323678
},
"raw_data_hex": "0a021c6222082e7109b917cc2abf40d8e9bf9ee5305a59083712550a36747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e667265657a6542616c616e63655632436f6e7472616374121b0a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca10c0843d709e9abc9ee530"
}

/wallet/delegateresource

Description: delegate bandwidth or energy resource to other address

Params:

  1. owner_address — Address of transaction initiator, data type is string
  2. receiver_address — Receiver address of resource to be delegated to
  3. balance — Amount of TRX staked for resources to be delegated, unit is sun, data type is unit256
  4. resource — Resource type, “BANDWIDTH” or “ENERGY”, data type is string
  5. lock — Whether it is locked, if it is set to true, the delegated resources cannot be undelegated within 3 days. When the lock time is not over, if the owner delegates the same type of resources using the lock to the same address, the lock time will be reset to 3 days
  6. visible — Whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST  https://api.nileex.io/wallet/delegateresource -d  \
'{"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"receiver_address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"balance":1000000,
"resource":"BANDWIDTH",
"lock": false,
"visible":true
}'

{
"visible": true,
"txID": "019ad89c89dc007a5aea99c8b14faff568574b922512cf276aea4cd1f319d123",
"raw_data": {
"contract": [{
"parameter": {
"value": {
"balance": 1000000,
"receiver_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM"
},
"type_url": "type.googleapis.com/protocol.DelegateResourceContract"
},
"type": "DelegateResourceContract"
}],
"ref_block_bytes": "1cb3",
"ref_block_hash": "3cdf3351b93a9439",
"expiration": 1676443626000,
"timestamp": 1676443567614
},
"raw_data_hex": "0a021cb322083cdf3351b93a94394090d4ce9ee5305a6f0839126b0a35747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e44656c65676174655265736f75726365436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca18c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70fe8bcb9ee530"
}

/wallet/undelegateresource

Description: undelegate resource

Params:

  1. owner_address — Address of transaction initiator, data type is string
  2. receiver_address — Receiver address of resource to be delegated to
  3. balance — Amount of TRX staked for resource to be undelegated, unit is sun, data type is unit256
  4. resource — Resource type, “BANDWIDTH” or “ENERGY”, data type is string
  5. visible — Whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST  https://api.nileex.io/wallet/undelegateresource -d  \
'{"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"receiver_address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"balance":1000000,
"resource":"BANDWIDTH",
"visible":true
}'

{
"visible": true,
"txID": "294929e4f7b20d4c30faa0015c980ae827fc10bc587f9a75a6ecff2413d25b33",
"raw_data": {
"contract": [{
"parameter": {
"value": {
"balance": 1000000,
"receiver_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM"
},
"type_url": "type.googleapis.com/protocol.UnDelegateResourceContract"
},
"type": "UnDelegateResourceContract"
}],
"ref_block_bytes": "2280",
"ref_block_hash": "da350a0ba8f3668a",
"expiration": 1676448129000,
"timestamp": 1676448069711
},
"raw_data_hex": "0a0222802208da350a0ba8f3668a40e8bfe1a0e5305a71083a126d0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca18c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70cff0dda0e530"
}

/wallet/withdrawexpireunfreeze

Description: withdraw unfrozen balance, the user can call this API to get back their funds after executing /wallet/unfreezebalancev2 transaction and waiting N days, N is a network parameter.

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  https://api.nileex.io/wallet/withdrawexpireunfreeze -d  \
'{
"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"visible":true
}'

{
"visible": true,
"txID": "294929e4f7b20d4c30faa0015c980ae827fc10bc587f9a75a6ecff2413d25b33",
"raw_data": {
"contract": [{
"parameter": {
"value": {
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM"
},
"type_url": "type.googleapis.com/protocol.WithdrawExpireUnfreezeContract"
},
"type": "WithdrawExpireUnfreezeContract"
}],
"ref_block_bytes": "2280",
"ref_block_hash": "da350a0ba8f3668a",
"expiration": 1676448129000,
"timestamp": 1676448069711
},
"raw_data_hex": "0a0222802208da350a0ba8f3668a40e8bfe1a0e5305a71083a126d0a37747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e556e44656c65676174655265736f75726365436f6e747261637412320a1541ce8a0cf0c16d48bcf22825f6053248df653c89ca18c0843d221541fd49eda0f23ff7ec1d03b52c3a45991c24cd440e70cff0dda0e530"
}

/wallet/getavailableunfreezecount

Description: remaining times of executing unstake operation

Params:

  1. owner_address — account address, data type is string.
  2. visible — whether the address is in base58 format, data type is bool

Returns:

  1. count — Remaining times of available unstaking, data type is number.

Example:

curl -X POST  https://api.nileex.io/wallet/getavailableunfreezecount -d  \
'{
"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"visible":true
}'

{
"count": 31
}

/wallet/getcanwithdrawunfreezeamount

Description: query the withdrawable balance at the specified timestamp

Params:

  1. owner_address — account address, data type is string.
  2. timestamp — query cutoff timestamp, in milliseconds.
  3. visible — Whether the address is in Base58 format, data type is bool

Returns :

  1. amount — withdrawable balance, unit is sun.

Example:

curl -X POST  https://api.nileex.io/wallet/getcanwithdrawunfreezeamount -d  \
'{
"owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"timestamp":1706448129000,
"visible":true
}'

{
"amount": 3000000
}

/wallet/getcandelegatedmaxsize

Description: query the amount of delegatable resources share of the specified resource Type for target address, unit is sun.

Params:

  1. owner_address — account address, data type is string.
  2. type — resource type, data type is number, 0 is bandwidth, 1 is energy
  3. visible — whether the address is in base58 format, data type is bool

Returns :

  1. max_size — the amount of delegatable resource share, unit is sun.

Note: This API indicates the return of the maximum delegable resource share, but this API only assumes that your delegate resource transaction will not include situations that consume additional resources, such as a memo, etc. Otherwise, the maximum value of specific resources that can be delegated may be smaller than the recommended value returned through this API.

Example:

curl -X POST  https://api.nileex.io/wallet/getcandelegatedmaxsize -d  \
'{
"owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"type": 1,
"visible": true
}'

{
"max_size": 11000000
}

/wallet/getdelegatedresourcev2

Description: query the amount of resource delegated by fromAddress to toAddress

Params:

  1. fromAddress — resource from address, data type is string.
  2. toAddress — resource to address, data type is string.
  3. visible — whether the address is in base58 format, data type is bool.

Returns: Resource delegation list, each resource delegation information includes below fields:

  1. delegatedResource.from — owner address.
  2. delegatedResource.to — recipient address.
  3. delegatedResource.frozen_balance_for_bandwidth — amount of TRX staked for bandwidth delegated from delegatedResource.from address to delegatedResource.to address.
  4. delegatedResource.frozen_balance_for_energy — amount of TRX staked for energy delegated from delegatedResource.from address to delegatedResource.to address.

Example:

curl -X POST  https://api.nileex.io/wallet/getdelegatedresourcev2 -d  \
'{"fromAddress":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"toAddress":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"visible":true
}'

{
"delegatedResource": [{
"from": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"to": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
"frozen_balance_for_bandwidth": 7000000,
"frozen_balance_for_energy": 1000000
}]
}

/wallet/getdelegatedresourceaccountindexv2

Description: query the resource delegation index by an account. Two lists will return, one is the list of addresses the account has delegated its resources(toAddress), and the other is the list of addresses that have delegated resources to the account(fromAddress).

Params:

  1. value — account address, data type is string.
  2. visible — whether the address is in base58 format, data type is bool

Returns: Resource delegation index, including below fields:

  1. account — address to query.
  2. fromAccounts — the list of accounts which delegated resources to account.
  3. toAccounts — the list of accounts which account delegated resources to.

Example:

curl -X POST  https://api.nileex.io/wallet/getdelegatedresourceaccountindexv2 -d  \
'{
"value":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"visible": true
}'

{
"account": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
"fromAccounts": ["TUznHJfHe6gdYY7gvWmf6bNZHuPHDZtowf"],
"toAccounts": ["TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g"]
}

Stake 2.0 Solidity API

Stake 2.0 realizes the integration with TVM, users can perform staking/unstaking, delegating/undelegating, resource status query, etc. in the smart contract, the following introduces the Solidity APIs related to Stake 2.0.

freezebalancev2(uint amount, uint resourceType)

Description: stake TRX to obtain TRON Power (voting rights) and bandwidth or energy. If fails, the revert exception will be thrown

Params:

  1. amount — amount of TRX to be staked, unit is sun
  2. resourceType — resource type, 0 is “BANDWIDTH” and 1 is “ENERGY”

Returns: N/A

Example:

pragma solidity ^0.8.17;

contract C {
event BalanceFreezedV2(uint, uint);

// stake 1 TRX to obtain energy
function example() external {
freezebalancev2(1000000, 1);
emit BalanceFreezedV2(1000000, 1);
}
}

unfreezeBalanceV2(uint amount, uint resourceType)

Description: unstake TRX to release bandwidth and energy and at the same time TRON Power will be reduced and corresponding votes will be canceled. After executing this transaction, the users need to wait for N days, then they can call withdrawexpireunfreeze to withdraw their funds.

Params:

  1. amount — amount of TRX to be staked, unit is sun
  2. resourceType — resource type, 0 is “BANDWIDTH” and 1 is “ENERGY”

Returns: N/A

Example:

pragma solidity ^0.8.17;

contract C {
event BalanceFreezedV2(uint, uint);

// unstake 1 TRX staked for energy
function example() external {
unfreezebalancev2(1000000, 1);
emit BalanceUnfreezedV2(1000000, 1);
}
}

cancelAllUnfreezeV2()

Description: cancel all pending unstaking requests. Before calling selfdestruct(address) to destroy the contract, should cancel all pending unstaking requests, otherwise, the contract cannot be destroyed.

Params: N/A

Returns: N/A

Example:

pragma solidity ^0.8.17;

contract C {
event AllUnFreezeV2Canceled();

// cancel all pending unstaking requests and destroy the contract
function killme(address payable target) external {
cancelallunfreezev2();
emit AllUnFreezeV2Canceled();

selfdestruct(target);
}

}

withdrawExpireUnfreeze() returns(uint amount)

Description: withdraw unfrozen TRX, the user can call this API to withdraw funds to account after executing /wallet/unfreezebalancev2 transaction and waiting N days, N is a network parameter.

Params: N/A

Returns: the amount of TRX successfully withdraw, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {
event ExpireUnfreezeWithdrew(uint);

// withdraw unfrozen TRX
function example() external{
amount = withdrawexpireunfreeze();
emit ExpireUnfreezeWithdrew(amount);
}

}

<address payable>.delegateResource(uint amount, uint resourceType)

Description: delegate bandwidth or energy resource to address

Params:

  1. amount — amount of TRX staked for resource to be delegated, unit is sun
  2. resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: N/A

Example:

pragma solidity ^0.8.17;

contract C {
event ExpireUnfreezeWithdrew(uint);

// the contract delegates 1 TRX bandwidth resource share to receiver
function example(address payable receiver) external {
receiver.delegateResource(1000000, 0);
emit ResourceDelegated(1000000, 0, receiver);
}

}

<address payable>.unDelegateResource(amount, resourceType)

Description: cancel the resource delegation for the address

Params:

  1. amount — amount of TRX staked for resource to be undelegated, unit is sun
  2. resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: N/A

Example:

pragma solidity ^0.8.17;

contract C {
event ResourceUnDelegated(uint, uint, address);

// the contract undelegates 1 TRX bandwidth resource share from the receiver
function example(address payable receiver) external {
receiver.unDelegateResource(1000000, 0);
emit ResourceDelegated(1000000, 0, receiver);
}
}

Chain Properties

  • chain.totalNetLimit: total bandwidth provision in the network, the current value is 43,200,000,000
  • chain.totalNetWeight: total TRX staked for bandwidth, the unit is TRX
  • chain.totalEnergyCurrentLimit: total energy provision in the network, the current value is 90,000,000,000
  • chain.totalEnergyWeight: total TRX staked for energy, the unit is TRX
  • chain.unfreezeDelayDays: unstaking waiting time, the unit is DAY

Example:

pragma solidity ^0.8.17;

contract C {

function getChainParameters() view public returns(uint, uint, uint, uint, uint)

{
return (chain.totalNetLimit, chain.totalNetWeight,
chain.totalEnergyCurrentLimit, chain.totalEnergyWeight,
chain.unfreezeDelayDays);
}
}

<address>.availableUnfreezeV2Size() returns(uint)

Description: query the remaining times of executing unstake operation for address

Params:N/A

Returns: remaining times of executing unstake operation

Example:

pragma solidity ^0.8.17;

contract C {
function getvailableUnfreezeV2Size(address target) view public returns(uint) {
return target.availableUnfreezeV2Size();
}
}

<address>.unfreezableBalanceV2() returns(uint amount)

Description: query the unfreezable balance of a specified resourceType for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: unfreezable TRX balance, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {

function getvailableUnfreezeV2Size(address target) view public returns(uint amount) {
return target.unfreezableBalanceV2(1);
}
}

<address>.expireUnfreezeBalanceV2(uint timestamp) returns(uint amount)

Description: query the withdrawable balance at the specified timestamp for address

Params:

  • timestamp — query cutoff timestamp, the unit is secounds

Returns: withdrawable TRX balance, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {

function getExpireUnfreezeBalanceV2(address target) view public returns(uint amount) {
return target.expireUnfreezeBalanceV2(block.timestamp);
}
}

<address>.delegatableResource(uint resourceType) returns(uint amount)

Description: query the amount of delegatable resources share of the specified resourceType for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: delegatable resources share, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {
//query the amount of delegatable resources share of energy for target address
function getDelegatableResource(address target) view public returns(uint) {
return target.delegatableResource(1);
}
}

<address>.resourceV2(address from, uint resourceType) returns(uint amount)

Description: query the amount of resources share of a specific resourceType delegated by from to address

Params:

  • from — resource owner
  • resourceType — Resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: resources share, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {
//query the amount of resources share of energy delegated by a to b
function getResourceV2(address b, address a) view public returns(uint) {
return b.resourceV2(a, 1);
}
}

<address>.checkUnDelegateResource(uint amount, uint resourceTyp) returns(uint available, uint used, uint restoreTime)

Description: check whether the contract can recycle the specified amount of resources share of a specific resourceType that have been delegated to address

Params:

  • amount — resource share, unit is sun
  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: available is the amount of available resource share, the unit sun, used is the amount of used resource share, the unit is sun, restoreTime is the restore time point for the used resources, the unit is seconds

Example:

pragma solidity ^0.8.17;

contract C {

function checkUnDelegateResource(address target) view public returns(uint, uint, uint) {
(uint available, uint used, uint restoreTime) = target.checkUnDelegateResource(1000000, 1);
return (available, used, restoreTime);
}
}

<address>.getResourceUsage(uint resourceTyp) returns(uint used, uint restoreTime)

Description: query the usage of a specific resourceType of resources for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: used is the amount of used resource share, the unit sun,, restoreTime is the restore time point for the used resources, the unit is seconds

Example:

pragma solidity ^0.8.17;

contract C {

function getResourceUsage(address target) view public returns(uint, uint) {
(uint used, uint restoreTime) = target.resourceUsage(1);
return (used, restoreTime);
}

}

<address>.totalResource(uint resourceTyp) returns(uint amount)

Description: query the total available resource share of a specific resourceType for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: the amount of available resource share, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {
//query the available resource share of energy for the target address
function getTotalResource(address target) view public returns(uint) {
return target.totalResource(1);
}

}

<address>.totalDelegatedResource(uint resourceTyp) returns(uint amount)

Description: query delegated resources share of a specific resourceType for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: the amount of delegated resource share, the uint is sun

Example:

pragma solidity ^0.8.17;

contract C {
//query the delegated resource share of energy for the target address
function getTotalDelegatedResource(address from) view public returns(uint) {
return from.totalDelegatedResource(1);
}
}

<address>.totalAcquiredResource(uint resourceTyp) returns(uint amount)

Description: query the acquired resource share of a specific resourceType for address

Params:

  • resourceType — resource type, 0 is BANDWIDTH and 1 is ENERGY

Returns: the amount of acquired resource share, the unit is sun

Example:

pragma solidity ^0.8.17;

contract C {
//query the acquired resource share of energy for the target address
function getTotalAcquiredResource(address target) view public returns(uint) {
return target.totalAcquiredResource(1);
}
}

Summary

Stake 2.0 has fully upgraded the stake mechanism, which improves the flexibility of staking and reduces the complexity of user operations. It also realizes the seamless integration of the stake system and TVM, supporting the execution of stake and resource delegate operations in smart contracts. Stake 2.0 will bring abundant application scenarios to the TRON network, such as decentralized staking, decentralized resource market and other applications. In the new mechanism, the arrival of assets will be delayed for a period of time, which improves the stability of the stake model when the TRX market fluctuates violently, and also helps to build an anticipated future of total network circulation for the network participants.

--

--