Smart Contracts and the TVM

A USDTA US-dollar stablecoin issued by Tether, first launched in 2014 on Bitcoin's Omni Layer and circulating on TRON as a TRC-20 token since April 2019. Tether retains privileged functions in the token contract — it can blacklist addresses and destroy blacklisted balances — so every USDT balance is ultimately conditional on the issuer's authority. Not to be confused with counterfeit tokens that copy the USDT name and symbol without any issuer or backing. payment looks like value moving from 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". to another. On the wire it’s a function call on Tether’s contract, run by the TRON Virtual Machine, and that difference decides which resource the 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. burns, whether a new account can come into existence, and where the real counterparty is recorded.

The TVM is the component that runs that code. Once you see how it works, three TRON quirks stop being mysterious: why a TRC-20TRON's smart-contract standard for fungible tokens, derived from Ethereum's ERC-20: a compliant contract exposes transfer, approve, allowance, and transferFrom, and emits Transfer and Approval events. USDT on TRON is issued as a TRC-20 token. Because every TRC-20 transfer is a contract call, it consumes Energy (plus Bandwidth) and — unlike a TRX or TRC-10 transfer — cannot activate a not-yet-created account. transfer never activates its recipient, why a wallet’sSoftware 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. 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. footprint fingerprints its contract activity, and why the to field of a USDT transfer points at Tether’s contract while the person being paid appears nowhere on the surface.

What the TVM is

Every node keeps its own instance of the TVM, the runtime that executes TRON smart contractsA 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., and runs the same code against the same inputs. That agreement is how the network settles on one result.

It’s a state machine, not a ledger. A payments chain only tracks balances. A chain that runs arbitrary code has to track the full state of every contract — storage slots, balances, code — and advance it deterministically. TRON’s own documentation puts it bluntly: with smart contracts, “instead of a simple distributed ledger, TRON is actually a distributed state machine.” Each block applies a transition function to the previous state and produces the next.

Under the hood it’s a stack machine, 1024 items deep, each item a 256-bit word. That width was picked for easy work with 256-bit cryptography: Keccak-256 hashes, secp256k1 signaturesA 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.. Ethereum made the same choices.

A near-twin of the EVM

TRON’s docs say the TVM “exhibits fundamental compatibility with the Ethereum Virtual Machine.” Solidity contracts and compiled EVMEthereum's execution engine — the specification of the state machine that runs compiled smart-contract code, guaranteeing that every node computes identical results from identical transactions. The EVM became a de-facto standard well beyond Ethereum: chains that implement a compatible machine can run the same compiled contracts and reuse the same developer tooling. TRON's TVM is one such compatible implementation, which is why Solidity contracts and their forensic artifacts — call data, event logs, ABIs — look alike on both chains despite entirely different fee models. bytecode mostly port across with minimal changes. For an investigator, intuition built on Ethereum carries over, and the exceptions are where TRON-specific behavior hides.

The opcodes match the EVM’s apart from a small TRON-specific set. Three are worth knowing:

Opcode	What it does	Why it exists
CALLTOKEN (0xD0)	Call a contract while attaching a TRC-10 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. value	TRON has a native TRC-10 token layer the EVM lacks
TOKENBALANCE (0xD1)	Read an address’s balance of a TRC-10 token	Same — native multi-token support at the protocol level
ISCONTRACT (0xD4)	Test whether an address is a contract	The chain answers natively what an address string can’t reveal

[!NOTE] ISCONTRACT is a quiet gift to anyone reasoning about TRON addresses. A base58 T... string looks the same whether it’s a person’s wallet or a deployed contract — the prefix doesn’t tell them apart. The TVM has a dedicated opcode to settle the question on-chain.

A few EVM opcodes are inert on TRON because its consensus model has no use for them. TRON runs delegated proof-of-stake, so the DIFFICULTY opcode returns 0. There’s no per-block gas auction, so GASLIMIT returns 0, and GASPRICE and BASEFEE both return TRON’s fixed energyPrice. One more divergence matters when tracing deterministically-deployed contracts: TRON’s CREATE2 address derivation uses a 0x41 prefix where the EVM uses 0xff — the same 0x41 byte that sits behind every TRON mainnet address.

Triggering a contract is its own transaction type

TRON doesn’t bury contract calls inside ordinary transfers. The protocol defines distinct transaction types, and the split between them is the split between moving value and running code.

A TriggerSmartContract carries a function selector (say, transfer(address,uint256)), ABI-encoded parameters, an optional amount of 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. to send into the contract, and a fee limitA caller-set ceiling, denominated in TRX, on how much a contract call may spend on Energy — fixed at the moment the transaction is signed. If execution would cost more, it halts and its state changes are rolled back, but the resources consumed up to the stop are still charged. The fee limit is the signer's own declaration of what the call is worth to them, so habitual fee-limit values can act as a small behavioral fingerprint of the wallet software or operator constructing the transactions. capping the spend. It names one contract_address — the contract being called — and nothing else at the top level.

