Enable Conversion between Energy and Bandwidth in Stake 2.0

[neuscala]

Simple Summary

In order to improve user experience and resource flexibility on the TRON network, it is recommended to introduce a new transaction type that allows direct conversion between Energy and Bandwidth resources in Stake 2.0, without the need for unstaking and re-staking TRX.

Motivation

Following the implementation of Stake 2.0, the demand for resources on the TRON network has been continuously increasing.

Under the current Stake 2.0 mechanism, users can only perform staking and unstaking operations. According to proposal #70, the lock-up period for unstaked assets is set to 14 days. This means that if a user wants to change their resource type (e.g., from bandwidth to energy), they must first unstake the TRX, wait through the 14-day lock-up period, and then re-stake the TRX to obtain energy. This process is highly inconvenient for users and leads to inefficient resource allocation on the network.

Therefore, we need to introduce a new transaction type that allows users to directly exchange between Energy and Bandwidth resources without going through the unstaking process, making resource management more convenient and flexible for all users.

Background

Here is the daily transaction volume for staking and unstaking operations on the TRON network:

As shown in the chart above, the TRON network processes approximately 3,000 to 5,000 staking and unstaking transactions daily. With each unstaking operation requiring a 14-day waiting period, a lot of TRX remains locked in this transition state.
This inefficiency creates several problems:

• Resource Underutilization
• Poor User Experience
• Network Contribution Loss

By implementing the proposed direct exchange mechanism between Energy and Bandwidth, TRX could be converted to another active resource rather than sitting idle in the unstaking queue.

Specification

Propose to add a new transaction type and a new opcode that enable direct resource exchange.

• Add a new transaction type ExchangeResourceContract.
• Add a new opcode EXCHANGERESOURCE to TVM.

Compatibility

This proposal is fully compatible with the existing Stake 2.0 system and does not require any changes to it.

[brooklynn1212]

This proposal enhances the efficiency of TRX staking by eliminating the staking waiting period, which greatly benefits TRX staking users.

[ferdinand026]

I have been looking forward to this feature. Finally, I can flexibly switch resources at any time according to my needs. Otherwise, I really would not do this because 14 days is too long.

[Bellgin]

I understand why there is a lock period, but 14 day is too long. Glad to see the model is tending to be more flexible. Besides this feature, is there any proposal to adjust the lock period either?

[angrynurd]

I would like to know whether this proposal has assessed the potential impacts(positive and negative) on participants within the existing staking system, including:Stakers, Super Representatives (SRs), Exchanges, DApp developers, and other relevant stakeholders.

[Jake151987]

Just wondering one thing, when performing such a conversion, is there a quantitive parameter that indicates how much energy or bandwidth would be converted? Or is the conversion designated to a particular staking operation done before, therefore, all the energy or bandwidth obtained by that staking operation would be converted to another?

[neuscala]

I would like to know whether this proposal has assessed the potential impacts(positive and negative) on participants within the existing staking system, including:Stakers, Super Representatives (SRs), Exchanges, DApp developers, and other relevant stakeholders.

Thanks for your reminder.
As this proposal does not modify existing mechanisms but rather adds a new resource conversion option for users:

For Super Representatives, it may increase the total amount of staking, as users will be more willing to participate in staking.
For stakers, exchanges, and dapp developers, it reduces the waiting time for resource reconfiguration and improves TRX utilization efficiency.

However, there might also be some potential impacts:

Direct resource conversion could make the unit cost of bandwidth and energy by staking TRX more dynamic.
I believe it's necessary to consider adding a minimum conversion interval to prevent excessively frequent resource switching.

Overall, this proposal aims to improve the efficiency and flexibility of resource allocation on the TRON network and is expected to bring positive impacts to all ecosystem participants.

[neuscala]

Just wondering one thing, when performing such a conversion, is there a quantitive parameter that indicates how much energy or bandwidth would be converted? Or is the conversion designated to a particular staking operation done before, therefore, all the energy or bandwidth obtained by that staking operation would be converted to another?

In my view, allowing users to specify the amount of TRX they wish to convert is the better option. This approach offers more flexibility compared to an "all-or-nothing" conversion method.
If you have any alternative suggestions, welcome discussing them together.

[Murphytron]

I have noticed several requests of shifting the resource type without unstaking from the community, and glad to have this TIP. This proposal will truly increase the convenience, but I think these aspects should be taken into consideration:

1. The frequent shift may cause unnecessary risk, and it's better to limit the frequency such as once per 14 days at the most.
2. The giant stakers may have drastic impact on resource distribution and influence. It's better to enable users to specify the ratio of staking amount. And also limit the maximum resource can be converted of an address per day, or limit the maximum resource can be converted of the whole network per day.
3. It would be better to make it predictive of resources cost in the near future, to help DEX, CEX and other dApps to assess their resource in advance.

[sYNCHROtime]

How is the effective time of resource conversion determined?

[lxcmyf]

@neuscala
Can the staked converted resources be delegated resources? For example, can resources delegated by others for the current account be converted? Or can we only convert the available resources that we have already staked?

[neuscala]

@neuscala Can the staked converted resources be delegated resources? For example, can resources delegated by others for the current account be converted? Or can we only convert the available resources that we have already staked?

Under the current Stake 2.0, I propose that an account should only be able to convert resources directly obtained through its own staking, not resources that have been delegated to it.

This design approach offers better traceability and management for the original account's resources. Resource conversion would inherently come with certain constraints, such as frequency limits. For instance, if an account delegates its energy to another account and later receives bandwidth back, but cannot immediately convert it back to energy, the account would face significant inconveniences in resource utilization.

By maintaining this approach, we ensure that resource management remains transparent, controllable, and aligned with the original staking intentions of the account holder.

[neuscala]

How is the effective time of resource conversion determined?

To balance network stability and user operational flexibility, I think a shorter waiting period would be introduced (e.g., 1-7 days) compared to the current 14-day unstaking lock-up.

From another perspective, we could also limit the frequency of resource exchange, for example, to once every 14 days.

These proposals are still under discussion.

[lxcmyf]

@neuscala
Attention should be paid to the mutual conversion between resources, which will affect totalNetWeight and totalEnergyWeight. Also, do resources that are already in the process of being de staked support conversion?