TRON Crypto Dictionary

ABI (Application Binary Interface) (Smart Contract Interaction Interface)

A standardized interface for interacting with smart contracts on the TRON network. The ABI defines contract function signatures along with input and output parameter types. It is used by wallets and dApps to construct contract calls, including USDT TRC-20 transfers (the transfer function). Without a valid ABI, programmatic interaction with a contract is impossible.

Account Activation (TRON Account Activation)

The initial process of creating and activating an address on the TRON network. To activate an account, the newly generated address simply needs to receive a minimal amount of TRX (as little as 0.00001 TRX), after which it becomes a fully functional network participant. The standard activation fee is 1 TRX, paid by the sending wallet and effectively consumed to register the new account in the blockchain ledger.

Immediately upon activation, the account is automatically credited with 600 Bandwidth points, which are replenished daily at no cost. Without activation, the following operations are unavailable: transferring USDT TRC-20, receiving and using Energy, and executing smart contract calls. Activation is a mandatory first step for full interaction with the TRON network.

Note: The terms Account Creation Fee, Activation Fee, and Address Activation Fee all refer to the same 1 TRX charge for activating a new address and are consolidated under this definition.

Account Balance

The amount of cryptocurrency, tokens, and available resources (Energy, Bandwidth) held at a blockchain address. You can check your balance through a wallet (TronLink, Trust Wallet) or the public block explorer Tronscan (tronscan.org).

Account Model

The architectural model of the TRON blockchain, where the network state is stored as accounts with balances and resources (as opposed to Bitcoin’s UTXO model). Each TRON account contains: TRX balance, token balances, resources (Energy, Bandwidth), TRON Power, permission data, and staking history.

Account Permission Update

An operation on the TRON network that allows modification of the account’s governance structure, including adding or removing keys, configuring access levels, and setting transaction signing rights. It supports three levels: Owner Permission (full control), Active Permission (operational rights), and Witness Permission (for SR nodes).

Account Resource Limit

The maximum amount of Energy and Bandwidth available to an account on the TRON network. It is determined by the sum of the free daily quota (600 Bandwidth/day), resources obtained through staking, and delegated resources. Current limits can be checked via the wallet/getaccountresource API.

Account Type

There are two types of accounts on the TRON network: External Account — controlled by a private key and owned by the user; and Contract Account — governed by smart contract code and created upon contract deployment. Only external accounts can initiate transactions.

Active Permission

One of three permission levels in the TRON account management system (alongside Owner Permission and Witness Permission). Active Permission defines which transaction types an account can execute: transfers, staking, delegation, and contract calls. It is configured via the operations field and supports multi-signature with a customizable threshold. Important: accounts created before Stake 2.0 may lack permissions for Stake 2.0 operations — a permissions update is required.

Address

A public identifier on the blockchain used for sending and receiving cryptocurrency and tokens. TRON addresses start with the letter “T”, consist of 34 characters, and use Base58Check encoding with a built-in checksum verification.

Advanced TRON Metrics

A set of in-depth metrics and statistics used for analyzing TRON network load, smart contract performance, and Energy and Bandwidth consumption. Available through Tronscan, TronGrid API, and third-party analytics services.

Approval (Token Approval)

A permission granted to a smart contract to spend tokens from the user’s wallet up to a specified limit. In the TRC-20 context: the approve(spender, amount) function allows, for example, a DEX to debit USDT from your address during a swap. Each approve call consumes Energy. It is recommended to set the limit equal to the required amount rather than infinite, to minimize risk exposure.

APR (Annual Percentage Rate)

A yield metric for staking TRX on the TRON network. It is generated from voting rewards distributed by Super Representatives. The actual APR depends on the stake size, the selected SR, and the current reward parameters (16 TRX per block + voting rewards). Each SR sets its own reward-sharing ratio with voters.

Asset Issue (Asset Issuance / TRC-10)

A mechanism for creating custom TRC-10 standard tokens on the TRON network. Unlike TRC-20, TRC-10 tokens are implemented at the protocol level (not via smart contracts), making their transfers cheaper — they require only Bandwidth, with no Energy consumption. Creating a TRC-10 token costs 1,024 TRX.

Automation & Smart Rules

Mechanisms for automated resource and transaction management on the TRON network based on predefined conditions, limits, and usage scenarios. Implemented through API integrations, smart contracts, and third-party services.

Auto Energy Allocation

A mechanism for automatically distributing Energy across wallets or operations on the TRON network based on current demand. Used by Energy rental services and business platforms to optimize resources across operational wallets.

Auto Resource Refill (Auto Resource Replenishment)

A feature that automatically tops up Energy or Bandwidth when available resources fall below a predefined minimum threshold. Implemented via Energy rental service APIs: when the balance drops below the set level, the system automatically delegates the required amount.

Available Bandwidth

The amount of throughput capacity available for executing transactions on the TRON network without paying a TRX fee. It consists of: 600 free daily points, resources from TRX staking, and delegated Bandwidth. It can be checked in your wallet or on Tronscan under the “Resources” tab.

Available Energy

The current amount of Energy available to an account for executing smart contracts and USDT TRC-20 transfers without burning TRX. It is composed of staked, delegated, and rented Energy. There is no free Energy quota — when Energy reaches zero, the network burns TRX.

Bandwidth (TRON Throughput Capacity)

A fundamental network resource on the TRON blockchain, required for transmitting and storing transactions. Bandwidth determines the “weight” of a transaction in bytes — 1 byte of data = 1 Bandwidth point. Virtually every transaction on the TRON network, except read operations (queries), requires Bandwidth consumption.

