Token Standards on TRON

A 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. transfer on TRON isn’t one thing. The chain carries three distinct kinds of value on entirely different plumbing. A 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. transfer is a native protocol operation. A TRC-10 transfer is also native — the protocol understands the token directly, with no code running. 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 is the odd one out: a 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. executing, the same machinery that runs a 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. swap.

For an investigator, which standard a transfer uses isn’t a detail. It tells you whether the transfer could have brought a new account into existence, which resource it consumed, and whether the recipient is sitting in plain sight or waiting to be decoded.

TRX: the native coin

TRX is the base layer everything else sits on: “the native token of the TRON network — used for fees, 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 rewards, and as the primary unit of value across the TRON DeFi ecosystem.” It pays for resources when an account’s 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. runs short, is staked to obtain those resources and voting rights, and serves as collateral in DeFi lending.

Its smallest unit is the sun, where 1 TRX = 1,000,000 sun — always lowercase, because uppercase SUN is the unrelated SUN.io governance token. Raw 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. data is denominated in sun, which is why a one-TRX transfer shows an amount of 1000000.

Moving TRX is its own protocol transaction type — TransferContract (type 1). A TRX transfer is “a TransferContract transaction that moves TRX from one account to another.” Sender, recipient, and amount ride as top-level fields. No code runs; the protocol moves the balance directly.

TRC-10: a token the protocol understands natively

TRC-10 is where TRON diverges most sharply from Ethereum. It’s “a native token standard supported by the TRON network. Unlike TRC-20 tokens, it does not rely on the TRON Virtual Machine (TVM) but is implemented directly at the blockchainA shared ledger maintained by many independent computers, in which transactions are grouped into blocks and each block cryptographically references the one before it. Because rewriting any past entry would break every link after it, the record is effectively append-only — new entries can be added, but history cannot be quietly altered. protocol level.” The chain itself knows what a TRC-10 token is — issuing or transferring one runs no contract code.

Issuance is a transaction type, not a deployment. Any account can issue a TRC-10 token through AssetIssueContract (type 6), “limited to one issuance per account — with a creation fee of 1024 TRX” (a network parameter rather than a fixed constant). No Solidity, no bytecode — the token’s name, supply, and precision are fields in a transaction the protocol records directly. Transfers get their own type too: TransferAssetContract (type 2) — distinct from the TransferContract used for TRX and from a TRC-20 transfer’s contract call — which exposes the token, sender, recipient, and amount as readable top-level fields.

The TVM was even extended to handle TRC-10. Dedicated opcodes — CALLTOKEN and TOKENBALANCE, whose own description names the “trc10 token” — let a contract attach and read TRC-10 value. Those opcodes exist precisely because the protocol treats TRC-10 as first-class, and they’re covered alongside the rest of the TVM in Smart Contracts and the TVM. TRC-20 gets no such native support, because a TRC-20 token isn’t a protocol object at all.

TRC-20: a token that is really a smart contract

TRC-20 is “the fungible token standard on TRON, fully compatible with Ethereum’s ERC-20Ethereum's fungible-token standard: a contract interface fixing a common set of functions (transfer, approve, transferFrom, balanceOf) and events (Transfer, Approval) so that every conforming token behaves identically for wallets, exchanges, and tooling. TRON's TRC-20 standard is a deliberate copy, which is why token mechanics on the two chains — allowances, transfer events, decimal scaling — read the same and why analysis concepts carry over directly. The name comes from Ethereum Request for Comments 20, the 2015 proposal by Fabian Vogelsteller and Vitalik Buterin. at the interface level” — not a protocol primitive but a smart contract implementing that interface on the TVM. TRON’s glossary draws the same line, listing TRC-20 as a TVM-based fungible token against TRC-10’s protocol-level one.

The standard is defined by TIP-20 (status: Final), adapted from Ethereum’s ERC-20 — possible because the TVM is EVM-compatible. It fixes the interface every compliant token exposes:

Function	What it does
totalSupply()	Total tokens in existence
balanceOf(address)	An address’sA 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". balance
transfer(to, value)	Move tokens from the caller
transferFrom(from, to, value)	Move tokens the caller was approved to spend
approve(spender, value)	Authorize another address to spend the caller’s tokens
allowance(owner, spender)	Remaining approved amount

Two events round it out — Transfer and Approval — emitted so off-chain readers can follow token movement through logs.

