Every TRON transaction costs something. When a wallet’s fees are being paid by someone else — through delegated Energy, delegated Bandwidth, or recurring TRX top-ups sized to cover fallback burns — that payment is an act of deliberate, sustained operational commitment. Understanding who is paying, and why, is one of the sharpest lenses available in a TRON attribution investigation.
This article covers the resource model in brief, the two forms external fee payment takes, why each is a strong ownership signal, the one exception that neutralizes the signal, and how TRONORIGIN weighs the evidence.
What “fueling” means on TRON
TRON uses two resources to price transaction execution: Bandwidth and Energy.
Bandwidth is consumed by every transaction, priced by transaction byte size. A simple TRX transfer consumes a small fixed amount. Energy is consumed only by smart contract execution — any call into the TRON Virtual Machine, including a standard USDT transfer. Energy cost scales with computational complexity.
Both resources can be obtained in two ways. First: stake TRX and receive a proportional share of the daily resource pool — 43.2 billion Bandwidth units per day and 180 billion Energy units per day, distributed proportionally to stakers. Second: do nothing and let TRON burn TRX from the transacting wallet’s balance as a fallback fee. Bandwidth burns at 0.001 TRX per unit; Energy at 0.0001 TRX per unit.
This architecture means every address that executes transactions regularly is either staking TRX, burning TRX, or being subsidized by someone who is. On Ethereum, fees always burn from the sender’s own account — the attribution question does not arise. On TRON, a third party can transparently cover another address’s transaction costs, and the on-chain record captures exactly who that third party is.
That is what “fueling” means in investigative terms: the pattern of external resource provision that keeps a wallet operating without its holder needing to fund its own fees.
Two kinds of fueling
Both forms of fueling attribute ownership. They differ in mechanism and in the strength of the signal each produces.
Resource delegation
DelegateResourceContract (contract type 57) is a Stake 2.0 transaction in which one address — call it the operator — explicitly assigns a portion of its staked Energy or Bandwidth to a specific recipient address. The recipient’s transactions then consume those resources instead of burning TRX from the recipient’s own balance. When the operator withdraws the delegation, UnDelegateResourceContract (type 58) records that act as well.
Both events are on-chain. Both name the delegating address and the recipient explicitly. The delegation must be renewed actively — each renewal is a fresh on-chain commitment. This is the cleaner ownership signal of the two: the mechanism was built for exactly this use case, operational management of dependent addresses.
Direct fee provision
Some wallets are fueled through TRX transfers rather than resource delegation. The pattern: a wallet receives a small TRX deposit, executes one or more smart contract calls that burn TRX as fallback Energy, and then receives another small deposit just before the next batch of transactions. The deposit amounts are sized to match the expected burn.
This is less clean than delegation as a signal because the TRX transfer itself is not tagged with intent — it looks like any other transfer. But the pattern becomes identifiable when it repeats: same source, predictable timing relative to outbound activity, amounts consistent with fee burn rather than commercial exchange. The source of the recurring top-ups is the fee provider, and that relationship points to the same conclusion as resource delegation.
TRONORIGIN’s V3.3 Fee Provider Detection looks for origin_energy_usage > 0 in transaction receipts (indicating energy was provided by a delegator) and also identifies when a consistent external address appears as fee payer for two or more transactions — the minimum threshold for distinguishing an operator from a one-time helper.
Why this is the strongest ownership signal available
Resource delegation requires a specific, deliberate, repeatable decision. The operator froze TRX, received resources, and directed those resources at a particular address. Every re-delegation is a new commitment. The cost is real: delegated resources are unavailable for the operator’s own transactions during the delegation period.
No exchange performs this for individual users. Binance processes millions of customer accounts — per-user Energy delegation would require a separate, continuously maintained staking position for each active customer. No centralized exchange does this. The only addresses that delegate Energy to individual wallets are those with a specific operational reason: managing an address they own, covering a counterparty’s costs, or running a working wallet in the field.
The asymmetry is what makes the signal valuable. Exchange-funded wallets, faucet-activated wallets, and airdrop recipients all look similar from a first-sender perspective — the infrastructure address came first. Resource delegation is different in kind: an exchange never delegates; a personal or operational wallet delegates only to addresses it controls.
TRONORIGIN’s scoring reflects this: resourceDelegationBonus = +50, the highest single-factor bonus in the system, and classified as a “definitive signal” alongside AccountCreateContract — overriding confidence reductions from mixer involvement or address-poisoning indicators.
The fee provision bonus (+40) follows the same logic at slightly lower weight: recurring fee payment is a strong indicator but lacks the on-chain specificity of a named DelegateResourceContract.
Energy marketplaces — the third-party fueling exception
There is one class of entity that delegates Energy commercially to many unrelated addresses: energy rental marketplaces. These are legitimate services that accept payment and return Energy delegation — a direct transaction, not an ownership signal.
Feee.io (TYukBQZ2XXCcRCReAUguyXncCWNY9CEiDQ) is the primary example on TRON. Users pay a small TRX or USDT fee through the platform and receive Energy delegation in return, typically sized to cover one or more USDT transfers at substantially lower cost than burning TRX directly. Feee.io cuts transfer costs by up to 88% compared to direct fee burn. It appears in many wallets’ transaction histories because it is one of the cheapest ways to execute a USDT transfer on TRON.
JustLend Energy Rental operates differently: it is an on-chain decentralized protocol rather than a centralized platform. Users specify a rental amount, duration (up to 30 days), and receiving address; the protocol pools staked TRX from lenders and delegates the corresponding Energy to the specified recipient. The “one-to-many” model means a single rental operation can fund multiple addresses simultaneously. JustLend is more suited to high-volume DeFi users and operators who want on-chain, counterparty-free rental terms; Feee.io is simpler for retail users sending individual USDT transfers.
Both appear in TRONORIGIN’s allowlist as SERVICE / ENERGY_MARKETPLACE. When a delegation from an allowlisted marketplace address is detected, the system treats it neutrally — the marketplace was paid for a commercial service, not expressing operational control. The signal is filtered out before scoring.
The practical implication: a wallet that uses Feee.io to cover USDT transfers is not linked to Feee.io’s address in any ownership sense. The relevant question is whether any other address in the history is delegating resources outside the marketplace allowlist.
What it looks like on-chain
On Tronscan, delegation events appear as contract type 57 and undelegation events as type 58. Each names the delegating address in owner_address and the recipient in receiver_address. The resource field reads ENERGY or BANDWIDTH.
The recurring pattern: address A delegates to B (type 57); B executes USDT transfers consuming that Energy; after some period A undelegates (type 58); shortly before B’s next active window A re-delegates. The re-delegation is timed to B’s operational needs — not to market conditions or batch purchase orders — which distinguishes a personal operator from a marketplace. An energy marketplace delegates to many addresses with uniform timing driven by customer orders. A personal operator delegates to one address, when it needs resources, in amounts sized to its workload.
The direct-fee-provision variant is less visually distinct: address A sends small TRX transfers (0.5–5 TRX) to B just before B executes smart contract calls. The transfers are TransferContract (type 1) with no special tagging, but the timing and sizing make the pattern legible once you are looking for it.
How TRONORIGIN scores it
In TRONORIGIN’s signal-weight hierarchy, resource delegation ranks second overall, behind only the combined return-flow signals:
| Rank | Signal | Max Points |
|---|---|---|
| 1 | Return flow (all components combined) | +79 |
| 2 | Resource delegation | +50 |
| 3 | Fee provision | +40 |
| 4 | AccountCreateContract | +100 (definitive) |
Resource delegation and AccountCreateContract are the two signals TRONORIGIN classifies as “definitive” — meaning they can override confidence reductions from mixer involvement or address-poisoning indicators. A wallet whose origin candidate has delegated Energy to it will reach High confidence even in otherwise noisy data.
The fee provision bonus (+40, V3.3) applies only when hasResourceDelegation = false for that candidate, preventing double-counting. It requires at least two confirmed fee-payment events to avoid false positives from one-time Bandwidth covers.
Both signals feed primarily into Phase 3 (current control, 50% weight) of the three-phase scoring model. The reason is straightforward: resource delegation and fee provision are ongoing operational acts, not historical ones. They tell you who is managing the wallet now, which is the question Phase 3 is designed to answer. See /how-it-works/ for the full three-phase breakdown.
The OPERATIONAL_FUNDER behavioral tag is applied to any candidate exhibiting delegation, fee provision, or strong return flows — flagging them explicitly as the active operational controller as distinct from the GENESIS_FUNDER (whoever first activated the wallet, which may be an exchange).
A worked example
Wallet B was activated nine months ago by a Binance hot wallet. Binance earns GENESIS_FUNDER and a first-sender bonus (+10); its category score is neutral under V4.2.
Two days after activation, address A — a personal wallet created eighteen months ago — delegated 65,000 Energy units to B. A re-delegated three more times, each time shortly before B’s next active period. B also sent three dust-amount TRX returns to A within 24 hours of each top-up.
Candidate A’s score:
- Category (PERSONAL): +10
- First sender: 0 (Binance was first)
- Interactions (7 events): ~+16
- Resource delegation: +50
- Return flow (same-day, dust, ×3): +25 + 10 + 24
- Amount and established funder: +15
Total ≈ 150 points. Binance scores ≈ 27. A dominates the normalized percentage; confidence band is High; stability is HIGH (definitive delegation signal). Output: A receives OPERATIONAL_FUNDER; Binance receives GENESIS_FUNDER; Phase 3 and Phase 1 leaders agree, no takeover flag.
For the resource model mechanics — how staking generates Energy and Bandwidth, what Stake 2.0 changed, and the full delegation contract structure — see /learn/stake-2/.
Sources
- TRON Developer Hub. “Resource Model” — Bandwidth and Energy mechanics, free daily Bandwidth allocation (600 units), fallback TRX burn rates (0.001 TRX/Bandwidth unit; 0.0001 TRX/Energy unit), daily resource pool sizes (43.2 billion Bandwidth; 180 billion Energy).
- GitHub: tronprotocol/protocol. “core/Tron.proto” — ContractType enum; DelegateResourceContract = type 57, UnDelegateResourceContract = type 58. Authoritative TRON protocol definition.
- tronprotocol GitHub. “System Contracts” — Canonical list of TRON system contract types including DelegateResourceContract and UnDelegateResourceContract.
- Feee.io. “TRON Energy Exchange” — Commercial Energy rental platform; delegates Energy to purchasing addresses; up to 88% fee reduction vs TRX burn. Catalog-allowlisted address:
TYukBQZ2XXCcRCReAUguyXncCWNY9CEiDQ. - JustLend DAO Documentation. “Energy Rental” — On-chain decentralized Energy rental protocol; one-to-many model; security deposit and refund mechanics; up to 30-day rental periods.
- TRONORIGIN Heuristic Specification (HEURISTIC_SPEC.md, v5.1.0) — Internal project document:
resourceDelegationBonus = +50,feeProviderBonus = +40, signal-strength ranking table, definitive signal classification, Phase 3 weighting (50%),OPERATIONAL_FUNDERandGENESIS_FUNDERtag definitions, marketplace allowlist handling. - TRONORIGIN E2E Address Catalog (
tronorigin-app/e2e/addresses/catalog.ts) —energy-marketplacealias:TYukBQZ2XXCcRCReAUguyXncCWNY9CEiDQ, categorySERVICE, expected tagENERGY_MARKETPLACE, expected confidence bandHigh.