The network’s daily Bandwidth pool is 43,200,000,000 points (network parameter #62). Every activated account receives 600 free points per day.

Bandwidth Consumption

The amount of throughput capacity consumed when executing a transaction. Consumption is directly proportional to the transaction size in bytes (1 byte = 1 point). Typical values: TRX transfer — ~268 pts, USDT TRC-20 transfer — ~345 pts, Energy delegation — ~281–283 pts, voting — ~270–300 pts.

Bandwidth Delegation

A TRON network mechanism that enables transferring throughput capacity from one account to another without moving TRX tokens. Delegated Bandwidth is used by the recipient for transactions, reducing or eliminating the need to burn TRX. Executed via DelegateResourceContract in Stake 2.0. Only unused Bandwidth can be delegated.

Bandwidth Fee Fallback

A built-in TRON network mechanism where insufficient Bandwidth is automatically compensated by burning TRX. Rate: 1 Bandwidth point = 1,000 sun = 0.001 TRX. For a USDT TRC-20 transfer (~345 Bandwidth), this amounts to ~0.345 TRX. This allows the transaction to go through even with zero Bandwidth, but at the cost of direct TRX expenditure.

Bandwidth Limit

The maximum throughput capacity available to an account. It consists of the 600 free daily points plus resources from staking. Formula: your Bandwidth = (your TRX staked for Bandwidth / total TRX staked for Bandwidth network-wide) × 43,200,000,000.

Bandwidth Points

A synonym for Bandwidth — throughput capacity units that allow executing transactions without paying TRX fees. Each account receives 600 Bandwidth Points every 24 hours. Additional points can be obtained through TRX staking or delegation.

Bandwidth Recovery

The process of automatic Bandwidth restoration after consumption. Recovery occurs linearly over 24 hours (~28,800 blocks): with each block (~3 seconds), approximately 1/28,800 of the consumed amount is restored. After 6 hours — ~25%, after 12 hours — ~50%, full recovery — after 24 hours.

Note: The term Bandwidth Regeneration refers to the same process and is consolidated under this definition.

Bandwidth Surplus / Deficit

An account state where the available Bandwidth exceeds demand (surplus) or falls short (deficit). In a deficit scenario, the network automatically burns TRX (Bandwidth Fee Fallback). With a surplus, excess Bandwidth can be delegated to other accounts.

Bandwidth Usage Rate

A metric measuring the intensity of Bandwidth consumption by an account or smart contract per unit of time. Useful for forecasting demand and planning staking or rental strategies.

Base58Check (Address Encoding Format)

The address encoding format used on the TRON network. All TRON addresses start with the letter “T” and consist of 34 characters. Base58Check includes a built-in checksum verification, reducing the likelihood of errors when copying addresses. Internally, TRON stores addresses in hex format with the 0x41 prefix. Base58 excludes the characters 0, O, l, and I, which are easily confused.

Block

A set of confirmed transactions bundled together and appended to the blockchain. On the TRON network, a new block is produced every ~3 seconds by one of the 27 Super Representatives. Approximately 28,800 blocks are generated per day. Each block contains the previous block’s hash, a timestamp, transactions, and the producer’s signature.

Block Explorer

A tool for viewing transactions, blocks, addresses, smart contracts, and resource consumption on the TRON network. The primary explorer is Tronscan (tronscan.org). It allows users to check: balances, resource status (Energy, Bandwidth), transaction history, delegation records, and staking data.

Block Production

The process of creating new blocks on the TRON network. Blocks are produced by the 27 Super Representatives in rotation, every ~3 seconds (~28,800 blocks per day). The order is determined by the DPoS consensus mechanism and recalculated every maintenance cycle (6 hours).

Block Reward

The reward earned by Super Representatives for producing blocks. It consists of: 16 TRX per block created (8 TRX block reward + 8 TRX voting reward) and 160 TRX in voting rewards distributed among the 27 SRs and 100 SR Partners every 6 hours. A portion of these rewards is redistributed by SRs to voters proportionally to their vote share.

Block Time

The average time required to produce a new block. On TRON, it is ~3 seconds. For a reliable confirmation (solid block), approval from 19 out of 27 SRs is needed — approximately 1 minute.

Blockchain

A distributed and immutable data ledger secured by cryptography that stores all network transactions. TRON operates on a blockchain powered by the DPoS (Delegated Proof of Stake) consensus mechanism.

Burn Mechanism

An automatic process that permanently destroys TRX when resources are insufficient. For Energy shortfalls — 0.0001 TRX per unit (100 sun); for Bandwidth shortfalls — 0.001 TRX per unit (1,000 sun). Burned TRX is permanently removed from circulation. Resource consumption priority: delegated resources → own resources (staking) → free quota (Bandwidth only) → TRX burn.

Burn TRX

A fee payment mechanism that permanently destroys TRX when Energy or Bandwidth is insufficient. It serves as a last-resort option — the network triggers it automatically when no available resources remain. For a USDT TRC-20 transfer with zero available resources, approximately 6.77–13.37 TRX is burned.

Bytecode

Compiled low-level smart contract code executed by the TVM (TRON Virtual Machine). Contracts written in Solidity or Java are compiled into bytecode before deployment. Bytecode directly determines Energy consumption — each instruction has a fixed cost (SSTORE: 20,000/5,000 Energy, SLOAD: 200 Energy).

CancelAllUnfreezeV2 (Unstaking Cancellation)

A Stake 2.0 transaction that allows canceling all pending TRX unstaking operations. The TRX is returned to frozen status, and resources (Bandwidth/Energy) along with TRON Power are restored. Useful when an unstaking request was initiated by mistake. API: wallet/cancelallunfreezev2.

Checkpoints

Snapshots of the TRON network state used to calculate Energy and Bandwidth recovery. They are tied to block numbers. Each block (~3 seconds) serves as a potential checkpoint for linear resource restoration.

Cold Storage

A method of storing cryptocurrency offline to enhance security. In the TRON context: TRX and USDT are held at an address whose private key has never been exposed to the internet (hardware wallet, paper wallet, air-gapped device).

Cold Wallet

A wallet that is not connected to the internet, used for secure cryptocurrency storage. On TRON, it can receive TRX, USDT, and other tokens, but sending requires Energy and Bandwidth — which can be delegated from a hot wallet. Examples: Ledger, SafePal, Trezor.

Cold Wallet Energy Management

A strategy of delegating Energy from a hot wallet to a cold wallet to execute transactions without holding TRX on the cold wallet. All TRX is stored on the hot staking account, while the operational (cold) wallet receives only resources via delegation — maximizing security.

Committee Proposal

A mechanism for modifying TRON network parameters through Super Representative voting. Any SR can submit a proposal. Approval requires 19 out of 27 SRs. Key parameters: #19 — Energy pool (180 billion), #62 — Bandwidth pool (43.2 billion), #70 — unstaking period (14 days). The full list is available on Tronscan under “Parameters.”

Confirmation

The process of including a transaction in a block and having it confirmed by the network. A single confirmation (block inclusion) takes ~3 seconds. A reliable confirmation (solid block) requires 19 out of 27 SRs — approximately 1 minute. Most exchanges consider a transaction confirmed after 19 confirmations.

Consensus Mechanism / DPoS

The transaction agreement algorithm — Delegated Proof of Stake. TRX holders vote for Super Representatives using TRON Power (1 TRX = 1 vote). The 27 nodes with the most votes produce blocks. Votes are recalculated every 6 hours (00:00, 06:00, 12:00, 18:00 UTC). The mechanism delivers ~2,000 TPS and a block time of ~3 seconds.

consume_user_resource_percent (User Resource Percentage)

A smart contract parameter (0 to 100) that defines the share of Energy paid by the user when calling the contract. The remainder is covered by the deployer (within the origin_energy_limit). For USDT it is set to 100%: the sender pays all Energy. Set at deployment, it can only be modified by the owner via UpdateSettingContract.

Contract Account

An account type created upon smart contract deployment. Unlike an External Account, it is governed by contract code, has no private key, and cannot initiate transactions. It contains bytecode, storage, and resource parameters (consume_user_resource_percent, origin_energy_limit).

Contract Bandwidth Usage (Contract Bandwidth Consumption)

The amount of throughput capacity consumed by a smart contract during execution. For USDT TRC-20, a single transfer() call requires ~345 Bandwidth points. The cost is borne by the transaction initiator.

Contract Call (Smart Contract Call)

An operation that interacts with a smart contract function, requiring both Energy and Bandwidth. Every USDT TRC-20 transfer is a transfer() function call. Executed via a TriggerSmartContract transaction. To estimate resource consumption: use the wallet/triggerconstantcontract or wallet/estimateenergy API.

Contract Call Failure

An interruption of contract execution due to an error or insufficient resources. Common causes: OUT_OF_ENERGY (insufficient fee_limit), OUT_OF_TIME (exceeding the 80 ms limit), REVERT (logic error — e.g., insufficient balance). Consumed Energy is not refunded, except on REVERT (unused portion is returned).

Contract Deploy (Contract Deployment)

The process of placing a smart contract onto the TRON blockchain. The transaction includes bytecode and configuration parameters (consume_user_resource_percent, origin_energy_limit). It consumes a significant amount of Energy and Bandwidth. API: wallet/deploycontract.

Contract Energy Limit

The maximum Energy allowed for a single contract operation. Determined by the origin_energy_limit parameter set at deployment. It caps how much Energy the deployer is willing to spend per user call.

Contract Execution Cost

The total Energy and Bandwidth required to execute contract logic. For USDT TRC-20: ~64,285 Energy + ~345 Bandwidth (recipient has a balance), ~130,285 Energy + ~345 Bandwidth (new address). DeFi operations: 150,000–500,000+ Energy.

Contract Owner

The address with management rights over smart contract parameters: consume_user_resource_percent, origin_energy_limit, and others. Only the owner can update parameters via the UpdateSettingContract transaction.

Contract Resource Allocation

The mechanism governing how Energy and Bandwidth are sourced and consumed during contract operations. Energy consumption priority: delegated → own (staked) → TRX burn. The split between user and deployer is determined by consume_user_resource_percent.

Contract Resource Optimization

Best practices for reducing Energy and Bandwidth consumption during contract development: optimizing SSTORE (write: 20,000 vs. update: 5,000 Energy), minimizing SLOAD calls, using events instead of storage writes, employing efficient data structures, and batching operations.

Cost per Transaction (CPT)

The average resource or TRX cost per transaction. For USDT TRC-20: ~6.77 TRX (burn, recipient holds USDT) or ~13.37 TRX (new address). With Energy rental — ~2–6 TRX. A TRX transfer costs 0 TRX when free Bandwidth is available.

CPU-equivalent Instructions

TVM computational operations that determine Energy consumption. Each bytecode instruction has a fixed cost: SSTORE (write) — 20,000 Energy (new slot) / 5,000 (update); SLOAD (read) — 200 Energy; ADD/MUL — 3–5 Energy.

Cross-chain

Technology for transferring assets between blockchains. Cross-chain bridges enable moving USDT between TRC-20, ERC-20, BEP-20, and other networks. The fee model varies: on TRON — Energy + Bandwidth, on Ethereum — gas, on BSC — BNB gas.

Custodial Wallet

A wallet whose private keys are held by a third party (an exchange or service). The user does not control the keys and cannot independently manage resources (Energy, Bandwidth), stake TRX, or use Energy rental. The opposite is a non-custodial wallet, where the user holds the keys (TronLink, Trust Wallet, SafePal).

dApp (Decentralized Application)

An application built on smart contracts running on the TRON blockchain. Unlike conventional apps, a dApp’s logic is executed within the TVM and cannot be altered or halted by a third party. Examples on TRON: DEX platforms (SunSwap), lending protocols (JustLend), and stablecoins (USDD). Every user interaction with a dApp consumes Energy — the network’s computational resource.

Delegated Energy

The amount of Energy transferred from one account to another on the TRON network without moving TRX tokens. Delegated Energy is used by the recipient to execute transactions and smart contracts. The resource owner retains ownership of the underlying TRX and can reclaim the delegated Energy at any time (unless a lock period is set). Delegation is performed via the DelegateResourceContract transaction in Stake 2.0.

Delegating

The process of transferring Energy or Bandwidth from one wallet to another without transferring TRX ownership. Only Bandwidth and Energy can be delegated — TRON Power (voting power) is non-delegable. Delegation is limited to activated accounts and applies only to unused resources. A delegation transaction costs ~281–283 Bandwidth points.

DelegateResourceContract

The standard Stake 2.0 transaction type used to delegate Bandwidth or Energy to another address. Transaction parameters: recipient address, resource type (Bandwidth or Energy), amount in TRX, and an optional lock_period (lock duration in blocks; 1 block ≈ 3 seconds). All Energy rental services operate via DelegateResourceContract — they delegate the resource to the user’s wallet upon payment.

Delegation Limit

The maximum amount of Energy or Bandwidth that can be delegated from a single account to others on the TRON network. The limit is determined by the amount of staked TRX and the account’s current share of the total network stake. Only unused resources can be delegated — if you’ve already consumed part of your Energy on your own transactions, the available delegation capacity decreases accordingly.

Delegation Lock Period

A lock-up period set by the resource owner when delegating under Stake 2.0. During the lock period, the owner cannot reclaim the delegated Bandwidth or Energy. The period is specified in blocks (1 block ≈ 3 seconds). For example, lock_period = 28,800 blocks ≈ 24 hours. If no lock is set (lock_period = 0), the owner can reclaim the resource at any time.

The lock period is the foundation of Energy rental services: it guarantees that the rented resource will not be reclaimed before the paid period expires. This protects the renter’s interests at the blockchain level.

Delegation Pool

A combined pool of Energy and Bandwidth resources available for distribution across multiple wallets. Used by Energy rental services and large stakers to facilitate mass delegation to numerous recipients.

Delegation Queue

A list of active or pending resource delegation operations on the TRON network. The queue enables tracking the execution order and current status of delegations.

Delegation Reclaim

The process of returning delegated Bandwidth or Energy from the recipient back to the resource owner. Executed via the UnDelegateResourceContract transaction. Only possible after the lock period expires (if one was set) or at any time (if no lock was applied).

Upon reclaim, a reclamation mechanism applies: if the recipient has consumed a portion of the delegated resource, the owner’s available capacity is proportionally reduced until full recovery (linear over 24 hours). Reclamation formula: reclaimed resource = (reclaimed TRX / recipient’s total delegated stake) × recipient’s unrecovered resources.

Delegation Status

The current state of delegated resources: active (resource is available to the recipient), locked (lock period is in effect, reclaim is impossible), or reclaimed (resource has been returned to the owner). Delegation status is recorded on-chain and can be verified on Tronscan under the account’s “Resources” section.

Delegation Transaction

An on-chain operation that records the transfer of Energy or Bandwidth between accounts on the TRON network. This covers both delegation (DelegateResourceContract) and reclaim (UnDelegateResourceContract). Each transaction is recorded on the blockchain and requires Bandwidth.

Delegation Utilization

The actual volume of Energy or Bandwidth consumed by the recipient of delegated resources. This metric matters to the resource owner: upon reclaim, the reclamation penalty is calculated proportionally to utilization — the more the recipient has used, the more of the owner’s resources will be temporarily reclaimed.

DPoS (Delegated Proof of Stake)

The consensus mechanism of the TRON network. TRX holders vote for Super Representatives using TRON Power (1 staked TRX = 1 vote). The 27 nodes with the most votes earn the right to produce blocks. Votes are recalculated every maintenance cycle (every 6 hours). DPoS delivers a block time of ~3 seconds, throughput of ~2,000 TPS, and transaction finality in ~1 minute (19 confirmations out of 27 SRs).

Duplicate Transaction

A resubmission of an already-processed transaction on the TRON network. Each transaction has a unique hash (txID), and the network rejects transactions with matching hashes. Duplication can occur due to software bugs, double-clicking the send button, or rebroadcasting after a timeout.

Dynamic Energy Model

A TRON network mechanism that dynamically increases the Energy cost for frequently called smart contracts. The key parameter is energy_factor, recalculated every maintenance cycle (6 hours). Formula: actual consumption = base consumption × (1 + energy_factor).

For the USDT contract, energy_factor can reach 0.5 or higher, meaning a +50% increase over the base Energy cost. This is why typical USDT transfer costs (~64,285 / ~130,285 Energy) are higher than for less popular TRC-20 tokens. The mechanism protects the network from overload and incentivizes contract optimization.

The energy_factor value for a specific contract can be retrieved via the getcontractinfo API.

Energy (TRON Energy)

A blockchain resource on the TRON network representing the computational power (CPU) consumed by the TVM when executing smart contracts. 1 Energy unit corresponds to 1 millisecond of processing time. The more complex the contract logic and the longer its execution, the more Energy is required.

Energy is needed for all smart contract operations: USDT TRC-20 transfers, DeFi interactions, NFTs, and dApps. Unlike Bandwidth, free Energy is not automatically granted to accounts — it can only be obtained through TRX staking, delegation, or rental. When Energy is insufficient, the network automatically burns TRX at a rate of 0.0001 TRX per unit (100 sun).

Consumed Energy recovers linearly over 24 hours — approximately 1/28,800 of the spent amount is restored with each block (~3 seconds).

Energy Consumption

The amount of Energy used when executing smart contracts or TRC-20 transactions on the TRON network. Typical values: USDT transfer to an address with a balance — ~64,285 Energy; transfer to a new address — ~130,285 Energy; DeFi operations (swap, stake) — 150,000–500,000+ Energy; complex multi-contract calls — 1,000,000+ Energy.

Energy Deficit

An account state where the available Energy is insufficient to execute an operation without burning TRX. In a deficit scenario, the Energy Fee Fallback mechanism is automatically triggered — the missing Energy is compensated by burning TRX at a rate of 0.0001 TRX per unit.

Еnergy_factor

A dynamic multiplier applied to Energy consumption when calling popular contracts on the TRON network. It is part of the Dynamic Energy Model. Formula: actual consumption = base consumption × (1 + energy_factor). Recalculated every maintenance cycle (6 hours) based on contract call frequency. The value can be retrieved via the getcontractinfo API.

Energy Fee Fallback

A TRON network mechanism where insufficient Energy is automatically compensated by burning TRX. Rate: 1 Energy unit = 100 sun = 0.0001 TRX. It triggers automatically without warning — TRX is simply deducted from the balance. If neither Energy nor sufficient TRX is available, the transaction will fail. This mechanism is responsible for the ~6.43–13.03 TRX fee incurred when transferring USDT without resources.

Energy Limit

The maximum amount of Energy that can be consumed during a single transaction or smart contract call. Determined by the transaction’s fee_limit parameter (in sun). Recommended value for USDT TRC-20 transfers: at least 15,000,000 sun (15 TRX). If fee_limit is set too low, the transaction will fail with an OUT_OF_ENERGY error.

Energy Marketplace

Platforms and services where users can rent or provide Energy to reduce fees on the TRON network. They operate via the standard Stake 2.0 resource delegation mechanism. Examples: Tron Pool Energy and similar platforms. The Energy rental market processes over 1 million delegations per day.

Energy Pool (Network Energy Pool)

The fixed daily volume of Energy distributed among all staking participants on the TRON network proportionally to their stake. The current value is 180,000,000,000 (180 billion) Energy units per day. This is network parameter #19, modifiable only through a Committee Proposal vote. Formula: your Energy = (your TRX staked for Energy / total TRX staked for Energy network-wide) × 180,000,000,000.

Energy Recovery

The automatic process of gradual Energy restoration on a TRON account after consumption. Recovery occurs linearly over 24 hours: with each block (~3 seconds), approximately 1/28,800 of the consumed amount is restored. After 6 hours — ~25% recovered, after 12 hours — ~50%, full recovery — after 24 hours.

Energy Rental

A mechanism for temporarily obtaining Energy to execute transactions and smart contracts without needing to stake TRX. A rental service delegates Energy to your address via the standard TRON protocol (DelegateResourceContract). Only your public wallet address is needed — no private keys required. Renting Energy costs significantly less than burning TRX, with savings reaching up to 65%. Formats: hourly rental, transaction bundles, subscriptions, and API integration.

Energy Spike

A brief, sharp increase in Energy consumption, often associated with complex or mass operations: DeFi swaps, multi-contract calls, and batch USDT transfers. Can also be triggered by a rise in energy_factor for a popular contract under the Dynamic Energy Model.

Energy Surplus

An account state where the available Energy exceeds what is needed for typical transactions. Surplus Energy can be delegated to other accounts or offered through rental services to generate additional income.

Energy Utilization Rate

A metric reflecting the share of consumed Energy relative to the total Energy available on an account. A high utilization rate (>80%) signals the need to increase the stake or subscribe to an Energy rental service to meet demand.

ERC-20 / TRC-20 (Token Standards)

ERC-20 is the token standard on Ethereum; TRC-20 is its counterpart on TRON. Both define a set of mandatory functions (transfer, approve, balanceOf, totalSupply, etc.) that a token’s smart contract must implement. USDT exists in both standards: ERC-20 (Ethereum, fees paid in gas) and TRC-20 (TRON, fees paid in Energy). TRC-20 token transfers require Energy, while the earlier TRC-10 standard is implemented at the protocol level and requires only Bandwidth.

Еstimate energy (Energy Estimation API)

A TRON network API endpoint (wallet/estimateenergy) that allows pre-estimating the Energy consumption for a specific smart contract call. Available since Java-Tron v4.7.0.1. Returns energy_required — the total consumption including energy_factor. For nodes that do not support this method, the alternative is wallet/triggerconstantcontract. It is recommended to call this before every transaction for precise fee_limit configuration.

Estimated Energy Consumption

The projected amount of Energy needed to execute a transaction or smart contract. Used for preliminary fee estimation and fee_limit configuration. Estimates can be obtained via the wallet/estimateenergy or wallet/triggerconstantcontract APIs. Actual consumption may vary slightly due to the dynamic energy_factor coefficient.

Event (Smart Contract Event)

A logging mechanism for smart contract actions on the TRON blockchain. When a USDT TRC-20 transfer occurs, the contract emits a Transfer(from, to, value) event recorded in the transaction log. Events do not consume storage but do use Energy. They are used by wallets, explorers (Tronscan), and API services to track token transfers in real time.

Execution Fee (Smart Contract Execution Fee)

The fee for executing smart contract logic in the TVM, paid with Energy. When Energy is unavailable, the fee is covered by burning TRX (Energy Fee Fallback). For a USDT TRC-20 transfer, the Execution Fee amounts to ~6.43–13.03 TRX when fully burned. With Energy rental — ~2–6 TRX.

External Account

A TRON account type controlled by a private key and owned by the user. Unlike a Contract Account, an external account can initiate transactions, stake TRX, delegate resources, and vote for Super Representatives. Every activated external account receives 600 free Bandwidth points per day.

External Energy Source

Energy received by an account not through its own TRX staking, but from external sources: delegation from another account or rental via a service. When consuming Energy, the network uses external (delegated) resources first, then own (staked) resources, and only then resorts to burning TRX.

Energy Sharing Contract / origin_energy_limit (Energy Sharing Between User and Deployer)

A TRON network mechanism that allows a smart contract developer (deployer) to cover a portion of the Energy costs incurred during contract calls. Governed by two parameters:

consume_user_resource_percent (0 to 100) — the percentage of Energy paid by the user. The remainder is covered by the contract deployer from their own resources.

origin_energy_limit — the maximum Energy the deployer is willing to spend per single contract call.

For example, if consume_user_resource_percent = 30, the user pays 30% of the Energy while the deployer covers 70% (within the origin_energy_limit). In practice, most popular contracts, including USDT, set consume_user_resource_percent = 100% — meaning the user pays all Energy. This parameter is set at deployment and can only be changed by the contract owner.

Failed Transaction Fee

The Energy or TRX costs that are deducted even when a transaction fails on the TRON network. For OUT_OF_ENERGY and OUT_OF_TIME errors, all consumed Energy is lost. For a REVERT error (contract logic failure), the unused portion of Energy is returned, but the already-consumed amount is not recoverable. Bandwidth for transmitting the transaction data is consumed regardless of the outcome.

Fee

A charge for processing a transaction or executing a smart contract on the TRON blockchain. Unlike most blockchains, TRON fees can be fully offset by network resources — Energy and Bandwidth. If sufficient resources are available, no TRX fee is deducted and the transaction is effectively free. When resources are insufficient, the network automatically burns TRX.

Fee Estimation

A preliminary calculation of the expected Energy, Bandwidth, or TRX costs before executing a transaction. TRON provides API endpoints for estimation: wallet/estimateenergy (Energy calculation including energy_factor) and wallet/triggerconstantcontract (simulated contract call without writing to the blockchain). It is recommended to call these before every transaction for precise fee_limit configuration.

fee_limit

A transaction parameter on the TRON network that sets the maximum amount of TRX (in sun) that can be spent on Energy when calling a smart contract. If the actual Energy consumption exceeds fee_limit, the transaction fails with an OUT_OF_ENERGY error and all spent resources are lost.

Recommended value for USDT TRC-20: at least 15,000,000 sun (15 TRX). If the account has sufficient Energy (via staking, delegation, or rental), fee_limit is not consumed — it acts solely as a safety cap.

Fee Optimization

A set of methods for reducing TRX costs on TRON transactions. Key approaches: staking TRX to obtain Energy and Bandwidth (fee = 0), renting Energy (savings up to 65%), delegating resources between wallets, utilizing the free 600 daily Bandwidth points, and sending to addresses that already hold a USDT balance (~65,000 Energy instead of ~130,000).

Fee Structure

The set of rules governing fee calculation on the TRON network. Fees consist of two components: Energy (for smart contracts, ~95% of a USDT transfer fee) and Bandwidth (for data transmission, ~5%). Burn rates: Energy — 0.0001 TRX/unit, Bandwidth — 0.001 TRX/unit. Priority: delegated resources → own resources (staking) → free quota (Bandwidth) → TRX burn.

Finality (Transaction Finality)

The point after which a transaction is considered irreversible and cannot be canceled or modified. On TRON, finality is reached after confirmation by 19 out of 27 Super Representatives (solid block) — approximately 1 minute (~19 blocks × 3 seconds). Until finality, there is a theoretical risk of block reorganization. Most exchanges and services wait for a solid block before crediting funds.

Free Bandwidth

The daily throughput capacity allotted to every activated TRON account without staking — 600 points per day. Sufficient for 1 TRX transfer (~268 pts) or 1 USDT TRC-20 transfer (~345 pts) per day. Recovers linearly over 24 hours.

Freeze TRX / FreezeBalanceV2

The process of locking TRX on an account to obtain network resources under Stake 2.0. When freezing, the resource type is specified: Bandwidth or Energy. Resources are credited instantly. TRON Power is also granted simultaneously (1 TRX = 1 TP).

TRX remains the owner’s property and can be unfrozen with a 14-day waiting period. FreezeBalanceV2 differs from the deprecated FreezeBalance (Stake 1.0): it does not require a receiver_address; delegation is handled via a separate DelegateResourceContract transaction. API: wallet/freezebalancev2.

Freeze Period

Under Stake 2.0, there is no minimum freeze period — you can initiate unstaking at any time. However, once unstaking is triggered, a 14-day waiting period applies (network parameter #70), during which the TRX is inaccessible. Resources are revoked immediately when unstaking begins.

Frozen Balance

The amount of TRX currently in a frozen (staked) state, generating network resources. Frozen TRX is displayed separately from the available balance in wallets and on Tronscan. It cannot be transferred or spent until unfrozen. It generates Energy or Bandwidth (depending on the staking choice) and TRON Power.

Frozen Resource Allocation

The process of distributing Energy and Bandwidth obtained by freezing TRX. The resource amount is proportional: your share = your staked TRX / total staked TRX network-wide × daily pool. Daily Energy pool: 180 billion units (#19). Daily Bandwidth pool: 43.2 billion units (#62).

Full Node

A TRON network node that stores a complete copy of the blockchain and validates all transactions. It provides an HTTP API (port 8090) and gRPC API (port 50051) for network interaction: submitting transactions, querying balances, and estimating resources. Public Full Nodes are accessible via TronGrid (requires a TRON-PRO-API-KEY). For high-traffic applications, running a dedicated Full Node is recommended.

Gas Fee

A general term for the fee charged for executing transactions on a blockchain. On Ethereum, it is paid in ETH (gas × gas price). On the TRON network, the concept of “gas” is replaced by a resource model: Energy (smart contract computation) + Bandwidth (transaction data transmission). If sufficient resources are available, no TRX fee is deducted. This is TRON’s key differentiator: with enough Energy and Bandwidth, transactions are effectively free.

Gas Limit

The maximum amount of computational resources permitted for transaction execution. An Ethereum-native term. On the TRON network, the equivalent is fee_limit — the maximum TRX (in sun) that can be spent on Energy. Recommended fee_limit for USDT TRC-20: at least 15,000,000 sun (15 TRX).

Gas Optimization

A set of methods for reducing computational resource consumption during smart contract execution. In the TRON context: optimizing SSTORE operations (write: 20,000 Energy, update: 5,000), minimizing SLOAD calls, using events instead of storage, and employing efficient data structures. For end users: staking, renting Energy, and sending to addresses that already hold a USDT balance.

Gas-equivalent Cost

A benchmark metric for comparing transaction costs across TRON and other blockchains. USDT transfer: TRON (TRC-20) — ~6.77 TRX (~$1.5–2.5), with Energy rental — ~$0.5–1; Ethereum (ERC-20) — $2–15+; BSC (BEP-20) — $0.10–0.30; Solana (SPL) — $0.01–0.05.

Gasless Transaction

A transaction where the user does not pay the fee directly. On TRON, this is achieved in two ways: setting consume_user_resource_percent = 0 (the contract deployer covers Energy), or having a third party delegate Energy to the user’s wallet. Energy rental services enable a near-gasless model: the rental fee is significantly lower than burning TRX.

Get account resource (Account Resource API)

A TRON network API endpoint (wallet/getaccountresource) that returns the current resource state of an account: available and total Bandwidth and Energy, the amount of TRX frozen for each resource type, delegated resources, and limits. A critical endpoint for monitoring resources before transactions and deciding whether rental or staking is needed.

Get contract info (Contract Info API)

A TRON network API endpoint (wallet/getcontractinfo) that returns full smart contract information: consume_user_resource_percent, origin_energy_limit, current energy_factor (Dynamic Energy Model), bytecode, ABI, and other parameters. Used to calculate expected Energy consumption before a contract call, factoring in the dynamic coefficient.

Global Resource Limit

The aggregate cap on Energy and Bandwidth usage across the TRON network. Daily pools: Energy — 180,000,000,000 units (network parameter #19), Bandwidth — 43,200,000,000 units (parameter #62). Resources are distributed among all stakers proportionally to their share. Parameters can only be modified via a Committee Proposal (vote of 19 out of 27 SRs).

Governance (Network Governance)

The decision-making mechanism on the TRON blockchain. TRX holders stake their tokens, receive TRON Power (1 TRX = 1 TP), and vote for Super Representatives. The 27 SRs with the most votes produce blocks and manage network parameters. Votes are recalculated every 6 hours (00:00, 06:00, 12:00, 18:00 UTC). SRs can create Committee Proposals to modify network parameters.

Governance Proposal

A formal proposal to change TRON network parameters, submitted for Super Representative voting. Synonymous with Committee Proposal. Any of the 27 SRs can create a proposal. Approval requires 19 out of 27 SRs. Examples of adjustable parameters: Energy price, Bandwidth pool size, unstaking period, and maximum number of concurrent unstaking operations.

Hardware Wallet

A physical device for storing private keys offline, providing enhanced security for funds. The private key never leaves the device — transactions are signed internally. In the TRON context: hardware wallets (Ledger, Trezor) support TRX and TRC-20 tokens. Executing transactions from a hardware wallet requires Energy and Bandwidth — which can be delegated from another account.

Hash / txID (Transaction Hash)

A unique 64-character hexadecimal transaction identifier generated by the SHA-256 cryptographic function. Every TRON transaction has a unique txID, which can be used to track status, resource consumption (Energy, Bandwidth), and execution results on Tronscan. If a transaction with the same txID is resubmitted, the network will reject it.

Hex Address

The internal address format on the TRON network, prefixed with 41 (in hex). Length: 42 characters. Used in API calls and internal blockchain structures. For end users, the address is converted to Base58Check format (starting with “T”, 34 characters). Example: hex 41a614f803b6fd780986a42c78ec9c7f77e6ded13c → Base58 TQn7aGHkLGKf6sT6vSaNwSBg...

High Energy Consumption

A state where transactions or smart contracts consume a significant amount of Energy. Typical examples: USDT transfer to a new address (~130,285 Energy), DeFi operations (150,000–500,000+ Energy), and multi-contract calls (1,000,000+ Energy). High consumption can be amplified by the Dynamic Energy Model (energy_factor) for popular contracts.

Historical Energy Usage

Data on an account’s or contract’s Energy consumption over past periods. Used for analysis, demand forecasting, and planning staking or rental strategies. Available via Tronscan (account “Resources” section), TronGrid API, and analytics services. Enables calculating average daily demand and the optimal staking volume.

Hot Wallet

A wallet that is permanently connected to the internet and used for active operations and frequent transactions. In the TRON context: a hot wallet is the primary operational tool for USDT transfers, DeFi interactions, and everyday transactions. It requires a constant supply of Energy and Bandwidth. Examples: TronLink (browser extension and mobile app), Trust Wallet, SafePal.

Hot Wallet Energy Management

The practice of optimizing Energy and Bandwidth usage on a wallet used for regular transactions. Includes: monitoring resource balances before each send, subscribing to Energy rental or staking TRX, splitting wallets into a storage account (staking) and an operational account (receives delegated resources), and configuring auto-replenishment via API.

Hot Wallet Risk

The set of threats associated with a wallet being permanently connected to the internet. Key risks: phishing (fake websites and apps), malicious approval transactions (unlimited approve to a fraudulent contract), private key compromise, and address substitution during copy-paste. Recommendations: avoid storing large amounts on a hot wallet, verify approval limits, and use a hardware wallet for long-term storage.

HTTP API / gRPC API (Node Interaction Interfaces)

The two primary protocols for interacting with TRON nodes. HTTP API (port 8090) — a REST interface for wallet/ calls (Full Node) and walletsolidity/ calls (Solidity Node). gRPC API (port 50051) — a binary protocol, faster for high-throughput applications.

Public access via TronGrid requires an API key (TRON-PRO-API-KEY). Key endpoints: wallet/createtransaction (TRX transfer), wallet/triggersmartcontract (contract call), wallet/freezebalancev2 (staking), wallet/estimateenergy (Energy estimation).

Hybrid Wallet

A wallet type that combines elements of hot and cold storage to balance security and convenience. In the TRON context: the bulk of TRX and USDT is stored on a hardware wallet (cold storage), while the operational portion resides on a hot wallet with Energy and Bandwidth. Resources are delegated from the staking account to both wallets as needed.

Insufficient Balance

An account state in which the wallet does not have enough TRX or tokens to execute a transaction. In the TRON network, this may occur in several cases: insufficient TRX to pay the transaction fee when Energy/Bandwidth is lacking, insufficient USDT for a transfer, insufficient TRX to activate a new address (1 TRX). The balance can be checked before a transaction via the API wallet/getaccount.

Insufficient Energy / Insufficient Bandwidth

An account state in which the available resources are insufficient to execute a transaction without burning TRX.

When Energy is insufficient, the network automatically burns TRX at a rate of 0.0001 TRX per unit (Energy Fee Fallback). When Bandwidth is insufficient — 0.001 TRX per unit (Bandwidth Fee Fallback). If there are neither resources nor TRX available on the balance, the transaction will fail with an error.

Note: the terms Insufficient Energy and Insufficient Bandwidth are combined because they describe the same mechanism — Fee Fallback.

Internal Transaction

An operation executed within a smart contract during its execution — one contract calling another. In TRON, internal transactions are visible on Tronscan in the “Internal Transactions” tab of the main transaction. They consume Energy from the total fee_limit of the parent transaction.

A typical example: during a swap on SunSwap, the main contract calls token contracts to move funds.

Internal Call Trace

A detailed breakdown of the sequence of internal calls between smart contracts during transaction execution in the TRON network. It shows: which contracts were called, in what order, how much Energy each call consumed, and what data was passed.

Available via Tronscan (the “Internal Txns” tab) and the API wallet/gettransactioninfobyid.

Invalid Transaction

A transaction rejected by the TRON network due to errors. Typical causes: invalid signature (incorrect private key), expired transaction (expiration), duplicate txID, insufficient TRX balance for fee_limit, incorrect data format.

A rejected transaction is not recorded on the blockchain and does not consume resources.

Invocation Cost

The total Energy and Bandwidth consumption required to call a smart contract function. Includes: Energy for TVM computation (the main part) + Bandwidth for transaction data transmission.

For USDT TRC-20 transfer():
~64,285 Energy + ~345 Bandwidth (address with existing balance)
or ~130,285 Energy + ~345 Bandwidth (new address).

It can be estimated in advance via the API wallet/estimateenergy.

I/O Overhead

Additional computational operations involved in processing data in smart contracts that increase Energy consumption. The main source of I/O overhead in TRON is storage operations:

• SSTORE (write to storage): 20,000 Energy for a new slot, 5,000 for an update
• SLOAD (read): 200 Energy
  

Optimizing I/O operations is a key method for reducing Energy consumption during smart contract development.

Ledger Balance

The actual balance of TRX and tokens recorded in the distributed blockchain ledger after confirmation of all transactions. It does not include frozen (staked) funds that are temporarily unavailable for transfer, nor TRX in the unstaking process (14-day waiting period). The full balance (available + frozen + pending) can be checked via the API wallet/getaccount.

Legacy Stake / Stake 1.0

The outdated staking model in the TRON network, replaced by Stake 2.0.

Key limitations of Stake 1.0:

• delegation only to one address at the time of freezing,
• only full unfreeze (no partial unstaking),
• no delegation timelock,
• no parallel unstaking,
• no unstaking cancellation.
  

Stake 1.0 is still supported for backward compatibility, but all new operations should be performed via Stake 2.0.

Limit of Resources

The maximum amount of Energy or Bandwidth that an account can use within 24 hours. It is determined proportionally to the user’s share of frozen TRX relative to the total network stake.

Formulas:
Your Energy = (your TRX staked for Energy / total TRX staked for Energy) × 180 billion
Your Bandwidth = (your TRX staked for Bandwidth / total TRX staked for Bandwidth) × 43.2 billion

Plus 600 free Bandwidth per day for each account.

Liquidity Provider Energy

Energy consumption incurred when adding or removing liquidity in decentralized protocols (for example, SunSwap, JustLend). Such operations typically consume 2–5 times more Energy than a regular USDT transfer due to the complexity of smart contract logic: multiple SSTORE operations, pool ratio calculations, and LP token updates.

Typical consumption: 200,000–500,000+ Energy.

Liveness

A measure of the continuous operation of the TRON network. It is ensured by 27 Super Representatives who generate blocks approximately every ~3 seconds.

To maintain liveness, it is sufficient for 2/3+1 SR (19 out of 27) to operate. If an SR misses its slot, the next SR produces the block.

TRON’s liveness is among the highest in the blockchain industry: the network has operated continuously since launch.

lock_period

A timelock parameter used when delegating resources in Stake 2.0. It is specified in blocks (1 block ≈ 3 seconds). During the lock_period, the owner cannot reclaim delegated Energy or Bandwidth.

Examples:
lock_period = 28,800 ≈ 24 hours
lock_period = 403,200 ≈ 14 days

If lock_period = 0, resources can be reclaimed immediately.

The timelock mechanism is fundamental for Energy rental services: it guarantees resource availability for the paid period.

Lock-up Period / Unstaking Period

A 14-day time interval (network parameter #70) during which TRX remain unavailable after initiating unstaking in Stake 2.0.

Important: resources (Energy/Bandwidth) and TRON Power are revoked immediately upon initiating unstaking — the 14-day waiting period applies only to withdrawing TRX back to the available balance.

Up to 32 unstaking operations can run in parallel. Cancellation is possible via CancelAllUnfreezeV2.

Lost Energy

Energy irreversibly consumed during failed transaction execution. Occurs in OUT_OF_ENERGY errors (insufficient fee_limit) and OUT_OF_TIME errors (exceeded 80 ms limit) — all allocated Energy or its TRX equivalent is burned.

In case of REVERT, unused Energy is refunded, but the portion already consumed for computation is not.

Recommendation: always check estimated consumption via estimateenergy before submitting a transaction.

Maintenance Period

A 6-hour cycle for vote recalculation and network parameter updates on TRON. Cycles begin at: 00:00, 06:00, 12:00, and 18:00 UTC (4 times daily). Each cycle includes: counting TRON Power votes and electing 27 Super Representatives, updating energy_factor for contracts (Dynamic Energy Model), distributing SR rewards (16 TRX per block + 160 TRX in voting rewards), and applying approved Committee Proposals.

Malicious Contract

A smart contract designed to steal tokens, abuse permissions, or gain unauthorized access to a wallet. Common attack vectors include: infinite approve (the contract gains unlimited access to tokens), phishing contracts (disguised as legitimate ones), and honeypot contracts (allow buying a token but not selling). Protection: verify approve limits, avoid interacting with unknown contracts, and use verified dApps.

Mass Distribution

The process of simultaneously sending funds or tokens to a large number of addresses. On the TRON network, each transfer is a separate transaction consuming Energy and Bandwidth. Mass distribution of USDT to 100 addresses requires approximately 6,400,000–13,000,000 Energy + 34,500 Bandwidth. For optimization: stake or rent Energy, and send to addresses with existing USDT balances (saves 50% Energy).

Memo

An optional text field transmitted alongside a transaction on the TRON blockchain. Used for comments, payment identifiers, or service information. A memo increases transaction size and consequently Bandwidth consumption (each character = 1 additional byte = 1 Bandwidth). Memos do not affect Energy consumption.

Mempool

A queue of unconfirmed transactions on the TRON network awaiting inclusion in a block. Unlike Ethereum, where the mempool can become congested, TRON confirms transactions approximately every 3 seconds, so the mempool typically clears quickly. During high load, priority is determined by Super Representatives, not gas price.

Message Size

The transaction data volume in bytes, which directly determines Bandwidth consumption (1 byte = 1 Bandwidth). Size varies by transaction type: TRX transfer — approximately 268 bytes; USDT TRC-20 transfer — approximately 345 bytes; Energy delegation — approximately 281–283 bytes. Adding a memo or complex parameters increases size and Bandwidth consumption.

Mint / Burn

The processes of issuing new tokens (mint) and destroying them (burn) to manage supply and stability. In the TRON context: Tether performs mint to increase TRC-20 USDT supply and burn to reduce it. Mint/burn operations on the USDT contract can only be executed by the contract owner address. Not to be confused with Burn TRX — the burning of TRX coins when paying fees.

Misconfigured Contract

A smart contract with incorrect parameters leading to increased Energy consumption or execution failures. Common errors include: consume_user_resource_percent = 0 when the deployer has no Energy (user doesn't pay, deployer can't — transaction fails), overly low origin_energy_limit, unoptimized SSTORE operations, and missing code validations.

Monitoring Dashboard

An interface for tracking transactions, balances, and Energy/Bandwidth usage on the TRON network. Primary tools: Tronscan (tronscan.org) — a public explorer with a "Resources" section for each account; TronGrid API — programmatic access for monitoring automation; third-party dashboards for businesses aggregating data across multiple wallets.

Monthly Energy Usage

The total Energy consumed by an account or project over a calendar month. Used for planning staking and rental needs. Example calculation: 10 USDT transfers per day × ~65,000 Energy × 30 days = ~19,500,000 Energy/month. When burning TRX, this equals ~1,950 TRX/month. With Energy rental — savings of up to 65%.

Multi-account Resource Pool

A shared reserve of Energy and Bandwidth used by multiple wallets within a single system. Implemented through centralized staking on one account with subsequent resource delegation to operational wallets via DelegateResourceContract. Allows flexible resource redistribution based on each wallet's needs.

Multi-signature Wallet

A wallet requiring multiple independent signatures to confirm operations. On TRON, multi-signature is configured via Account Permission Update by specifying a threshold — the minimum "weight" of signatures required to confirm a transaction. Each key is assigned a weight, and the transaction is approved if the sum of signers' weights >= threshold. Important: accounts activated before Stake 2.0 may lack permissions for FreezeBalanceV2, DelegateResource, and other operations — updating Active Permission via the operations field is required.

Multi-wallet Management

A management model where transactions and resources are distributed across multiple wallets. Typical architecture: vault (TRX staking + delegation), operational wallets (receive resources, execute transfers), hot wallet (daily operations), cold wallet (large sum storage). Delegation via Stake 2.0 enables centralized resource management.

Network Congestion

A state of high activity on the TRON network. Unlike Ethereum, where congestion increases gas prices, TRON has no direct impact on transaction costs — the Energy price is fixed. However, the Dynamic Energy Model increases Energy consumption for frequently called contracts (energy_factor), effectively raising costs during high load on specific contracts (e.g., USDT).

Network Fee

The fee for processing transactions on TRON. Comprises two components: Energy (for smart contracts) and Bandwidth (for data transmission). Can be fully offset by resources — resulting in zero TRX fee. When resources are insufficient, the network automatically burns TRX: Energy at 0.0001 TRX/unit, Bandwidth at 0.001 TRX/unit.

Network Load

The current activity level on the TRON network: transactions per second, smart contract call volume, and resource consumption. Load affects the energy_factor of popular contracts (Dynamic Energy Model). Load monitoring is available on Tronscan under the "Dashboard" and "Contracts" sections.

Network Parameters

The set of configurable TRON parameters that govern network behavior. Key parameters: #4 — Energy burn price (100 sun = 0.0001 TRX); #11 — Bandwidth burn price (1,000 sun = 0.001 TRX); #19 — daily Energy pool (180 billion); #62 — daily Bandwidth pool (43.2 billion); #70 — unstaking period (14 days); #78 — maximum parallel unstakes (32). Modified via Committee Proposal (19 of 27 SRs required).

Network Throughput

The number of transactions TRON can process per unit of time. Current capacity is approximately 2,000 TPS (transactions per second). A block is produced every ~3 seconds by one of 27 Super Representatives. For comparison: Ethereum ~30 TPS, Bitcoin ~7 TPS, Solana ~4,000+ TPS.

Node

A computer or server participating in maintaining the TRON blockchain. Node types: Full Node — stores a complete blockchain copy, provides HTTP API (port 8090) and gRPC API (port 50051); Solidity Node — stores confirmed (solid) blocks, API walletsolidity/; Super Representative Node — Full Node + block production. Public nodes are accessible via TronGrid (requires TRON-PRO-API-KEY).

Node Synchronization

The process of updating a node's data to match the current state of the TRON blockchain. Full synchronization of a Full Node takes considerable time due to blockchain size. Fast synchronization is available via snapshot (blockchain snapshot). A node is considered synchronized when its latest block matches the network's latest block.

Node Validation

The process by which TRON network nodes verify transactions and blocks before adding them to the blockchain. Includes: signature verification, transaction format validation, resource sufficiency checks (Energy, Bandwidth, TRX), smart contract logic execution in TVM, and block integrity verification (previous block hash, SR signature).

Non-custodial Wallet

A wallet where the user has complete control over private keys and access to funds. No third party can block or confiscate funds. In the TRON context: allows independent resource management (Energy, Bandwidth), TRX staking, Energy rental, and delegation. Examples: TronLink, Trust Wallet, SafePal, Ledger. The opposite is a Custodial Wallet.

Network Monitoring

Real-time tracking of TRON network status: load, transaction confirmation speed, SR performance, and resource consumption. Tools: Tronscan Dashboard (tronscan.org), TronGrid API for programmatic monitoring, Node Tracker for SR performance tracking.

Network Resource Allocation

The mechanism for distributing Energy and Bandwidth among accounts on TRON. Resources are allocated proportionally based on each participant's stake relative to the total. Formula: account's share = their staked TRX / total staked TRX × daily pool. Daily pools: Energy — 180 billion (#19), Bandwidth — 43.2 billion (#62).

Network Stability

TRON's ability to maintain uninterrupted operation under high load. Ensured by: the DPoS mechanism (27 SRs produce blocks in rotation), redundancy (if an SR misses a block, the next one takes over), Dynamic Energy Model (protection against overloading popular contracts), and fast finality (~1 minute).

Network Upgrade

The process of implementing changes to the TRON protocol. Major upgrades (e.g., Stake 2.0, Dynamic Energy Model) require node software updates. Minor parameter changes (Energy price, pool sizes) are executed via Committee Proposal without software updates. Upgrade history is available in the java-tron repository on GitHub.

Nonce

Unlike Ethereum, where nonce is a sequential account transaction counter, TRON does not use a nonce in the traditional sense. Transaction uniqueness is ensured through: timestamp, expiration, and unique txID (SHA-256 hash of transaction data). If a txID matches an already processed transaction, the network will reject it.

Off-chain Calculation

Preliminary calculation of transaction parameters outside the blockchain to estimate Energy consumption and fees. Primary tools on TRON: wallet/triggerconstantcontract (simulates a contract call without writing to the blockchain or consuming resources), wallet/estimateenergy (Energy estimation accounting for energy_factor). Recommended before every transaction for accurate fee_limit configuration.

On-chain Transaction

A transaction recorded directly on the TRON blockchain and publicly verifiable via Tronscan. Includes: TRX transfers, TRC-20 token transfers (USDT), smart contract calls, staking, delegation, and voting. Every on-chain transaction consumes Bandwidth, and contract calls also consume Energy.

On-chain Execution

The process of executing a transaction or smart contract directly on the TRON blockchain. Contract logic is executed in the TVM on every node, and the result is recorded in the block. Execution consumes Energy (computations) and Bandwidth (data transmission). Results can be verified via the wallet/gettransactioninfobyid API: status, resource consumption, and event logs.

Operational Wallet

A wallet used for daily operations and frequent transactions. In an optimal architecture: the operational wallet does not hold large sums, receives Energy and Bandwidth via delegation from a vault account (staking), and executes USDT transfers and contract interactions. This improves security — if compromised, only the operational balance is at risk.

Optimization Strategy

A set of approaches to reduce Energy, Bandwidth, and TRX consumption for TRON operations. Key strategies: TRX staking (zero fees with sufficient stake), Energy rental (up to 65% savings compared to burning), resource delegation between wallets, sending USDT to addresses with existing balances (~65,000 instead of ~130,000 Energy), utilizing the free 600 Bandwidth, and configuring accurate fee_limit.

origin_energy_limit

A smart contract parameter defining the maximum Energy the deployer (contract creator) is willing to spend from their own resources per call. Works in conjunction with consume_user_resource_percent: if consume_user_resource_percent = 40, the user pays 40% of Energy, the deployer pays up to 60% (but not exceeding origin_energy_limit). Set during deployment and modified via UpdateEnergyLimitContract. For the USDT contract: origin_energy_limit = 0 (deployer pays nothing, consume_user_resource_percent = 100).

Out of Bandwidth

An error occurring when the account lacks sufficient Bandwidth and TRX. If TRX is available, the network automatically burns it at 0.001 TRX per unit (Bandwidth Fee Fallback) and the transaction proceeds. If neither Bandwidth nor TRX is available, the transaction is rejected. Solution: stake TRX for Bandwidth, receive delegation from another account, or top up your TRX balance.

Out of Energy (OUT_OF_ENERGY)

A smart contract execution error occurring when fee_limit is exhausted but Energy is insufficient to complete the operation. The transaction fails (USDT is not sent), but all consumed resources — Energy and TRX — are deducted irreversibly. Primary cause: fee_limit set too low. Solution: increase fee_limit to at least 15 TRX for USDT, or ensure the account has Energy (via staking/rental/delegation).

Overconsumption Risk

The probability of exceeding Energy or Bandwidth limits during mass or complex operations. Risk factors: increased energy_factor (Dynamic Energy Model) for popular contracts, sending to new addresses (2× Energy), DeFi operations (3–5× Energy), and batch distributions. Mitigation: monitor resources before transactions, auto-replenish Energy via API, and maintain fee_limit headroom.

Owner Permission

The highest permission level for a TRON account. Owner Permission grants full control over the account: modifying all permissions (Active, Owner, Witness), updating keys, and managing staking and delegation. By default, it's bound to the account creator's address. Multi-signature can be configured with a threshold. Important: losing Owner Permission means losing complete control over the account.

Partial Execution (Partial Execution)

A situation in which a smart contract was executed only partially due to insufficient resources or an error. In case of partial execution, all contract state changes are reverted (REVERT), but the consumed Energy is not refunded. A typical cause is that the fee_limit is too small to complete all contract operations.

As a result: USDT is not sent, but Energy/TRX are deducted.

PBFT (Practical Byzantine Fault Tolerance)

A mechanism that ensures transaction finality (the impossibility of reversal after confirmation) in the TRON network. PBFT complements the main DPoS consensus: after a block is produced by a Super Representative, 19 out of 27 SR must confirm it to achieve solid block status. Finalization occurs in approximately 1 minute (~19 blocks × 3 seconds). Before finalization, there is a theoretical risk of reorganization.

Peak Energy Usage

The maximum amount of Energy consumed by an account or contract over a specific period. Peak loads occur during mass USDT distributions, DeFi operations (swaps, liquidity provision), or batch contract calls. Monitoring peak usage helps plan staking or Energy rental with a reserve. Data is available via Tronscan and the TronGrid API.

Pending Transaction

A transaction that has been sent to the network but has not yet been included in a block. In TRON, transactions are confirmed approximately every ~3 seconds, so the pending status is usually short-lived. If a transaction is not confirmed before the expiration time (default 60 seconds), it is rejected. Reasons for delay: incorrect format, SR overload, node issues.

Permission Control

A mechanism for configuring access rights to a TRON account. There are three levels: Owner Permission (full control — changing keys and permissions), Active Permission (operational rights — transfers, staking, delegation, contract calls), Witness Permission (for SR nodes — block production). Each level supports multisignature with a configurable threshold. Configured via Account Permission Update.

Permission Update

An operation that modifies account access rights via the AccountPermissionUpdateContract transaction. Allows: adding or removing keys, changing the threshold (signature threshold), configuring permitted operations (the operations field). Important: accounts created before Stake 2.0 may not have permissions for FreezeBalanceV2 and DelegateResource — these must be added through an Active Permission update.

Pre-execution Check

An analysis of transaction parameters before submission. In TRON, it is performed via: wallet/triggerconstantcontract (simulation without writing to the blockchain), wallet/estimateenergy (Energy estimation taking energy_factor into account), wallet/getaccountresource (checking available resources). Recommended before every transaction to configure fee_limit properly and prevent OUT_OF_ENERGY errors.

Price per Energy Unit

The cost of one unit of Energy. When burning TRX: fixed price of 100 sun = 0.0001 TRX (network parameter #4). When renting: market price, significantly lower — savings of up to 65%. The rental price depends on supply and demand in the Energy market and is not regulated by the protocol. Comparison: 65,000 Energy when burning = 6.5 TRX, when renting = ~2–3 TRX.

Private Key

A secret cryptographic key (a 256-bit number) that provides full access to funds and wallet operations in TRON. From the private key, a public key is generated, and from it — the address (T...). Never share your private key with third parties. Storage: hardware wallets (Ledger, Trezor), mnemonic phrase (seed phrase), encrypted storage solutions.

Proof of Stake / DPoS

A consensus mechanism in which participation in maintaining the network is carried out through staking assets. TRON uses Delegated Proof of Stake (DPoS) — TRX holders vote for 27 Super Representatives who produce blocks. Unlike PoW (Bitcoin), DPoS does not require computational power — security is ensured through economic incentives and voting.

Protocol Parameters

TRON network settings that determine blockchain behavior. Key parameters: #4 — Energy price (100 sun); #11 — Bandwidth price (1,000 sun); #19 — Energy pool (180 billion); #62 — Bandwidth pool (43.2 billion); #70 — unstaking period (14 days); #78 — maximum parallel unstakes (32). Modified through a Committee Proposal (19 out of 27 SR). Synonym: Network Parameters.

Public Address

A TRON wallet address starting with “T” (34 characters, Base58Check). It can be safely shared with third parties to receive TRX, USDT, and other tokens. It does not contain information about the private key. To delegate Energy and Bandwidth to another account, it is sufficient to know only the recipient’s public address — private keys are not required.

Public Key

An open cryptographic key generated from the private key using the ECDSA (secp256k1) algorithm. Used for: generating a TRON address (T...), verifying transaction signatures. The public key can be safely disclosed — it is impossible to derive the private key from it.

Ниже — полный точный перевод без сокращений, без упрощений и без добавления новых смыслов. Все параметры, цифры и технические названия сохранены.

Reclaim Resources / UnDelegateResource

The process of withdrawing previously delegated Energy or Bandwidth via the UnDelegateResourceContract transaction. It is possible immediately (if the delegation was made without a timelock) or after the end of the lock_period. Upon reclaiming, a reclamation mechanism applies: if the recipient has consumed part of the resource, the owner’s available amount is reduced proportionally until full recovery (linearly over 24 hours).

Regeneration Cycle

A recurring 24-hour cycle of linear recovery of Energy and Bandwidth after use. Mechanism: with each block (~3 seconds), approximately 1/28,800 of the consumed amount is restored. After 6 hours — ~25%, after 12 hours — ~50%, after 24 hours — 100%. The cycle is identical for both resource types. The free 600 Bandwidth also regenerates according to this principle.

Rental Duration

The period during which rented Energy remains available in the wallet. It is determined by the lock_period parameter during delegation (in blocks, 1 block ≈ 3 sec). Typical formats: hourly rental (lock_period ≈ 1,200 blocks = 1 hour), daily (28,800 blocks), weekly (201,600 blocks). The timelock guarantees that the resource will not be withdrawn before the end of the paid period.

Resource Budgeting

Calculation and allocation of Energy and Bandwidth for stable operation. Example: 50 USDT transfers/day × ~65,000 Energy = ~3,250,000 Energy/day. Coverage options: staking ~300,000+ TRX (depends on network share), Energy rental (~1,100–2,200 TRX/day when burning → ~400–800 TRX/day when renting), or a combination of staking and rental for peak loads.

Resource Delegation

Transfer of Energy or Bandwidth from one account to another without transferring TRX. Executed via DelegateResourceContract in Stake 2.0. Key rules: only unused resources can be delegated, only to activated accounts, TRON Power cannot be delegated. Parameters: resource type, amount (in TRX), recipient address, optional lock_period.

Resource Forecasting

Analysis of future Energy and Bandwidth consumption based on current activity and transaction history. Tools: Historical Energy Usage (Tronscan), API wallet/getaccountresource (current limits), estimateenergy (calculation for a specific operation). Allows advance planning of staking or rental and avoidance of excessive TRX spending.

Resource Limit

The maximum amount of Energy or Bandwidth available to an account within 24 hours. Formulas: your Energy = (your TRX staked for Energy / total TRX staked for Energy) × 180 billion; your Bandwidth = (your TRX staked for Bandwidth / total TRX staked for Bandwidth) × 43.2 billion + 600 free. The limit includes both own and delegated resources.

Resource Model TRON

A unique transaction fee system in the TRON network using two types of resources instead of direct fees: Energy (smart contract computation, 1 unit = 1 ms CPU) and Bandwidth (data transmission, 1 unit = 1 byte). Resources are obtained via TRX staking, delegation, or rental. If sufficient resources are available, the transaction is free (0 TRX). If insufficient — automatic TRX burn occurs.

Resource Surplus / Deficit

Account state classification: surplus — more resources than needed (can be delegated or provided for rental to earn income); deficit — insufficient resources (the network burns TRX via Fee Fallback). Monitoring is done through wallet/getaccountresource and Tronscan.

Resource Usage Monitoring

Tracking Energy and Bandwidth consumption to optimize operations and prevent errors. Tools: Tronscan (account “Resources” section), TronGrid API (wallet/getaccountresource), automated dashboards for businesses. It is recommended to check resources before each transaction and configure alerts when levels drop below a threshold.

Resource Utilization Rate

The proportion of used Energy and Bandwidth relative to the total available amount. A high rate (>80%) is a signal to increase staking or enable rental. A low rate (<20%) indicates excess resources that can be delegated. Calculation: (used resources / total limit) × 100%.

Retry Transaction

A repeated attempt to send a transaction after unsuccessful execution. In TRON, each transaction must have a unique txID — it is not possible to simply resend the same transaction. A new transaction must be created with an updated timestamp and expiration. Before retrying: replenish Energy (staking/rental), increase fee_limit, and verify balance.

REVERT

A smart contract execution error in which all state changes are rolled back: tokens are not moved, storage is not updated. However, part of the Energy consumed for computation before the REVERT is not refunded — only the unused portion is returned. Typical causes: insufficient token balance, failed require() condition, overflow. Bandwidth for data transmission is fully consumed.

Seed Phrase / Mnemonic

A set of 12 or 24 words used to back up and restore a wallet’s private key. Generated when creating a wallet according to the BIP-39 standard. From a single seed phrase, all account addresses and keys can be restored. Never share your mnemonic phrase with third parties — it provides full access to all funds.

Shared Resource Pool

A reserve of Energy and Bandwidth distributed across multiple wallets. Implemented through centralized staking on one account with subsequent delegation of resources to operational wallets via DelegateResourceContract. Allows flexible redistribution of resources as needed.

Smart Contract

A program on the TRON blockchain that automatically executes predefined conditions without intermediaries. Written in Solidity or Java, compiled into bytecode and executed in TVM. Each interaction consumes Energy. Examples: USDT TRC-20 contract (stablecoin transfers), SunSwap (DEX), JustLend (lending). The contract code is immutable after deployment, but parameters (consume_user_resource_percent, origin_energy_limit) can be updated by the owner.

Smart Contract Execution

The process of executing contract logic in TVM. Stages: 1) receiving a TriggerSmartContract transaction, 2) loading contract bytecode, 3) executing instructions with Energy consumption, 4) updating contract storage, 5) emitting events, 6) recording the result in a block. Execution limit: 80 ms (if exceeded — OUT_OF_TIME error).

Smart Contract Security

Practices for protecting contracts against vulnerabilities. Main risks in TRON: unlimited approve (attacker gains access to tokens), reentrancy attacks (repeated function entry), integer overflow. Protection measures: code audits, limited approve allowances, use of trusted libraries (OpenZeppelin), verifying contracts before interaction.

Solidity Node

A TRON node type that stores only confirmed (solid) blocks — blocks confirmed by 19 out of 27 SR. Provides the walletsolidity/ API for queries guaranteeing finalized data. Unlike a Full Node (wallet/), a Solidity Node does not contain unconfirmed transactions. Used for reliable retrieval of balances, transaction history, and contract state.

Stablecoin Transfer

Transfer of stablecoins (USDT, USDC, TUSD, etc.) between addresses in the TRON network. All TRC-20 stablecoins are smart contract calls requiring Energy + Bandwidth. Consumption for USDT: ~64,285 Energy + ~345 Bandwidth (address with balance), ~130,285 Energy + ~345 Bandwidth (new address). TRON processes more than 60% of all USDT transfers worldwide.

Stake 2.0

The updated staking model of TRON, replacing Stake 1.0. Key advantages: flexible delegation (multiple addresses at any time), partial unstaking (any amount), delegation timelock (lock_period), up to 32 parallel unstakes, unstake cancellation (CancelAllUnfreezeV2), proportional reclamation upon delegation withdrawal. API: freezebalancev2, unfreezebalancev2, delegateresource, undelegateresource.

Stake Lock Period

In Stake 2.0, there is no minimum freezing period — unstaking can be initiated at any time. After initiation, a 14-day waiting period applies (network parameter #70). Resources (Energy/Bandwidth) and TRON Power are revoked immediately upon initiating unstaking. After 14 days, TRX are withdrawn via WithdrawExpireUnfreeze.

Stake Reward

A reward for participating in staking and voting for Super Representatives. Formed from: 16 TRX per block (8 TRX block reward + 8 TRX vote reward) + 160 TRX in voting rewards every 6 hours. Rewards are distributed between SR and their voters. Each SR sets its own redistribution share. To receive rewards, it is necessary to stake TRX, vote for SR, and claim the reward (RewardBalance).

Stake Weight

A metric determining the amount of resources and voting power of an account. Weight = amount of staked TRX. The more TRX staked, the more Energy/Bandwidth the account receives (proportional to total network stake) and the more TRON Power for voting (1 TRX = 1 TP).

Staking

The process of freezing TRX to obtain blockchain resources. When staking, a resource type is selected: Bandwidth or Energy. TRON Power (1 TRX = 1 TP) is credited simultaneously for voting. TRX are not spent — they are locked and can be unstaked (14-day waiting period). Resources are credited instantly and regenerate linearly over 24 hours. Synonym: Freeze TRX.

Storage

Permanent memory of a smart contract in the TRON blockchain, organized as key-value pairs (256-bit). Storage operations are the most expensive in terms of Energy: SSTORE (writing a new value) — 20,000 Energy, SSTORE (update) — 5,000 Energy, SLOAD (read) — 200 Energy. When transferring USDT, the main part of Energy consumption is spent on updating balances in the contract storage.

Sun

The smallest indivisible unit of TRX. 1 TRX = 1,000,000 Sun. Used in fee calculations, transaction parameters (fee_limit is specified in sun), and API calls. Examples: Energy price when burning = 100 sun (0.0001 TRX), Bandwidth price when burning = 1,000 sun (0.001 TRX), fee_limit = 15,000,000 sun (15 TRX).

SunSwap

The main DEX (decentralized exchange) in the TRON ecosystem. Allows swapping TRC-20 tokens without intermediaries via the AMM (automated market maker) mechanism. Swap operations consume significantly more Energy than a regular USDT transfer: ~150,000–300,000 Energy per swap. Adding/removing liquidity — ~200,000–500,000 Energy.

Super Representatives (SR)

27 elected TRON network nodes responsible for block production approximately every ~3 seconds. Elected by TRX holders through TRON Power voting. In addition to 27 SR, there are up to 100 SR partners who do not produce blocks but participate in vote reward distribution. Votes are recalculated every 6 hours. SR can create Committee Proposals to change network parameters (requires 19 out of 27 votes).

Team Wallet

A wallet or a system of wallets for collaborative use by multiple users. In TRON, it is implemented via multisignature (Account Permission Update) with threshold configuration — the minimum “weight” of signatures required to approve a transaction. It allows responsibility separation: one key initiates, others confirm. Resource management (Energy, Bandwidth) is handled via centralized delegation.

threshold

A multisignature parameter in TRON that defines the minimum total “weight” of signatures required to approve a transaction. Each key is assigned a weight (weight), and the transaction is approved when the sum of weights of signers is >= threshold. Example: 3 keys with weight 1, threshold = 2 → any 2 out of 3 signatures are required. Configured separately for Owner Permission and Active Permission.

Token Standard

A set of rules for issuing, transferring, and interacting with tokens. In TRON, there are two standards: TRC-10 — implemented at the protocol level, transfers require only Bandwidth (cheap); TRC-20 — implemented via smart contracts, transfers require Energy + Bandwidth (more expensive, but more flexible). USDT uses the TRC-20 standard. TRC-20 functions: transfer, approve, balanceOf, totalSupply, allowance.

TPS (Transactions Per Second)

Network throughput — the number of transactions processed per second. TRON: ~2,000 TPS. For comparison: Bitcoin ~7 TPS, Ethereum ~30 TPS, Solana ~4,000+ TPS. TRON’s high TPS is enabled by the DPoS mechanism (27 SR, a block every 3 seconds) and an efficient architecture.

Transaction

Any operation recorded on the TRON blockchain. Types: TransferContract (TRX transfer), TriggerSmartContract (contract call / TRC-20 transfer), FreezeBalanceV2 (staking), DelegateResourceContract (delegation), VoteWitnessContract (voting), AccountPermissionUpdateContract (permission update). Each transaction has a unique txID, timestamp, expiration, and consumes Bandwidth.

Transaction Batching

A method of sequentially sending multiple transactions. In TRON, each transfer is a separate on-chain transaction (there is no “native batching” into a single transaction like multicall in Ethereum). Optimization: parallel sending from different accounts, pre-delegation of Energy to all operational wallets, using the free 600 Bandwidth (1 TRX transfer/day is free).

Transaction Cost

The total cost of a single operation. TRX transfer: ~268 Bandwidth (0 TRX with free Bandwidth). USDT TRC-20 transfer: ~64,285 Energy + ~345 Bandwidth (address with balance) = ~6.77 TRX when burning, ~2–3 TRX when renting Energy. USDT transfer to a new address: ~130,285 Energy + ~345 Bandwidth = ~13.37 TRX when burning.

Transaction Failed / Transaction Reverted

A transaction that was not executed due to an error. Main statuses: OUT_OF_ENERGY — fee_limit is exhausted, all resources are lost; OUT_OF_TIME — the 80 ms limit is exceeded, resources are lost; REVERT — a logical contract error, unused Energy is refunded. In all cases, Bandwidth is fully deducted. USDT is not moved in case of any error.
Note: the term Transaction Reverted describes the same mechanism and is combined here.

Transaction Receipt

A transaction execution result containing full information: txID (hash), status (SUCCESS/REVERT/OUT_OF_ENERGY), Energy and Bandwidth consumption, fee (burned TRX), and event logs (events). Can be obtained via the API: wallet/gettransactioninfobyid. On Tronscan: a detailed transaction page with tabs “Overview”, “Internal Txns”, “Events”.

Transaction Speed

The time from broadcast to confirmation. In TRON: inclusion in a block — ~3 seconds (1 confirmation), finalization (solid block) — ~1 minute (19 out of 27 SR). For comparison: Ethereum ~12 sec + 64 slots for finalization, Bitcoin ~10 min + 6 confirmations.

Transfer Fee

A fee charged by the network for transfers. TRX transfer: 0 TRX (if 268 Bandwidth is available). USDT TRC-20 transfer: Energy + Bandwidth, when burning ~6.77 TRX (recipient with USDT balance) / ~13.37 TRX (new address). With Energy rental: ~2–6 TRX. With staking (if sufficient resources): 0 TRX. New address activation: +1 TRX.

TRC-20

A token standard in the TRON network, аналог ERC-20 in Ethereum. Implemented via smart contracts. USDT is the largest TRC-20 token. All TRC-20 operations require Energy (computation) + Bandwidth (data transmission). Mandatory contract functions: transfer(), approve(), balanceOf(), totalSupply(), allowance(), transferFrom(). More expensive to use than TRC-10, but provides full programmability.

Treasury Wallet

A wallet for storing and managing project or business reserves. Recommendations: multisignature (threshold 2 out of 3 or 3 out of 5), hardware wallet for key storage, minimal TRX balance on operational wallets, centralized TRX staking with Energy delegation to operational wallets as needed.

TriggerSmartContract

A TRON transaction type used to call a smart contract function. Every USDT TRC-20 transfer, a swap on SunSwap, or staking in JustLend is a TriggerSmartContract. Parameters: contract_address (contract address), function_selector (function name, for example transfer(address,uint256)), parameter (encoded arguments), fee_limit (maximum TRX for Energy). API: wallet/triggersmartcontract.

TRON (TRX)

A blockchain platform with high throughput (~2,000 TPS), ~3-second block time, and a resource-based fee model using Energy and Bandwidth. The native coin is TRX. Consensus is DPoS (27 Super Representatives). TRON processes more than 60% of global USDT transfers. Ecosystem: SunSwap (DEX), JustLend (lending), USDD (stablecoin), Sun.io (staking and voting).

TRON Power (TP)

A TRON network resource that provides the right to vote for Super Representatives. It is credited when staking TRX: 1 TRX = 1 TRON Power. It is not delegated — it can only be used from the staking account. Voting is performed via VoteWitnessContract and is recalculated every 6 hours. Voting earns rewards from SR.

TronGrid

A managed public TRON node infrastructure service providing HTTP and gRPC APIs without running your own node. Access requires an API key (TRON-PRO-API-KEY) obtained on trongrid.io. Supports all standard endpoints: wallet/, walletsolidity/, wallet/estimateenergy, and others. Recommended for development, testing, and moderate-load applications. For high-load systems — run your own Full Node.

TronLink

The most popular non-custodial wallet for the TRON network. Available as a browser extension (Chrome, Firefox) and a mobile app (iOS, Android). Allows: storing TRX and TRC-20 tokens, interacting with dApps, staking TRX, voting for SR, delegating resources. The user fully controls the private keys. For Energy rental, only the TronLink public address is required.

Tronscan

The main public TRON blockchain explorer (tronscan.org). Allows: viewing transactions by txID, checking account balances and resources, analyzing smart contracts (ABI, parameters, energy_factor), tracking delegation and staking, monitoring Super Representatives and voting, and viewing network parameters (Committee Proposals).

TVM (TRON Virtual Machine)

The smart contract execution environment in the TRON network, compatible with the EVM (Ethereum Virtual Machine). Executes contract bytecode written in Solidity or Java. Each bytecode instruction has a fixed cost in Energy. Execution limit: 80 ms per contract call (if exceeded — OUT_OF_TIME). TVM ensures deterministic execution — the same result on all network nodes.

UnDelegateResourceContract

A standard Stake 2.0 transaction type for returning previously delegated Energy or Bandwidth from the recipient back to the resource owner. It is possible only after the end of lock_period (if it was set) or immediately (if delegation is without a timelock). Upon withdrawal, a reclamation mechanism applies: if the recipient consumed part of the resource, the owner’s available amount decreases proportionally until full recovery (linearly over 24 hours). API: wallet/undelegateresource.

UnfreezeBalanceV2

An unstaking transaction in the Stake 2.0 model that initiates TRX unfreezing. When executed: resources (Energy or Bandwidth) and TRON Power are revoked immediately, and TRX move into a 14-day waiting state (network parameter #70). Up to 32 active unstaking operations can run in parallel. Cancellation is possible via CancelAllUnfreezeV2. After 14 days, TRX are withdrawn to the available balance via WithdrawExpireUnfreeze. API: wallet/unfreezebalancev2.

Unfreezing / Unstaking

The process of withdrawing TRX from staking. Stages in Stake 2.0: 1) sending an UnfreezeBalanceV2 transaction, 2) immediate stop of Energy/Bandwidth/TRON Power accrual, 3) 14-day waiting period, 4) withdrawing TRX via WithdrawExpireUnfreeze. If the need for resources returns — cancellation via CancelAllUnfreezeV2 (TRX return to the frozen state).