This is why reading TRC-20 flow takes a decode pass. Send USDT and the transaction is a TriggerSmartContract calling transfer(address,uint256) on Tether’s contract. The contract_address is the USDT contract. The actual payee and amount live inside the parameter field. Read only the surface fields and you see a wallet “interacting with the USDT contract” while missing who got paid. The counterparty is real; it just has to be decoded out of the call data.

Energy: the cost of computation

TRON’s docs define Energy as “the unit that measures the amount of computation required by the TRON Virtual Machine to perform specific operations.” Every instruction a contract runs “consumes a certain amount of Energy while running.” Each opcode has a price, metered as the contract executes.

Energy is the contract resource. Plain transactions — a bare TRX transfer — draw on 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.. The split carries information of its own: because only TVM execution spends Energy, a wallet’s Energy usage amounts to a record of its contract activity, and anything touching 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., tokens, or contracts has to spend Energy somewhere. A wallet that only ever sends TRX burns Bandwidth and leaves no Energy footprint at all.

Energy is generated by staking TRX or received as a delegation from another account. When staked Energy runs short, the shortfall is paid by burning TRX at the network’s Energy unit price. As of June 2026 that price is 100 sun per Energy unit (0.0001 TRX) — but it’s a governance-adjustable network parameter, not a protocol constant, which is why GASPRICE returns a fixed value. There’s no fluctuating gas auction; the price changes only when governance changes it.

Failed calls aren’t free. A reverted execution still costs the Energy it burned before failing, and the transaction is still recorded on-chain. A require-style revert charges only the Energy used up to the failure; an assert-style failure can consume the whole allocation up to the fee limit. Failed transactions carry real cost and belong in the trace.

When a contract can create an account

This is the load-bearing fact, and it has a history worth getting right — not least because the pre-2019 version of it is still repeated as though it were current.

In TRON’s original design, a system-level transfer (TransferContract or TransferAssetContract) to a non-existent address would create and activate it, charging the standard 1 TRX activation fee. A transfer made from inside a smart contract did not. The protocol documentation was explicit: “if the transfer to address does not exist it can not create an account by smart contract transfer.” A contract trying to send TRX or a TRC-10 token to an uninitialized address failed outright.

TIP-54 — now Final — fixed that inconsistency: a contract can now activate an account when it transfers TRX or TRC-10 to an uninitialized address. The catch is the price. Activation through a contract carries an extra 25,000 Energy charge (as of June 2026), a deliberate cost that keeps activation from being a free side effect of contract execution.

[!SOURCE] TIP-54’s specification discusses the change at a proposal-stage figure (a 0.1 TRX activation fee); the current dev-hub documentation quantifies it as a 25,000 Energy surcharge. These describe the proposal and finalized stages of the same change. Treat the 25,000 Energy figure as the authoritative current cost.

What survives the change is the principle 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. work leans on — but state it carefully, because the usual shorthand overshoots. It is not that a contract is powerless to activate an address; since TIP-54 it plainly is not. It is that a contract never acts on its own behalf. Activation still requires a value transfer someone paid for, and the contract call that carried it was signed 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 real wallet behind a TriggerSmartContract. However many contract layers sit in between, the chain of execution terminates in a signature. Who counts as a first-activator, and why a router or token contract is not the answer even when it is the address that moved the value, is the subject of account activation.

What this means on-chain

Three practical consequences fall out of how the TVM works.

A TRC-20 transfer is code execution. It’s a TriggerSmartContract, so the resource it burns is Energy, it doesn’t by itself activate the recipient (only TRX and TRC-10 transfers do that), and its on-chain contract_address is the token contract, with the counterparty sitting in the call data. A wallet holding only USDT that has never received TRX may sit at an address someone else activated entirely. For any analyst weighing attribution, a token-only funding history is therefore a weak signal: a TRC-20 transfer tells you less about who controls an address than a native transfer does.

An Energy footprint, meanwhile, fingerprints contract activity. Because Energy is spent only by TVM execution, a wallet’s Energy history maps its contract usage. Deterministic, fixed-price metering makes the pattern analysis possible: identical calls cost near-identical Energy, so a wallet whose consumption barely varies is behaving like an automated process, while variable consumption looks like a person reaching across a range of contracts.

The chain records intent, but contracts don’t have any. A contract executes the call it’s handed; it doesn’t decide to send funds. When a flow passes through a contract, the useful question is which externally-owned account triggered the call, and what the call data told it to do. The TVM carries out the instruction faithfully. Attribution starts from that instruction and its signer, and reading a TRON address picks up from there.

