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 does not score direct fee provision as a separate signal. TRON’s transaction records expose no fee-payer address — a top-up is just a TransferContract — so the recurring deposits surface as ordinary transfers in the funding history, where they strengthen the sender’s record like any other repeated funding. Reading the timing-and-sizing pattern on top of that history is investigator work. What the engine does verify on the resource side is consumption: transaction receipts show when the target executed on free, delegated Energy rather than burning its own TRX, which corroborates an active delegation (more on this below).
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: resource delegation is among the strongest single factors in the system — the leading behavioral indicator in the current-control fallback, and strong evidence on the origin side as well — though only AccountCreateContract is classified as a “definitive signal,” exempt from the confidence caps applied when the origin phases disagree or when the account is too young for its evidence windows to corroborate independently. Mixer or poisoning involvement still reduces confidence for any candidate, definitive signal or not.
Direct fee provision follows the same investigative logic but is not separately scored: recurring fee payment lacks the on-chain specificity of a named DelegateResourceContract, so the top-ups enter the analysis as ordinary transfers in the funding history, and the pattern reading stays with the investigator.
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 near the top, behind only the combined return-flow signals:
| Rank | Signal | Relative strength |
|---|---|---|
| 1 | Return flow (all components combined) | Strongest cumulative |
| 2 | Resource delegation | Strong |
| 3 | Sponsored energy use (corroborates delegation) | Corroborating |
| — | AccountCreateContract | Definitive (genesis) |
AccountCreateContract is the one signal TRONORIGIN classifies as “definitive” for the origin question — meaning the candidate is exempt from the confidence caps applied when the origin phases disagree or when the account is too young for its evidence windows to corroborate independently. It does not neutralize risk reductions: mixer or poisoning involvement still lowers confidence for any candidate. Resource delegation remains strong evidence on both axes, but it is not treated as definitive on its own: an active delegation is the leading behavioral indicator in the current-control fallback, while a controlling permission key settles the controller question outright.
Sponsored energy use is delegation’s corroborating companion, not a standalone signal: when the target’s transaction receipts show it executed on free, delegated Energy — energy consumed with no fee burned — a non-marketplace candidate holding an active Energy delegation earns additional credit. The receipts show the wallet is actually running on free Energy rather than burning TRX — consistent with the delegation being used, though the free Energy could also be self-staked, which is why this only corroborates and never stands alone.
Both scored signals — active delegation and the sponsored-energy-use corroboration — are first and foremost current-control evidence. The reason is straightforward: delegating resources, and running on them, are ongoing operational acts, not historical ones. They tell you who is managing the wallet now — and that question is answered rule-first from the wallet’s permission evidence, with behavioral signals like these serving as the fallback when no key evidence exists. They do not feed the origin shares as control signals, though sustained delegation also strengthens a candidate’s funding-history record on the origin side. See /how-it-works/ for the full breakdown.
The OPERATIONAL_FUNDER behavioral tag is applied to any positively-scoring control candidate holding an active resource delegation or a permission key — 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 the small first-sender bonus; its category score is neutral.
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 strength comes from several signals stacking together:
- PERSONAL category — a positive baseline
- First sender — none (Binance was first)
- Repeated interactions across seven events
- Resource delegation — the strongest single signal present
- Return flows — three same-day dust returns, the strongest of which weigh most heavily
- Normal transfer amounts and established-funder standing
Resource delegation is decisive on its own; combined with the return flows and category, A vastly outscores Binance, whose only credits are the neutral category and the first-sender bonus. A dominates the normalized percentage; confidence band is High; stability is HIGH (clear leader with a significant margin). 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 attribution methodology (proprietary) — the project’s internal scoring model: resource-delegation and sponsored-energy-use signals, the signal-strength ranking, the definitive-signal classification, the current-control assessment, the
OPERATIONAL_FUNDERandGENESIS_FUNDERtags, and marketplace allowlist handling. - TRONORIGIN E2E Address Catalog (
tronorigin-app/e2e/addresses/catalog.ts) —energy-marketplacealias:TYukBQZ2XXCcRCReAUguyXncCWNY9CEiDQ, categorySERVICE, expected tagENERGY_MARKETPLACE, expected confidence bandHigh.