Unfreeze Cooldown

A 14-day interval between the unfreeze request (UnfreezeBalanceV2) and the actual return of TRX to the available balance. Network parameter #70, changeable via Committee Proposal. During this period: TRX are unavailable for transfer or re-staking, resources are no longer accrued, TRON Power no longer applies. Can be tracked via wallet/getcanwithdrawunfreezeamount.

Usage Threshold

A predefined Energy or Bandwidth usage level at which action is required: resource replenishment (rental, staking) or operator notification. Used in automated systems and API integrations: when available resources fall below the threshold, the system automatically delegates Energy via DelegateResourceContract.

USDD

A decentralized stablecoin in the TRON ecosystem pegged to the US dollar. Unlike USDT (backed by fiat reserves), USDD uses algorithmic stabilization mechanisms. Issued via the TRON DAO Reserve protocol. USDD TRC-20 transfers require Energy and Bandwidth under the same rules as USDT TRC-20.

USDT

The world’s largest stablecoin pegged to the US dollar (1 USDT ≈ 1 USD). Issued by Tether on multiple blockchains. On TRON — TRC-20 standard. TRON processes more than 60% of all global USDT transfers due to low fees and high speed (~3 seconds). USDT contract: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.

USDT Balance Requirement

A key factor determining the fee size when transferring USDT TRC-20. If the recipient address already has a USDT balance — consumption is ~64,285 Energy (~6.77 TRX when burning). If the address has no USDT balance (first transfer) — consumption is ~130,285 Energy (~13.37 TRX when burning). The ~2× difference is explained by the need to create a new entry in contract storage (SSTORE: 20,000 Energy vs an update of 5,000 Energy).