Sources

• TRON Developer Hub — TRON Virtual Machine — canonical protocol documentation: TVM as runtime and distributed state machine, the 1024-deep 256-bit stack architecture, and GASPRICE. The live page still calls TRON a distributed state machine, but drops the “actually” quoted in the body, and it no longer spells the Ethereum Virtual Machine out by name anywhere, having moved the compatibility discussion to its TVM vs EVM page; the archived revision below is cited for both wordings. The DIFFICULTY, GASLIMIT and BASEFEE behavior and the 0x41 CREATE2 prefix have moved to the Opcodes page below.
• TRON Developer Hub — TRON Virtual Machine, archived 2026-01-20 — the revision carrying both sentences quoted in the body: that with smart contracts, “instead of a simple distributed ledger, TRON is actually a distributed state machine,” and that the TVM “exhibits fundamental compatibility with the Ethereum Virtual Machine.”
• TRON Developer Hub — Opcodes — opcode reference establishing that TVM opcodes match the EVM except for TRON-specific additions, including CALLTOKEN, TOKENBALANCE, and ISCONTRACT; also the live home of the DIFFICULTY, GASLIMIT and BASEFEE behavior and of the 0x41 CREATE2 prefix, which TRON has moved off the TRON Virtual Machine page above. It documents GASPRICE too, which that page still carries.
• TRON Developer Hub — Resource Model — Energy as the unit of TVM computation, per-instruction consumption, and generation via 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. The live page no longer gives the burn rate for shortfalls, deferring to Paying for resources & Energy sharing for it, and carries neither sentence the body quotes; no single archived revision carries both either, so the two revisions below are cited for one each.
• TRON Developer Hub — Resource Model, archived 2022-08-16 — the revision defining Energy as “the unit that measures the amount of computation required by the TRON Virtual Machine to perform specific operations.”
• TRON Developer Hub — Resource Model, archived 2025-06-20 — the later revision carrying the per-instruction sentence, that every instruction a contract runs “consumes a certain amount of Energy while running.”
• TRON Developer Hub — TriggerSmartContract — the call’s structure: function selector, ABI-encoded parameters, call value, fee limit, and contract address.
• TRON Developer Hub — VM Exception Handling — the Energy cost of failed executions and the difference between require-style and assert-style failures.
• tronprotocol/protocol — core/Tron.proto — the authoritative ContractType enum giving the numeric transaction types (TransferContract 1, TransferAssetContract 2, CreateSmartContract 30, TriggerSmartContract 31).
• TIP-54 — Allow smart contracts to activate accounts — the proposal (status: Final) documenting the original limitation and its amendment.
• TRON Developer Hub — Accounts — the standard 1 TRX fee for direct account activationOn TRON, a newly derived address does not exist on-chain until an existing account activates it — by transferring TRX or TRC-10 tokens to it, by creating it explicitly with an account-creation transaction, or by a smart contract transferring value to it. Until activation the address is just a valid key pair with no state, and the activating account (which pays a small creation cost) is the new wallet's first on-chain relationship., and the contract-activation surcharge. The live page still states the surcharge, as “The calling transaction incurs an extra 25,000 Energy on top of normal execution costs”, but no longer in the words quoted in the body, so the archived revision below is cited for the wording.
• TRON Developer Hub — Accounts, archived 2025-12-09 — the revision stating the finalized surcharge: “Account activation via a contract incurs an extra 25,000 Energy cost”.
• java-tron documentation — Smart contracts — Energy as the unit of contract resource consumption. The live page no longer describes the pre-TIP-54 contract-transfer behavior; the archived revision below is cited for it.
• java-tron documentation — Smart contracts, archived 2019-08-21 — the revision documenting the original limitation, that “if the transfer to address does not exist it can not create an account by smart contract transfer.” Captured while TIP-54 was proposed but not yet implemented.
• Ethereum Foundation — Ethereum Virtual Machine (EVM) — the EVM’s 256-bit word size, “chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures)”; cited for the Ethereum side of the comparison only.
• asset_issue_contract.proto — tronprotocol/protocol — the protocol definition of TransferAssetContract (asset_name, owner_address, to_address, amount) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.
• balance_contract.proto — tronprotocol/protocol — the protocol definition of TransferContract (owner_address, to_address, amount) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.
• smart_contract.proto — tronprotocol/protocol — the protocol definition of CreateSmartContract (owner_address, new_contract, call_token_value, token_id) and TriggerSmartContract (owner_address, contract_address, call_value, data, call_token_value, token_id) — the message types this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.