Paying for resources & Energy sharing

This page covers two things every TRON developer should understand. The first is the TRX burn fallback — what the network does when an account's Bandwidth or Energy is insufficient, and at what rate. The second is deployer Energy sharing — TRON's mechanism for letting a smart contract's deployer pay part of the Energy cost on behalf of the caller. The deployer share has no equivalent in Ethereum-style fee models, where the caller always pays 100% of gas, and it's one of the more useful tools available to DApp builders on TRON.

📘

Prerequisites

• Resource Model
• Bandwidth and Energy

---

TRX burn rates

When Bandwidth cannot be paid from a quota that covers the full transaction, or when the caller-side Energy cost exceeds the caller's available Energy, the network burns TRX from the sender's balance at the following rates:

Both rates are themselves chain parameters and can be changed by proposal — getTransactionFee (parameter #3) for Bandwidth and getEnergyFee (parameter #11) for Energy. Always query wallet/getchainparameters for current values.

A typical 270-byte TRX transfer with no single Bandwidth quota large enough burns 270 × 1,000 = 270,000 sun = 0.27 TRX. For example, 200 staked Bandwidth and 100 free Bandwidth cannot be combined to pay for that transaction; the network burns TRX for all 270 Bandwidth.

Charging order

Standard Bandwidth payment order

Except for special payment rules such as account creation and TRC-10 issuer sponsorship, a transaction's Bandwidth is normally paid in this order:

1. First, use the account's Bandwidth obtained through its own stake or incoming resource delegations.
2. If the Bandwidth obtained through staking or incoming delegations cannot cover the transaction in full, try the account's free Bandwidth, currently 600 Bandwidth.
3. If free Bandwidth also cannot cover the transaction in full, burn TRX for the transaction's full Bandwidth requirement.

Each method must be able to cover the transaction's full Bandwidth requirement on its own. The network does not combine payment methods or burn TRX only for the portion that a quota does not cover. On Mainnet, getTransactionFee is currently 1,000 sun per Bandwidth, or 0.001 TRX.

Free Bandwidth is available only when both the account's remaining free quota and the network-wide shared free-Bandwidth quota can cover the transaction in full.

Account creation special case

An AccountCreateContract, or a direct TRX or TRC-10 transfer to an unactivated address, incurs an account creation fee of 1 TRX on Mainnet (getCreateNewAccountFeeInSystemContract, currently 1,000,000 sun). Free Bandwidth cannot be used for these transactions. The network first tries to deduct transaction Bandwidth × getCreateNewAccountBandwidthRate from the sender's Bandwidth obtained through staking or incoming resource delegations; the current Mainnet multiplier is 1. If that Bandwidth cannot cover the full amount, none of it is consumed and the network burns the fixed getCreateAccountFee, currently 0.1 TRX, in addition to the account-creation fee.

Contract activation. When a smart contract transfers TRX or a TRC-10 token to an unactivated address, the transfer activates the recipient automatically. This path does not charge the 1 TRX account-creation fee above. The outer transaction also does not use the account-creation-specific Bandwidth charging method, so the fixed 0.1 TRX charge represented by getCreateAccountFee does not apply.

The network still charges the initiating account for the outer transaction's Bandwidth in the standard order. If neither its Bandwidth obtained through staking or incoming delegation nor its free Bandwidth can cover the transaction in full, the network burns outer transaction Bandwidth requirement × getTransactionFee in TRX. The internal transfer itself does not incur a separate Bandwidth charge.

Creating the account adds 25,000 to the base Energy cost of the relevant TVM call. This value is a protocol implementation constant, not a chain parameter.

For full account activation details, see Accounts and keys.

TRC-10 issuer-sponsored Bandwidth

When a non-issuer transfers a TRC-10 token to an activated account, the network first tries to pay for the transaction with Bandwidth that the issuer obtained through staking or incoming resource delegations. Sponsorship applies only when the sender's remaining sponsorship allowance for that token, the token's remaining shared sponsorship allowance for all non-issuer transfers, and the issuer's available Bandwidth can each cover the transaction in full. Otherwise, the sender pays according to the standard payment order.

A transfer to an unactivated address follows the account-creation rules and is not eligible for issuer sponsorship.

Energy payment order

The contract settings first determine the deployer's share, subject to the deployer's limit and available staked or delegated Energy. The caller covers the remainder with staked or delegated Energy first and then a TRX burn. The caller's combined Energy usage is capped by the budget derived from fee_limit.

The Energy charging order introduces a participant the Bandwidth side does not have: the contract's deployer, who can choose to absorb part of the cost on behalf of every caller. This is the deployer Energy sharing mechanism described next.

---

Deployer Energy sharing

When a smart contract is deployed, its consume_user_resource_percent field decides how the Energy cost of every call into that contract is split between the caller and the deployer:

Most contracts default to 100. DApps that want to subsidize their users can set the value lower. The deployer's actual contribution is the smallest of its configured share of the call's Energy, the contract's origin_energy_limit, and the deployer's available staked or delegated Energy. Any remaining Energy is charged to the caller.

Why this matters for DApp builders

Ethereum-style fee models give the caller no choice: they hold the gas token, they pay every wei of gas. TRON's deployer share lets a DApp operator change that economic relationship from the contract side, without a relayer, paymaster, or off-chain account abstraction wallet.

A few patterns this enables:

• Subsidized onboarding. Setting consume_user_resource_percent = 0 assigns the full Energy cost to the deployer, within the contract's origin_energy_limit and the deployer's available staked or delegated Energy. Callers still need enough resources or TRX to cover any remainder and the transaction's Bandwidth cost.
• DEX, AMM, and operator-deployed contracts. A DApp team that owns and deploys its core contracts can set the percent to 0 to subsidize the Energy cost of the DApp's main flows. For calls to contracts you do not control — such as a wallet interacting with a third-party TRC-20 contract — use resource delegation instead, since only the contract's deployer can change its consume_user_resource_percent.
• Tiered subsidies via stake budgeting. The deployer's Energy stake is a finite, refilling pool. Once exhausted within a 24-hour cycle, additional calls fall back to caller-pays. Sizing the deployer stake to expected early-adopter volume creates a natural "free for the first N calls per day" tier without writing per-user logic in the contract. Combine with allow-lists or NFT gating in the contract for finer-grained eligibility.
• Gaming and NFT DApps. Setting the percent low (often 0–30) lets the deployer absorb the Energy cost of frequent on-chain actions like state writes, mints, and in-game item transfers. Players get a Web2-like experience because their wallet does not prompt them to top up TRX on every move.
• Migrating a subsidized Ethereum flow. If your existing Ethereum design uses a relayer (GSN) or paymaster (EIP-4337) to subsidize users, consume_user_resource_percent = 0 provides a contract-level subsidy on TRON. It is not an unconditional gasless guarantee: the caller covers any Energy beyond the deployer's limits and still pays the transaction's Bandwidth cost.

How to configure

The deployer can update consume_user_resource_percent after deployment via wallet/updatesetting. Only the deployer's account can call this. Once the update transaction takes effect, the node reads the then-current on-chain setting when it executes a later contract call. Entering the mempool does not lock an earlier setting into that transaction.

The deployer must set a sufficient origin_energy_limit and keep enough staked or delegated Energy to cover the intended share. If either limit is insufficient, the remainder is charged to the caller, using the caller's available Energy first and then burning TRX within the transaction's fee_limit.

Worked example

Suppose a contract call requires 80 Energy, the contract is configured with consume_user_resource_percent = 60, the caller has 100 Energy available, the deployer has 10 Energy available, and the Energy price is 100 sun.

1. Split the cost. Caller's theoretical share is 60% × 80 = 48 Energy. Deployer's theoretical share is 32 Energy.
2. Deployer contribution is limited. The deployer can supply 10 of the assigned 32 Energy.
3. Caller covers the remainder. The caller is responsible for 80 − 10 = 70 Energy. Because the caller has 100 Energy available, 70 Energy is consumed and no TRX is burned.

Total: the deployer consumes 10 Energy and the caller consumes 70 Energy. No TRX is burned. Because fee_limit caps the caller's total Energy budget — including available Energy, not just the TRX-burn portion — it must still cover at least 70 × 100 = 7,000 sun for this example.

---

fee_limit (caller-side Energy budget cap)

Every state-changing smart contract transaction includes a fee_limit field — the caller-side Energy budget for the call, in sun. It caps the total Energy the caller may use for the call (see FeeLimit & Energy cost for the exact conversion). The chain parameter getMaxFeeLimit caps the maximum value fee_limit can take (currently 15,000,000,000 sun = 15,000 TRX, query wallet/getchainparameters for current).

If the caller's Energy usage would exceed the budget implied by fee_limit, the transaction reverts with OUT_OF_ENERGY; Energy already consumed is still charged up to that limit. This protects callers from runaway loops, unbounded recursion, and contracts that fail in expensive ways.

fee_limit caps the caller's total Energy budget — Energy drawn from the caller's available quota as well as the TRX-burn portion, not just the TRX burn. The deployer's actual contribution is added separately. If the deployer cannot cover the configured share, the caller covers the shortfall within the same caller-side fee_limit budget, using available Energy before TRX is burned.

For sizing guidance — typical fee_limit values for common contract operations, the relationship between fee_limit and EVM gasLimit, and edge cases around fee_limit interaction with revert paths — see FeeLimit & Energy cost.

Dynamic Energy Model

Some contracts — popular DEXes, stablecoin contracts — are called frequently enough to create uneven load. The dynamic Energy mechanism raises the effective Energy cost of heavily-used contracts so the network can shed load without asking everyone to pay more.

The mechanism is governed by these chain parameters:

When a contract's recent Energy consumption exceeds DynamicEnergyThreshold, its effective Energy cost is multiplied by a factor between 1× and 1 + DynamicEnergyMaxFactor / 10,000 (currently 1 + 3.4 = 4.4×). The factor steps up gradually, capped at the maximum, and decays when usage drops.

---

Related resources

• Bandwidth and Energy — How both resources work and how to obtain them
• FeeLimit & Energy cost — fee_limit sizing and EVM gasLimit comparison
• Resource Model — Three-resource overview
• TVM — TRON Virtual Machine and per-instruction Energy costs
• Network parameters — Resource-fee parameters and how to query their current values
• wallet/updatesetting — Update consume_user_resource_percent for a deployed contract