USDT TRC-20

A version of the USDT stablecoin issued on the TRON network under the TRC-20 standard. Features: low fees (from 0 TRX if Energy is available), high speed (~3 seconds), wide adoption (more than 60% of global USDT transfers). Each transfer is a call to the transfer() function of the USDT smart contract. The Dynamic Energy Model increases consumption via energy_factor for the USDT contract due to its popularity.

USDT Transfer Fee

The cost of a USDT TRC-20 transfer, depending on resource availability and the recipient’s balance.
Without Energy (TRX burn): ~6.77 TRX (recipient with USDT) / ~13.37 TRX (new address).
With Energy rental: ~2–6 TRX (rental + Bandwidth). Savings up to 65%.
With staking (sufficient resources): 0 TRX — the transaction is fully free.
Additionally: new address activation +1 TRX. Bandwidth (~345 units) is deducted separately or from the free 600 units.
Note: the terms USDT Network Fee and USDT Transfer describe the same mechanism and are combined here.

User Resource Profile

A set of data describing an account’s resource state: available and total Energy and Bandwidth, staking volume (TRX for Energy / for Bandwidth), delegated resources (incoming and outgoing), TRON Power, active unstakes. Full profile can be obtained via: API wallet/getaccountresource (resources) + wallet/getaccount (balance and staking). Visually: Tronscan, the account “Resources” section.