[!NOTE] The approve/allowance pair is where a lot of TRON risk lives. approve() “authorizes _spender (often a DApp contract) to transfer up to _value tokens from the caller’s account.” 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. that has approved a malicious contract for an unlimited allowanceA standing grant recorded in a token contract: the holder calls approve to let a designated spender later move up to a set amount of their tokens via transferFrom, and allowance reports how much of the grant remains. An approval is a live control relationship — it persists until changed, and an "unlimited allowance" (a common dApp convenience) lets the spender drain the full balance at any time, which is exactly the mechanism wallet-drainer phishing abuses. can be drained later without signing anything further — the approval already granted the permission. Reading a wallet’s outstanding approvals is its own investigative step.

So a TRC-20 transfer is a TriggerSmartContract invoking transfer(address,uint256) — a contract call, behaving nothing like a native transfer. That gap drives everything below.

Resources: why TRC-20 costs more to send

Every transaction consumes Bandwidth, measured by its byte size, and each account gets 600 free Bandwidth per day — the full resource model lives in Stake 2.0. Energy is different: it “covers the computation the TVM performs when executing a smart contract,” and only contract execution burns it. A TRX or TRC-10 transfer runs no code, so it spends Bandwidth alone. A TRC-20 transfer is code, so it consumes Energy on top of the Bandwidth for its bytes.

What the distinction signals on-chain

Only native value can activate an account. A TRX or TRC-10 transfer to an uninitialized address creates and activates it — including when a smart contract is the one moving it, for a 25,000 Energy surcharge. A TRC-20 transfer can’t, because it moves no native value at all — a point developed in Account Activation. The 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. consequence is direct: a wallet holding nothing but 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. may have been activated by someone else entirely, because the USDT funding it could never have brought it into existence. That’s why a token-only funding history is a weak attribution signal for any analyst — a TRC-20 inflow tells you less about who stood up an address than a native one does.

The recipient is readable for native transfers and hidden for TRC-20. A TransferContract or TransferAssetContract records the recipient as a real to_address. A TriggerSmartContract doesn’t: its top-level contract_address is the token contract, and the actual recipient and amount are ABI-encoded inside the call data. Reading TRC-20 flow means decoding that data, and the mechanics belong to Smart Contracts and the TVM. The dominant TRC-20 on the network, and the one most of this matters for, is USDT — its story is USDT on TRON.

Sources

• TRON Developer Hub — TRX — TRX as the native coin, the sun subunit (1 TRX = 1,000,000 sun, always lowercase — uppercase SUN is the unrelated SUN.io token), and TransferContract as the TRX transfer type.
• TRON Developer Hub — TRC-10 — TRC-10 as a native, non-TVM token standard implemented at the protocol level; AssetIssueContract, the 1024 TRX issuance fee and one-per-account limit, and TransferAssetContract.
• TRON Developer Hub — TRC-20 — TRC-20 as a smart-contract token standard, the function interface, and the approve()/allowance() authorization model.
• TRC-20 protocol interface — TRON Developer Hub — the required Solidity interface and the per-function descriptions quoted here, including approve, which “authorizes _spender (often a DApp contract) to transfer up to _value tokens from the caller’s account.”
• TIP-20 — TRC-20 Token Standard — the canonical standard (status: Final), its ERC-20 derivation, and the function 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..
• TRON Developer Hub — Glossary — the native-vs-TVM contrast between TRC-10 and TRC-20 stated directly.
• TRON Developer Hub — Resource Model — Bandwidth as the per-byte resource every transaction consumes (600 free per day) and Energy as the TVM-computation resource.
• TRON Developer Hub — Opcodes — the native TVM opcodes for TRC-10 (CALLTOKEN, TOKENBALANCE), evidence that TRC-10 is a protocol-native asset class.
• tronprotocol/protocol — core/Tron.proto — the ContractType enum giving the numeric transaction types (TransferContract 1, TransferAssetContract 2, AssetIssueContract 6, TriggerSmartContract 31).
• asset_issue_contract.proto — tronprotocol/protocol — the protocol definition of AssetIssueContract (id, owner_address, name, abbr, total_supply, frozen_supply, trx_num, precision, num, start_time, end_time, order, vote_score, description, url, free_asset_net_limit, public_free_asset_net_limit, public_free_asset_net_usage, public_latest_free_net_time) and TransferAssetContract (asset_name, owner_address, to_address, amount) — the message types 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 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.