Who pays for a contract call in TRON: resource allocation

On the TRON blockchain, smart contract execution fees are not inherently restricted to the caller. Unlike EVM networks where the initiating transaction account always pays gas, the TRON Virtual Machine (TVM) incorporates a dual-payer resource model governed by two contract-level settings: consume_user_resource_percent and origin_energy_limit.

Understanding these two parameters explains why a USDT TRC-20 sender ends up paying all of the energy, while certain decentralized applications (DApps) and testnet contracts can sponsor execution gas for their users.

The TVM resource allocation hierarchy

When a transaction triggers a smart contract method on TRON, the TVM evaluates resource billing in the following sequence:

Contract Execution Request
            |
            v
Check `consume_user_resource_percent` (0 - 100%)
            |
  +---------+---------+
  |                   |
Caller Portion     Deployer Portion (100 - X%)
  |                   |
  |                   v
  |         Check deployer `origin_energy_limit` & balance
  |                   |
  |         +---------+---------+
  |         |                   |
  |     Sufficient         Exhausted
  |         |                   |
  v         v                   v
Caller   Deployer            Fallback:
Energy   Energy              Billed to Caller

1. Deployer sponsorship ratio (consume_user_resource_percent):
   • If set to 100, the caller pays all energy.
   • If set to 0, the contract creator pays 100% of the energy, provided the creator has available resources.
   • If set between 1 and 99, execution energy is split proportionally between caller and creator.
2. Deployer energy ceiling (origin_energy_limit):
   • The most energy the creator contributes to a single call. Above it, the caller pays the rest.
3. Fallback to caller:
   • If the deployer’s staked energy pool is exhausted or exceeds origin_energy_limit, the TVM bills the remaining deficit to the caller. If the caller also lacks energy and liquid TRX, the transaction reverts with OUT_OF_ENERGY.

Practical implications for developers

• USDT: the creator’s share is set (70%) but not funded, so senders pay all of it: they need energy or TRX.
• Gasless user onboarding: DApp builders can stake TRX on their deployer address and set consume_user_resource_percent = 0 to cover their callers’ energy, up to origin_energy_limit per call (callers still pay bandwidth).

To simulate contract resource splits, test your calls on Nile using our guide on testing contract energy on Nile.