Utility Token

A token used to pay for services, fees, or access ecosystem functionality. In the TRON context: TRX is the main utility token (staking, fees, voting); BTT (BitTorrent Token) — traffic payments; JST (JUST) — governance of the JustLend protocol; SUN — governance of Sun.io. All utility tokens in TRON follow TRC-20 or TRC-10 standards.

Validator / Super Representative

A TRON network node responsible for validating transactions and producing blocks. In TRON, validators are the 27 Super Representatives elected by TRX holders every 6 hours. SRs produce blocks in turns (~3 seconds per block), receive rewards (16 TRX per block + voting rewards), and can create Committee Proposals to change network parameters.
Note: the term Validator Node describes the same infrastructure and is combined here.

Validator Performance Metrics

A set of indicators used to evaluate the effectiveness of a Super Representative: uptime (percentage of active participation time), number of produced blocks, missed blocks, response time, and the share of rewards redistributed to voters. Metrics are available on Tronscan in the “Representatives” section and are used by voters to choose the optimal SR.

Validator Reward

The reward received by Super Representatives for block production and maintaining the network. It consists of: 16 TRX for each produced block (8 TRX block reward + 8 TRX vote reward), 160 TRX voting rewards distributed every 6 hours among 27 SR and up to 100 SR partners. SRs set the reward redistribution percentage to voters (from 0% to 100%).

