TIP-537: Optimize transaction fee consumption logic

[DmytroShalaiev]

TIP: 537
Title: Optimize transaction fee consumption logic
Author: Dmytro Shalaiev ([email protected])
Type: Standards Track
Category: Core
Created: 2023-04-13

Simple Summary

This Tron Proposal describes methods for turning off TRX burn mechanism if resources not enough for transaction. This should improve UX and more accurate predicting of transaction costs.

Abstract

Currently, TRON uses a resource consumption model which is advanced described here in documentation https://developers.tron.network/docs/resource-model#bandwidth-points-consumption

Motivation

One of the main ways of TRON usage is payment processing, whether it is native TPX or other assets. In this industry, it is very important to have a predictable transaction cost. The problem that we faced is that when there are no available resources on the account, to cover them, TRX will burn. This is not always a convenient approach. For example, we have an account to which the user deposits his assets (tokens) and TRX, to pay these tokens out we use a preliminary delegation of resources(BP and ENERGY if needed*) to this account (which is described in Staking 2.0), but due to resources price fluctuations or inaccuracies in the calculations of delegated resources amount, it may happen that the deficiency is covered by the user's TRX, which would like to save and not use, and even worse is when its amount will ultimately not be enough to successfully complete the transaction.

So it will be cool in such situation 'mark' transaction that it should use only available resources (FREE/STAKED/DELEGATED) without existing TRX balance, it is not enough avaliable - REVERT.

Specification

Add disable_trx_burn?: boolean type property to TX data object, that will indicate - Can available TPX be used for burning to cover transaction resource shortage.
If transaction 'marked' as disable_trx_burn and avaliable resources not enought for covering costs - REVERT tx in a standard manner.

Rationale

Adding just one property simplifies the implementation for backward compatibility with the current transaction DTO because it can be optional if needed. And realization not changing the current resource consumption model at all, only disabling the 'last' step to obtain resources - burn TRX.

[DmytroShalaiev]

#533

[WalterBrooks]

I don't think it is necessary to add such a disable trx burn option. First, tron has provide ways to estimate the energy consumption before the transaction, you can check whether the energy is enough in the account before hand. Second, if you don't want to estimate the energy consumption every time, simply set a feelimit with value lower than the energy corresponding trx in the transaction.

The automatic trx burning when energy is insufficient just make the transaction smooth and easy.

[CooperDepp]

I don't think it is necessary to add such a disable trx burn option. First, tron has provide ways to estimate the energy consumption before the transaction, you can check whether the energy is enough in the account before hand. Second, if you don't want to estimate the energy consumption every time, simply set a feelimit with value lower than the energy corresponding trx in the transaction.

The automatic trx burning when energy is insufficient just make the transaction smooth and easy.

But by using some dApps such as a wallet, the feelimit is set by wallet, we can't customize it.

[WalterBrooks]

I don't think it is necessary to add such a disable trx burn option. First, tron has provide ways to estimate the energy consumption before the transaction, you can check whether the energy is enough in the account before hand. Second, if you don't want to estimate the energy consumption every time, simply set a feelimit with value lower than the energy corresponding trx in the transaction.
The automatic trx burning when energy is insufficient just make the transaction smooth and easy.

But by using some dApps such as a wallet, the feelimit is set by wallet, we can't customize it.

I think most wallets provide with detailed information on the signing page, such as TronLink and Metamask. They will provide you with the estimated resource consumption or gas fee before you sign it, and you can simply compare it with the resource balance in your account.

[DmytroShalaiev]

simply set a feelimit with value lower than the energy corresponding trx in the transaction.

(FeeLimit of contract transaction = estimated basic energy consumption * (1 + energy_factor) * EnergyPrice)
feelimit - is not a good option, because I want to operate with all available resources, don't want to limit on EstimatedEnergy of transactions, and besides want to be proved that TRX will not be burned.

On the other hand, if you make payments with a preliminary delegation of resources, there may be such a scenario that you will evaluate them(1) -> generate a transaction for the required amount -> but they may not be enough at the time of the transfer of tokens because the recipient of the funds, for example, withdrew all USDT-tokens and such a transaction will consume more ENERGY then transfer to an account with a no-zero balance(account by at (1) step time).

If I limit it by Fee Limit, then I will deprive myself of the opportunity to use the resources already available on the wallet, and Fee Limit applies only to ENERGY, the same problem with BANDWITH.

[WalterBrooks]

simply set a feelimit with value lower than the energy corresponding trx in the transaction.

