Internal Transactions

A top-level transactionA 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. shows a walletSoftware or hardware that stores private keys and uses them to sign transactions. A wallet holds keys, not coins — balances live on the ledger itself — so the same funds can be reached from any wallet loaded with the same keys, and losing the wallet loses nothing if the keys are backed up elsewhere. calling a contract. It rarely shows where the money went. When a contract runs, it can move 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 tokensA 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. on its own — paying out a swap, releasing collateral, forwarding a deposit — and those movements never hit the chain as separate transactions. They’re internal transactionsA value transfer or call that a smart contract makes while executing, nested inside the outer transaction that triggered it — also called an internal tx. Internal transactions carry no signature and no separate fee of their own, because they are effects of contract code rather than independently authorized actions; a complete trace of value movement must therefore include them, not just the top-level signed transactions.: effects of the parent call, recorded inside it, and invisible to anyone reading only the top-level transfer list. For tracing DeFiDecentralized finance — financial services (trading, lending, borrowing, earning yield) delivered by smart contracts that hold funds and enforce terms directly on-chain, with no bank or broker as intermediary. Anyone with a wallet can interact with a DeFi protocol, and every position and movement is publicly recorded. fund flows that gap is most of the problem. This article covers what these records are, why they lack the defining features of a normal transaction, and where to actually find them.

What an internal transaction is

TRON’s docs put it precisely: “during the execution of smart contractA program deployed to a blockchain that runs deterministically when called, holding its own state and balance and enforcing its rules without any operator's ongoing involvement. Because a contract executes code rather than acting on anyone's initiative, its address represents logic — funds can flow through it, but the contract itself is not a person or a controlling entity. transactions, the contract may trigger other contract method invocation, or transfer TRX/TRC10 tokens to external accounts, or it may also perform operations such as 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., voting, resource delegating. Such transactions that occur during a smart contract execution are called internal transactions.” They are “transactions triggered in the TVM by contract accounts.”

The operative words are “by contract accounts.” A normal transaction starts at a person’s wallet; an internal one starts at a contract, mid-execution, because the code it’s running told it to. The reference is blunt about scope: internal transactions “represent all transactions happened in a smart contract call.”

There’s no separate object to point at. An internal transaction is a record — caller_address, transferTo_address, the value moved, and a type note of call, create, or suicide — carried inside the parent transaction’s info, in a repeated internal_transactions field. It exists only as something the parent TriggerSmartContract did while it ran.

Two things about that record mislead people, and both are worth fixing before you rely on it.

note: "create" does not mean an account was created. The three values are TVM operation categories, not outcomes: create is contract deployment (a CREATE or CREATE2 opcode), and suicide is SELFDESTRUCT. An internal transfer that brings a wallet into existence is an ordinary value-bearing call and carries note: "call" like any other. Filtering on create to find account creations returns deployments and misses every activation.

An internal transfer can activate an account. A contract sending TRX or a TRC-10 token to an 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". that doesn’t yet exist creates it — see Account Activation for the fee mechanics. That makes transferTo_address the field that matters: match it against the address you’re investigating, and the parent transaction tells you both which contract moved the value and which wallet signed for the call.

Why it doesn’t behave like a transaction

An internal transaction is an effect of execution that no person submitted, so it lacks the two features that define a top-level one.

No signatureA cryptographic proof, produced with a private key over a transaction's exact contents, that the key holder authorized that transaction and no other. Nodes verify the signature before accepting the transaction, so a valid signature is definitive evidence the key was used — though not of who was holding it at the time.. A normal transaction carries the sender’s signature — the cryptographic proof that it could only have come from whoever holds the private keyA mathematically linked pair — a private key that signs transactions, and a public key (with the address derived from it) that lets anyone verify those signatures. Whoever holds the private key controls the address: on a blockchain, ownership is key control, whatever any off-chain record says. "Keypair", "private key", and "public key" all refer to parts of this same structure.. An internal transaction has nothing like it. The authorization lives one level up: the outer call was signed, and the contract acted because that call told it to.

No fee. All the 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. for a contract execution is metered on the parent and billed to the calling account, the mechanics of which belong to smart contracts and the TVM. The internal record holds the value moved and the parties involved, but no resource accounting. The cost sits entirely on the parent.

	Top-level transaction	Internal transaction