Validator Selection / Voting Cycle

The process of determining the 27 Super Representatives based on voting by TRX holders. Votes = TRON Power (1 staked TRX = 1 vote). Votes are recalculated each Maintenance Period — every 6 hours (00:00, 06:00, 12:00, 18:00 UTC). The 27 addresses with the highest number of votes become SR. The next up to 100 addresses become SR partners (they do not produce blocks but receive a portion of rewards).
Note: the term Voting Cycle describes the same process and is combined here.

Validator Uptime

A measure of Super Representative stability — the percentage of time of active participation in block production. If an SR misses its slot, the next SR produces the block. Low uptime means loss of rewards for the SR and its voters. Top SRs maintain uptime >99.9%. Tracked on Tronscan.

Vote / Voting Power / TRON Power

A mechanism for participation in TRON network governance. When staking TRX, TRON Power is credited (1 TRX = 1 TP = 1 vote). Votes are allocated among Super Representative candidates via the VoteWitnessContract transaction. You can vote for multiple SR at the same time. Votes are recalculated every 6 hours. Voting yields rewards from SR.
Note: the terms Vote Weight, Vote Allocation, and Voting Power describe the same mechanism and are combined here.

Voting Interface

Tools for voting for Super Representatives. The main ones: Tronscan (tronscan.org — “Votes” section), TronLink (built-in voting function), Sun.io (staking + voting with a convenient interface). Process: connect wallet → select SR → specify number of votes → confirm the VoteWitnessContract transaction.

