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 stake plus free quota are insufficient, the network burns TRX from the sender's balance at fixed rates:

Resource	Burn rate	TRX equivalent
Bandwidth	1,000 sun per byte	0.001 TRX per byte
Energy	100 sun per Energy	0.0001 TRX per Energy

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 Bandwidth available burns 270 × 1,000 = 270,000 sun = 0.27 TRX.

Charging order

The network consumes Bandwidth and Energy in a fixed order, falling back to a TRX burn only after preconfigured stake (and the free quota for Bandwidth) is exhausted:

Bandwidth. Staked Bandwidth → free 600/day quota → TRX burn at 1,000 sun per byte.
Energy. Caller's staked Energy (up to the deployer-configured share) → deployer's staked Energy (for the remaining share) → TRX burn from the caller, capped by 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:

`consume_user_resource_percent`	Meaning
`0`	Deployer pays 100% of Energy (caller pays nothing)
`100`	Caller pays 100% of Energy (Ethereum-style behavior)
`30`	Caller pays 30%, deployer covers 70%

Most contracts default to 100. DApps that want to subsidize their users set the value lower, so the deployer's staked Energy absorbs part — or all — of the per-call cost.

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:

Frictionless onboarding. A user with an activated TRON account already has 600 free Bandwidth per day — enough for several typical contract calls. Setting consume_user_resource_percent = 0 removes the Energy cost as well, so users can interact with the DApp without holding TRX for ongoing fees beyond the one-time account activation. Note that the deployer share covers Energy only; Bandwidth still comes from the caller's free quota or stake.
DEX, AMM, and operator-deployed contracts. A DApp team that owns and deploys its core contracts can set the percent to 0 on those contracts, presenting a zero-Energy-fee experience for the DApp's main flows while keeping standard on-chain settlement. For absorbing fees on counterparty contracts you do not control — such as a wallet bridging to a TRC-20 stablecoin — 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 an Ethereum gasless flow. If your existing Ethereum design uses a relayer (GSN) or paymaster (EIP-4337) to give users a gasless experience, set consume_user_resource_percent = 0 on the TRON deployment to achieve a comparable result without running a relayer or paymaster service. Users still sign and submit their own transactions directly — the off-chain meta-transaction pattern is not needed.

How to configure

The deployer can update consume_user_resource_percent after deployment via wallet/updatesetting. Only the deployer's account can call this. The new value applies to all subsequent calls; in-flight calls already in the mempool use the old value.

The deployer must keep enough staked Energy to cover the share they have promised. If the deployer's staked Energy runs out, the unpaid portion silently falls through to the caller's TRX burn — so over-promising and under-staking is a common foot-gun.

Worked example

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

Split the cost. Caller's theoretical share is 60% × 80 = 48 Energy. Deployer's theoretical share is 32 Energy.
Caller pays. The caller has 30 Energy staked, covering 30 of the 48. The remaining 18 falls to a TRX burn: 18 × 100 = 1,800 sun.
Deployer pays. The deployer has only 10 of the required 32 Energy. The 22-Energy shortfall falls back to the caller's TRX burn: 22 × 100 = 2,200 sun.

Total: caller is charged 30 Energy (from stake) plus 1,800 + 2,200 = 4,000 sun (from balance). The deployer's 10 Energy is consumed.

If the caller's fee_limit is below 4,000 sun, the transaction reverts.

fee_limit (per-transaction Energy burn cap)

Every smart contract transaction includes a fee_limit field — the maximum TRX (in sun) the network may burn for the call's Energy cost. 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 actual TRX burn would exceed fee_limit, the transaction reverts. 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 only governs the caller's TRX burn. The deployer's portion of the Energy cost is paid from the deployer's stake; if the deployer can't cover it, the unpaid Energy becomes additional TRX burn against fee_limit (as in the worked example above).

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:

Parameter	API key	Current value	Role
`#72`	`getAllowDynamicEnergy`	1	Master switch (enabled)
`#73`	`getDynamicEnergyThreshold`	5,000,000,000	Energy usage threshold for activation
`#74`	`getDynamicEnergyIncreaseFactor`	2,000	Per-window cost increase (units of 1/10,000)
`#75`	`getDynamicEnergyMaxFactor`	34,000	Maximum multiplier (units of 1/10,000)

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

Account creation special case

Activating a new account incurs a fixed 1 TRX account creation fee (getCreateAccountFee chain parameter, currently 1,000,000 sun) on top of the normal Bandwidth cost of the activating transaction. If the activating account also has insufficient Bandwidth, an additional 0.1 TRX is burned to cover the Bandwidth shortfall.

Activating an account through a smart contract call costs an extra 25,000 Energy on top of normal execution costs.

For full account activation details, see Accounts and keys.

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 — Full list of fee-related chain parameters
wallet/updatesetting — Update consume_user_resource_percent for a deployed contract