Initiated by	An externally-owned accountAn account controlled by a private key held by a person or organization, as opposed to a contract account controlled by code. The term comes from Ethereum, but the distinction applies on TRON too: every externally initiated transaction begins with an EOA's signature, so tracing who acts on a chain ultimately means tracing EOAs. (a wallet)	A contract, during execution
Signature	Yes — proves the sender	None
Fee / resource cost	Pays its own 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. and Energy	None; carried by the parent
Exists on-chain as	A standalone transaction	A record inside the parent’s transaction info

Finding them

This is where internal transactions become an investigative problem: they don’t show up where you’d reach for them.

An internal transaction is addressable only through its parent. Call gettransactioninfobyid with the outer hashA fixed-length fingerprint computed from data of any size by a one-way function: the same input always produces the same output, but the output reveals nothing about the input and no practical method finds a second input that matches it. Transaction IDs and block IDs are hashes, and each block embeds the previous block's hash — which is what makes tampering with history detectable. and the internal_transactions field comes back — but, the docs warn, “viewing internal transactions directly through the hash of internal transactions is not supported.” You find them only if you already know the outer transaction.

It gets worse: a node may not hold them at all. “The TRON node does not save internal transaction information by default, and needs to be manually enabled through the node configuration file” — the saveInternalTx setting. A node that ran with it off has no record of anything that passed through.

The way around the outer-hash requirement is a gateway with its own index. TronGrid exposes an address-indexed endpoint, /v1/accounts/{address}/internal-transactions, listing the internal transactions touching a given address with the usual direction and time filters. As a free public gateway, it’s the practical way to ask “what flowed in and out of this wallet through contracts” without first knowing every parent transaction. In practice you end up using both routes; the workflow around them belongs to reading a TRON address.

Why the real flow lives here

A top-level TriggerSmartContract tells you a wallet called a contract. It does not tell you the contract then sent TRX to five external accounts — that fan-out is all internal. For any interaction where a contract custodies and redistributes value — a DEX swap, a bridge deposit, a lending withdrawal — the movement that matters is internal.

It also bends attributionThe process of identifying the entity most likely to control a blockchain address by combining on-chain signals — who created and funded it, how it transacts, which keys can act for it — with known service patterns and labels. Attribution conclusions are evidence-weighted judgments, not certainties, and are strongest when several independent signals converge.. When a contract moves value to an address, the party recorded as the sender is the contract — the internal transaction’s caller_address. The externally-owned account that triggered the outer call appears only on the parent. A wallet funded this way reads, on the record, as funded by a contract, even though a person set the whole thing in motion one layer up.

A blind spot any trace must close

Funds sent through a contract’s internal calls may never appear in the standard transaction history. A wallet financed that way reads as unfunded until someone decodes the internal effects of the calls it was involved in, and its origin slips past in the meantime.

There is a weight-of-evidence point here too. Internal-transaction funding is weaker evidence than a direct transfer: the human originator is one layer removed, a contract mediated the value, so the person behind it stays less certain than when one wallet pays another outright. Read it as corroborating evidence, not proof. That caution fits the whole category — internal transactions show where value actually moved, and a contract standing between two parties is where intent is hardest to read.

Sources

• Internal transactions — TRON Developer Hub — the live home of the topic: internal transactions as TRX moves triggered inside contract execution, the addressing constraint that they are reached through the outer transaction, and the node setting that must be enabled before a node records them. TRON split this page off the Transactions page and rewrote it; the wording quoted in the body belongs to the combined page, cited from the archive below.
• Transactions — TRON Developer Hub, archived 2026-04-10 — the revision carrying the wording quoted in the body: internal transactions as “transactions triggered in the TVM by contract accounts,” the constraint that “viewing internal transactions directly through the hash of internal transactions is not supported,” and the default that “The TRON node does not save internal transaction information by default, and needs to be manually enabled through the node configuration file”.
• tronprotocol/documentation — InternalTransaction — internal transactions as “all transactions happened in a smart contract call,” the caller_address/transferTo_address/callValueInfo fields, the call/create/suicide types, retrieval via gettransactioninfobyid, and the saveInternalTx requirement.
• tronprotocol/protocol — core/Tron.proto — the InternalTransaction message and its presence as a repeated field inside TransactionInfo, the structural proof that an internal transaction has no standalone existence.
• TronGrid — Get internal transactions by address — the address-indexed endpoint for listing the internal transactions touching an account.
• smart_contract.proto — tronprotocol/protocol — the protocol definition of TriggerSmartContract (owner_address, contract_address, call_value, data, call_token_value, token_id) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.