Voting Reward

Rewards received by users for participating in voting for Super Representatives. The amount depends on: your number of votes (TRON Power), the redistribution percentage set by the SR, and the total number of votes for that SR. Rewards accumulate and are claimed via API wallet/rewardbalance + wallet/withdrawbalance. They are not credited automatically — withdrawal must be requested.

Voting Snapshot

A record of the vote and TRON Power state at the start of each Maintenance Period (00:00, 06:00, 12:00, 18:00 UTC). Based on the snapshot, 27 SR are determined for the next 6 hours and rewards are calculated. Vote changes between snapshots take effect only in the next cycle.

VoteWitnessContract

A TRON transaction type for voting for Super Representatives. Parameters: owner_address (voting account), votes (an array of pairs “SR address → number of votes”). The total number of votes cannot exceed the account’s TRON Power. Each new vote completely replaces the previous vote allocation. The transaction consumes ~270–300 Bandwidth. API: wallet/votewitnessaccount.

Wallet

A tool for storing, sending, and managing cryptocurrency, tokens, and resources in the TRON network. Types: non-custodial (the user controls keys — TronLink, Trust Wallet, SafePal, Ledger), custodial (keys are held by a third party — exchanges). To work with TRON, a wallet must support: TRX, TRC-20 tokens, staking (Stake 2.0), and resource delegation.

