The Resource-Delegation Trail

Most funding relationships on-chain are visible because value moves: A sends B some TRXThe native coin of the TRON network. TRX settles value directly (no contract call needed), is staked to obtain Energy, Bandwidth, and voting power, and is burned to pay fees when staked resources fall short. Its smallest unit is the sun: 1 TRX = 1,000,000 sun., and the transfer is right there in B’s history. Resource delegationA TRON mechanism by which one account lends the Energy or Bandwidth derived from its own staked TRX to another account, without any TRX changing hands. Because it supplies a wallet's operating capacity rather than its funds, delegation marks an ongoing operational relationship — a fee-sponsorship link, not a funding-lineage link — and routine services such as exchanges do not delegate resources to customer wallets. is the exception. It is how one addressA public identifier, derived from a key pair, at which an account receives funds and is looked up on-chain. Anyone can view an address's history, but only the matching private key can spend from it. TRON addresses are 34-character Base58Check strings beginning with "T". can pay for another’s transactionsA signed instruction ("tx" for short) that changes on-chain state — transferring value, calling a contract, or updating an account's settings. Once it is included in a block and that block reaches finality the record is permanent: later transactions can supersede its effects, but the entry itself can never be edited or deleted. Before finality, a freshly included transaction can still be reversed if its block is reorganized out. indefinitely, and it leaves no transfer behind — because no transfer happens.

That makes delegation the quietest funding relationship TRON has, and one of the more useful once you know where it hides. This article is about the trail itself: what a delegation transaction is, what its reversal looks like, and how to read a sequence of them. The economics of why stakingLocking TRX (historically called freezing) to obtain network resources instead of paying fees per transaction — a stake earns either Energy or Bandwidth, chosen at stake time. Staking also grants TRON Power for Super Representative voting, at one vote per staked TRX, making a wallet's stake both its fee budget and its governance weight. and delegation work this way is the subject of Stake 2.0; here the subject is narrower — the transactions the relationship leaves behind.

A delegation moves no TRX

When an address delegates a resource, its staked TRX does not move. The delegator keeps the balance; what shifts is only the right to consume the BandwidthA TRON network resource that covers the byte-size cost of putting a transaction on chain — one byte consumes one Bandwidth point. Every account receives a small free daily allowance (also called free bandwidth); heavier usage requires staking TRX, receiving a delegation, or burning TRX to cover the bytes. or EnergyA TRON network resource that meters the computational cost of smart-contract execution, consumed whenever a transaction calls contract code — including TRC-20 token transfers such as USDT. An account obtains Energy by staking TRX or receiving a delegation from another account; if it holds too little, the shortfall is paid by burning TRX from its balance. that balance produces. The receiver transacts as though it had staked for itself, the cost draws down the delegator’s allowance, and the underlying TRX sits exactly where it was.

The consequence for a reader is direct. A trace that follows value — TRX transfers, tokenA unit of value recorded inside a smart contract rather than in the chain's native ledger — the contract keeps the balance table, and moving tokens means asking the contract to update it. Not to be confused with a coin, which is the chain's built-in asset (TRX on TRON) used to pay for the network itself. movements — passes straight over a delegation, because there is no value edge to follow. Two addresses can be in a months-long funding relationship, one carrying the other’s entire transaction cost, with nothing in either account’s transfer history to show it. The relationship is real; it is just recorded in a different place.

That place is the transaction type. A delegation is a DelegateResourceContract, and undoing it is an UnDelegateResourceContract — neither is a transfer, and neither shows up if those types are filtered out of a view.

The two contracts and their fields

The grant and its reversal are small, and their fields say exactly what happened.

DelegateResourceContract carries:

Field	What it names
owner_address	The delegator — the address that staked the TRX and is lending its resource.
receiver_address	The address receiving the resource.
resource	Which resource: Bandwidth or Energy.
balance	The amount of staked TRX (in sun) whose resource is being delegated.
lock / lock_period	Whether the delegation is time-locked, and for how many blocks.

UnDelegateResourceContract is the mirror image — owner_address, receiver_address, resource, balance — and it reclaims the delegated resource back to the delegator. It has no lock fields; it is the reversal, not a new commitment.

Read together, the pair tells you the whole arrangement: who lent, to whom, which resource, how much, and — from the two timestamps — for how long.

The lifecycle: delegate, lock, reclaim

A delegation is not instantaneous-and-gone. It has a shape in time.

The DelegateResourceContract opens it. If the delegator sets lock, the delegation cannot be reclaimed until lock_period blocks have passed — a parameter added so the two parties can write a fixed resource-lease term straight into the chain. Set lock with lock_period left at zero and it falls back to the default of 86,400 blocks, about three days; set it higher and the lock runs longer. Until the lock clears, the receiver keeps the resource and the delegator cannot pull it back.

The UnDelegateResourceContract closes it. When it lands, the resource returns to the delegator’s allowance and the receiver loses it. The gap between the two transactions is the lifetime of that particular grant — a fact you can read off the block timestamps without any off-chain information.

Reading the trail

For someone following an address, the delegation transactions answer a question transfers cannot.

A recurring delegator is a funder. One DelegateResourceContract is a favor. A pattern of them — the same delegator topping the same receiver up again and again, each grant renewed before the resource runs dry — is a standing arrangement. Someone is absorbing the ongoing cost of keeping that address operational, and the trail shows it plainly even though no money ever moved.

The reclaim is a signal too. An UnDelegateResourceContract ends the relationship. A delegation that runs for months and is then abruptly reclaimed marks a change — the funder stepping back, an arrangement dissolved — dated to the block it lands in.

The fields scope the tie. resource and balance say what was being covered and how much: a small Bandwidth delegation keeps an address able to send simple transfers; a large Energy delegation underwrites heavy contract activity. The size and type of the lend describe the kind of operation the receiver runs.

None of this is visible to a view built around value. A delegation is a relationship without a payment, and the only trace it leaves is the pair of contracts that opened and closed it — which is exactly why, for an address that seems to transact for free, the first question worth asking is who is delegating to it.

Sources

• balance_contract.proto — tronprotocol/protocol — the DelegateResourceContract (owner_address, receiver_address, resource, balance, lock, lock_period) and UnDelegateResourceContract (owner_address, receiver_address, resource, balance) message definitions.
• TIP-467: TRON Stake 2.0 — the Stake 2.0 model that separates staking from delegation and defines the DELEGATERESOURCE / UNDELEGATERESOURCE operations.
• TIP-542: Customizable delegate lock period — the lock_period parameter (in blocks) and the 86,400-block (~3-day) default lock.