(FeeLimit of contract transaction = estimated basic energy consumption * (1 + energy_factor) * EnergyPrice) feelimit - is not a good option, because I want to operate with all available resources, don't want to limit on EstimatedEnergy of transactions, and besides want to be proved that TRX will not be burned.

On the other hand, if you make payments with a preliminary delegation of resources, there may be such a scenario that you will evaluate them(1) -> generate a transaction for the required amount -> but they may not be enough at the time of the transfer of tokens because the recipient of the funds, for example, withdrew all USDT-tokens and such a transaction will consume more ENERGY then transfer to an account with a no-zero balance(account by at (1) step time).

If I limit it by Fee Limit, then I will deprive myself of the opportunity to use the resources already available on the wallet, and Fee Limit applies only to ENERGY, the same problem with BANDWITH.

Well, I think maybe you have misunderstood the feelimit. In fact, (actual energy consumption = estimated basic energy consumption * (1 + energy_factor) ). And feelimit is a parameter you can set any value when you initiate a transaction, just that if the (actual energy consumption) * energy price > feelimit, the transaction will fail.

And the energy in your account is easy to know, if you do not want to burn your trx in any case, you can set the feelimit < or = your energy balance * energy price. In my opinion, the only problem is that in most wallet that support TRON, the feelimit is set by the wallet rather than users. I think if the wallet allows you to set feelimit every time you make a transaction, your problem will be perfectly solved.

[DmytroShalaiev]

Not really, I just want to have a simple mechanism whereby burning can be turned off, for all cases BPs or ENERGY. At the same time, do not limit the transaction in the use of all available resources at the time of its execution.

[CooperDepp]

Not really, I just want to have a simple mechanism whereby burning can be turned off, for all cases BPs or ENERGY. At the same time, do not limit the transaction in the use of all available resources at the time of its execution.

Then can you please explain the scenario a bit? cause I did not get the point you need to forbidden trx burning. You know, for other public chains, they use the native token for gas fee, there is not even an option of using resource.

[IvanKodak]

I have the same problem as Dmytro, I have client wallets to which I delegate resources for transaction execution and I want these wallets not to burn TRX(when tx burns TRX, it's hard to manage client balances on my side), but only use delegated resources for transaction execution. And for example in a situation when the client wallet doesn't have enough resources for broadcasting, the TRON node needs to return an error and I will handle it on my side.
Dmytro's proposal with the disable_trx_burn property for a transaction will allow me to implement my scenario.

If u will have questions, I can explain my opinion in more detail.

[IvanKodak]

@CooperDepp @WalterBrooks

[WalterBrooks]

I have the same problem as Dmytro, I have client wallets to which I delegate resources for transaction execution and I want these wallets not to burn TRX(when tx burns TRX, it's hard to manage client balances on my side), but only use delegated resources for transaction execution. And for example in a situation when the client wallet doesn't have enough resources for broadcasting, the TRON node needs to return an error and I will handle it on my side. Dmytro's proposal with the disable_trx_burn property for a transaction will allow me to implement my scenario.

If u will have questions, I can explain my opinion in more detail.

I see, so basically you mean that you have a delegated address that needs to make multiple transactions and you want it stop when the energy is used up. But still I think the easier way is to let the account check its energy balance whether it's lower than feelimit before making every transaction.

Because resources on TRON is a bonus, stopping TRX burning is against major users benefit. Just imagine that if this proposal is passed, and more and more users stop burning and stake for energy, the cost for getting energy will also increase, and finally increase to the similar cost of burning TRX.

So it seems like stopping burning is what you need right now, but it indeed brings harmful result. I think it is not as good to let wallets be able to allow users to customize the feelimit.

[DmytroShalaiev]

Thanks for reply

[KrisdiaPaul]

Agree with the opinion that trx burning mechanism should not be changed. TRX with advantage over many other popular tokens is its gas token identity. Now, burning is one of most cherish feature of a token. It is not wise to stop the burning feature, otherwise it would be damage to TRX price.

On the other hand, however, the gas fee of ETH transaction could be adjusted by users in wallet. I think this is what TRON can refer to. When the proposal of transaction fee increases, many users encounters the problem that many wallets client not upgrade in time, resulting in failure of transaction. If TRON also allows users to adjust feelimit in wallet, it would be more reliable. Maybe we need another TIP about this.

[CarlChaoCarl]

It is currently not recommended to adjust the trx burning mechanism.
If there are no further ideas, this issue can be closed.