Wallet Approval

A list of smart contracts to which the user has granted approval (approve) to manage their tokens. Each approval specifies: contract address (spender), token type, and the allowed limit. Risk: unlimited approval gives a contract unrestricted access to tokens. Recommendation: regularly review and revoke unnecessary approvals via Tronscan (account “Approval” section) or TronLink.

Wallet Connection

The process of connecting a wallet to a dApp or Web3 application. In TRON, the standard protocol is TronLink Adapter (an аналог of WalletConnect for Ethereum). When connected, the dApp gains access to the public address, but not to the private key. Each transaction requires user confirmation in the wallet interface. Connection itself does not consume Energy or Bandwidth.

Wallet Drain

The theft of funds from a wallet due to: phishing (a fake site obtains the seed phrase or private key), malicious approval (a contract receives unlimited access to tokens), address replacement (clipboard hijacking — malware replaces the address when copying), or key compromise. Protection: never enter seed phrase on websites, check approve limits, use a hardware wallet, verify the address before sending.

Wallet Energy Status

The current state of Energy resources in a wallet: available Energy (for transactions without TRX burn), total limit (own + delegated), used in the current cycle, and time to full recovery. Check via: Tronscan (“Resources” section), TronLink (main screen), API wallet/getaccountresource. Recommended to check before every USDT transfer.

Wallet Monitoring

Continuous tracking of wallet transactions, balance, and activity. Tools: Tronscan (transaction history, resources, approvals), TronGrid API (programmatic monitoring, webhook notifications), third-party services with balance and resource alerts. For business: monitoring multiple operational wallets with a centralized dashboard and automatic Energy replenishment.

Wallet Recovery

The process of restoring access to a wallet. The main method: importing the seed phrase (a 12- or 24-word mnemonic phrase). Alternative: importing the private key. Upon recovery, all balances (TRX, USDT, other tokens), staking, and delegations remain intact — they are recorded on the blockchain and tied to the address, not to the device. Without the seed phrase or private key, recovery is impossible.

Wallet Security

Security measures: store seed phrase offline (paper, metal — not in the cloud), use a hardware wallet for large amounts, use limited approve allowances (not unlimited), separate wallets (vault + operational), multisignature for team wallets, verify contracts before interacting. Never: enter the seed phrase on websites, connect a wallet to unknown dApps.

Wallet Signature

A cryptographic signature that confirms the authenticity and authorship of a transaction. Created by the private key using ECDSA (secp256k1). Any network node can verify the signature using the public key but cannot forge it. Every transaction in TRON must be signed — without a signature, the network rejects it. Hardware wallets sign transactions inside the device without exposing the private key.

Wallet Transaction History

A complete list of account operations recorded on the blockchain: TRX transfers, TRC-20 transfers (USDT, etc.), contract calls, staking, delegation, voting. Viewing: Tronscan (“Transactions”, “Transfers”, “Internal Txns” tabs), TronLink (wallet history), API wallet/gettransactionlistbyaddress. Each record contains: txID, status, resource consumption, and time.

Withdrawal Fee

A fee charged by an exchange or service when withdrawing USDT or other assets to an external wallet. This is not a TRON network fee but a platform markup. The network fee is ~6.77 TRX (when burning), but exchanges usually charge a fixed amount (1–5 USDT). Withdrawing on TRON (TRC-20) is significantly cheaper than on Ethereum (ERC-20) or Bitcoin.

WithdrawExpireUnfreeze

A Stake 2.0 transaction for receiving TRX after completing the 14-day unstaking waiting period. After execution, TRX move to the available account balance and become available for transfers, re-staking, or other operations. Check the withdrawable amount via the API wallet/getcanwithdrawunfreezeamount. If the waiting period is not complete, the transaction will be empty (0 TRX).

Witness Permission

The third permission level in the TRON account permission system (along with Owner Permission and Active Permission). Witness Permission is used only by Super Representatives and SR partners for: block production, block signing, and participation in voting on Committee Proposals. For regular users, Witness Permission does not apply.

Yield Staking

A form of staking where freezing cryptocurrency is used not only to obtain network resources but also to generate yield. In the TRON ecosystem: staking TRX → receiving TRON Power → voting for SR → rewards from SR (APR). Additionally: DeFi staking in JustLend (depositing TRX/USDT to earn interest), Sun.io (staking LP tokens to farm SUN/TRX). Important: DeFi staking consumes Energy and carries smart contract risks.

Zero Energy State

An account state in which the available Energy is fully exhausted. In this state: USDT TRC-20 transfers are possible, but all Energy is paid via TRX burn (Energy Fee Fallback) — ~6.77–13.37 TRX per transfer. TRX transfers are unaffected (they require only Bandwidth). To exit Zero Energy State: stake TRX, rent Energy, or receive delegation from another account.

Zero Fee Transaction

A TRON transaction executed without TRX burn — fully covered by resources (Energy + Bandwidth). Achievable with: sufficient Energy (staking/delegation/rental) + sufficient Bandwidth (staking/delegation/free 600 units). For TRX transfers: the free 600 Bandwidth is sufficient (1 transfer per day). For USDT transfers: Energy is required (~64,285–130,285 units) + Bandwidth (~345 units).