Layer 1 blockchain
TRON ticker TRX
Summary
Delegated proof of stake run by the java-tron client. TRX holders stake to receive TRON Power (one vote per staked TRX) and vote for candidates. At each 6-hour maintenance update the 27 candidates with the most votes become Super Representatives (SRs) and take turns producing blocks, one 3-second slot each. A block is treated as irreversible (solidified) once at least 19 distinct active SRs have produced a block at or above its height, usually about a minute. There is no slashing: missed or conflicting blocks cost rewards and votes, not stake. The same 27 SRs form the committee that changes network parameters such as fees and rewards; a proposal needs 18 approvals. 231213
Design
- System
- Layer 1 blockchainTRON mainnet runs its own delegated proof-of-stake consensus in the java-tron client and does not post data to or settle on another chain. Its virtual machine runs most Solidity contracts, but consensus, fees, addresses and account rules are TRON's own, so no Ethereum defaults are applied. BitTorrent Chain is a separate chain and is not described by these cells. The package's layer-1 class is kept.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- The 27 active SRs produce blocks in vote-ranked order, one slot each per 81-second round; a missed slot stays empty and is not reassigned. Registering as a candidate burns 9,999 TRX. Candidates ranked 28 to 127 (SR Partners) share voter rewards but do not produce blocks.
- Fork choice
- For blocks that are not yet solidified, a node accepts a new block only if it is higher than its current head; a rival block at the same height is dropped on a first-seen basis, and each slot can hold at most one block. Forks normally resolve within one round, and once 19 of the 27 SRs have built on a branch, blocks at or below that height are no longer subject to fork choice.
Qualifications
- Finality · Partial. A block is treated as irreversible once 19 of 27 active producers have built at or above it, usually about a minute, and the solid height never rolls back in the client. No stake is slashed if producers misbehave, so this is not classed as stake-backed economic finality. If nine or more producers stopped producing, solidification would stall; that last point is an inference from the documented threshold rule.
- Decentralization · Partial. 27 producers are chosen by stake-weighted votes every six hours, with 100 more ranked candidates earning rewards but not producing. Anyone can become a candidate by burning 9,999 TRX. Operator identities and vote concentration were not verified in this review.
- Ethereum defaults · Not applicable. TRON's virtual machine runs most Solidity contracts, but TRON has its own consensus, fee resources, address format and no account nonce, so fee-market, validator and rollup assumptions built into EVM tooling do not carry over.
- Fee market · Not applicable. There is no priority-fee bidding: producers take transactions first-in-first-out, and resource prices are fixed network parameters changed by proposal. Heavily used contracts pay a dynamic Energy multiplier of up to 4.4 times the base cost.
- Settlement family · Partial. Recorded as other. TRON's own terms: delegated proof of stake run by the java-tron client, with 27 elected Super Representatives, Bandwidth and Energy fee resources, its own address format and no account nonce; its virtual machine runs most Solidity contracts.
Tradeoffs
- Emphasizes
- Scalability
- Gives up
- Decentralization of block production and governance: 27 elected producers make every block, and 18 of them can change fees, rewards and other network parameters by proposal. There is no slashing, so misbehaviour costs rewards and votes rather than staked TRX. A full node needs server-class hardware and multi-terabyte storage.Security is not listed as an emphasis because irreversibility rests on 19 of 27 producers behaving honestly with no stake at risk; readers who count one-minute deterministic solidification as a security feature may disagree. Vote concentration among producers was not measured in this review.
- Full node at home
- Demanding 8913TRON's deployment guide lists a minimum of 8 CPU cores, 16 GB RAM, a 3 TB SSD and 100 Mbps, and recommends 16 cores and 32 GB for a full node (32 cores and 64 GB for a producing node). Syncing from genesis can take weeks to months, so operators usually start from a snapshot of about 3 TB (May 2026). A pruned Lite Fullnode boots from a state snapshot of about 52 GB but keeps the same CPU and memory recommendation. The client README gives somewhat different figures: 200 GB for a Lite Fullnode, 3.5 TB for a stable full node and 4 TB recommended.
- Throughput claims
- Theoretical peak: 2,000 tx/s 1612Theoretical peak; not comparable across chains or with observed load.Stated as 'up to 2,000' on TRON's overview page and '2,000+' on another TRON developer page; the 2018 whitepaper gives 2000 and says it was surpassed, with no method.No measurement window, date range or workload statedProject-stated capacity with no published method, transaction mix or hardware; not an observed network rate. Does not show whether nodes on the published minimum hardware keep up, and ignores state growth, block propagation and spam or decoy load. The same figure appears in the 2018 whitepaper, when fee and resource settings were different, so it is not tied to today's parameters.
Scaling layers
- BitTorrent Chain (BTTC) · Sidechain, mainnet 22232425
Separate proof-of-stake chain with a Tendermint-based validator layer. Its staking contracts are deployed on TRON, and its validators publish Merkle-root checkpoints to TRON, BNB Chain and Ethereum. The TRON bridge locks tokens on TRON and mints mapped tokens on BTTC, unlocking them when those are burned. Users trust BTTC's validators and bridge contracts, not TRON's producers. BTTC's docs call it a layer 2, but it has its own consensus and describes no fraud or validity proofs, so it is not a rollup. Most reviewed pages date from August 2022.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Independent softwareLimited scope | Independent software, limited: STON.fi's Omniston settles cross-chain swaps through hashed time-locked contracts. The trader locks funds on the source chain, a resolver locks the output on the destination chain, and revealing the secret lets both legs complete; otherwise timelocks return the funds. Its docs list TRON as an operational chain whose routes use this contract flow. No TRON DAO swap tool is cited; TRON's virtual machine can run hash- and time-locked contracts. Limited: USDT (TRC-20) is the only TRON asset listed, with a resolver quoted through STON.fi's service as counterparty. 373839 |
| Authenticated data publication | Unknown | Not yet assessed under this row's current definition. |
| Light clients | Unknown | Not yet assessed under the current definitions; third-party light verifiers were not reviewed, so the rule that absence needs a source makes this unknown. TRON's node documentation describes only Fullnode and Lite Fullnode, both running java-tron; a Lite Fullnode starts from a state snapshot the operator must obtain and trust, then validates new blocks itself, so it is a pruned full node, not a light client. 8 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel network settling to TRON was found in the reviewed sources. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | TRON's virtual machine runs Solidity contracts under TRON's own fee and address rules, with some opcodes that differ from the EVM's, and accounts support weighted multi-signature permissions scoped to transaction types at the protocol level rather than through contract wallets. 57 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; Account Permission Management lets an account spread control across up to five weighted keys per permission, keep an owner key offline that can replace compromised active keys, and limit active keys to chosen transaction types. Replacing keys with the owner key is rotation by the account's own key holder, which the pending account-abstraction row covers; no delayed or reversible payment was found. 5 |
| Rollups | Unknown | Unknown under the rule that absence needs a source: the earlier note said absence was not exhaustively verified. No rollup settling to TRON was found in the reviewed sources; BitTorrent Chain, which describes itself as a layer 2, runs its own proof-of-stake consensus and is recorded as a sidechain. 2223 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Established in the ecosystemSunSwap (SUN.io) | SUN.io describes SunSwap as its core trading protocol, with V1 to V4 liquidity pools reached through a router, and TRON's tokenomics page names SunSwap as a TRON exchange. Liquidity depth and market share were not measured. 41415 |
| Issuer-native stablecoins | Established in the ecosystemUSDT (Tether, TRC-20), USDD | Tether's supported-protocols page lists a TRON contract for USDT (and MXNT), and lists CNHT on TRON as deprecated. USDD's own docs list TRON contracts for a crypto-collateralized vault stablecoin, which is not an issuer-redeemable fiat token. Circle's USDC address list does not include TRON. 16192021 |
| Algorithmic stablecoins | Unknown | Current USDD is documented as over-collateralized, with vaults, liquidations and a 1:1 swap module. Its legacy version (USDDOLD) was issued by the TRON DAO Reserve and minted by that reserve's whitelisted institutions burning TRX; the issuer describes it as over-collateralized by reserve assets including BTC, USDT, USDC and TRX. Because minting by burning TRX resembles algorithmic designs, how to classify the legacy version was not settled here. No other algorithmic stablecoin was reviewed. 1718 |
| Bridges | Established in the ecosystemBTTC bridge, USDT0 Legacy Mesh | BitTorrent Chain's bridge moves tokens between TRON and BTTC by lock-and-mint. The USDT0 Legacy Mesh routes native TRON USDT through a hub on Arbitrum to chains using USDT0, with a 0.03% fee. Other third-party routes were not reviewed; this is not a complete list. Risk: A mapped token is only as sound as its bridge: BTTC transfers depend on BTTC's validator set, checkpoint contracts and documentation last updated in 2022, and the Legacy Mesh depends on pool liquidity on each side and on the cross-chain messaging layer that carries its instructions. No bridge audits were reviewed. 232426 |
| Block explorers | Established in the ecosystemTRONSCAN, OKLink | TRON's docs describe TRONSCAN as the most widely used TRON explorer, with a web interface and API; OKLink also runs a TRON explorer. Listing is not a quality or completeness check, and explorer data is provider-indexed. 1027 |
| Hardware wallets | Established in the ecosystemLedger, Trezor | See custody rows: Ledger and Trezor both list TRON in their own apps, and both vendors document TRX staking with voting for producers and TRC-20 tokens. Trezor limits staking to its desktop app and does not support TRC-10 tokens. TRON's wallet page and TronLink also name Ledger. 112829313233 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Native supportSame as native: Yes | Can: Set up a TRON account in the Ledger Wallet app and send and receive TRX Can: Stake TRX and vote for Super Representatives from the Ledger Wallet app, up to five representatives in one voting operation, as Ledger's TRON staking page states Can: Receive, send and buy TRC-20 tokens in Ledger Wallet once the TRON device app is installed, as Ledger's TRC-20 page states Can: Connect a Ledger to TronLink, which documents Ledger importLedger's staking page says reward handling depends on the chosen Super Representative: some leave rewards to be claimed on chain every 24 hours, others pay them off chain under their own policy. Which Ledger device models support each TRON feature was not checked. 1128293036 |
| Trezor | Native supportSame as native: Yes | Can: Send and receive TRX and TRC-20 tokens such as USDT in Trezor Suite on Trezor Safe 3, Safe 5, Safe 7 and Model T Can: Stake TRX for Bandwidth or Energy, vote for a Super Representative, claim rewards and unstake in the Trezor Suite desktop app Can: Buy, sell and swap TRX through Trezor Suite, as Trezor's TRON page states Can: Use a Trezor with the NuFi wallet for TRON Cannot: Use TRON on a Trezor Model One Cannot: Manage TRC-10 tokens in Trezor Suite, which does not support them and labels TRC-10 transactions as potential scams Cannot: Stake, unstake, withdraw or claim TRX rewards in the Trezor Suite mobile app, which shows staking but sends users to the desktop app for these actionsTrezor's send guide still says native staking for Energy is coming soon, while its staking guide describes staking for Bandwidth or Energy as available on desktop; the staking guide is followed here. The send guide also calls TRON in the mobile app experimental. 31323335 |
Public data
iKnow Blockchain has no public-data lookups for TRON yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
java-tron GreatVoyage-v4.8.2.2 (Parmenides) mandatory maintenance release
GreatVoyage-v4.8.2.2 (Parmenides) was published and marked mandatory. It refines validation of contract-deployment transactions, improves edge-case handling of Stake 2.0 and SELFDESTRUCT, and reuses virtual-machine jump tables to speed up contract execution.
- Implementation:shipped in java-tron v4.8.2.2
- Release:mandatory release; no deadline stated in the release notes
- Activation:not stated in the reviewed sources
Sources: tronprotocol (GitHub) — GreatVoyage-v4.8.2.2 (Parmenides) release notes (external site) · TRON Developer Hub — Release Announcements (external site)
-
java-tron GreatVoyage-v4.8.2.1 (Heraclitus) non-mandatory maintenance release
GreatVoyage-v4.8.2.1 (Heraclitus) was published as a non-mandatory upgrade after Pyrrho. Its notes list one functional change, improved HTTP API performance, plus two dependency updates: libp2p from 2.2.8 to 2.2.9 and grpc-java from 1.81.0 to 1.83.0. They describe no new virtual-machine feature, TIP or governance parameter.
- Implementation:shipped in java-tron v4.8.2.1
- Release:non-mandatory release; no deadline stated in the release notes
- Activation:no network activation described; the changes apply to nodes that install the release
Sources: tronprotocol (GitHub) — GreatVoyage-v4.8.2.1 (Heraclitus) release notes (external site) · tronprotocol (GitHub) — Release notes from java-tron (Atom feed) (external site)
-
java-tron GreatVoyage-v4.8.2 (Pyrrho) adds Osaka- and Pectra-era virtual machine features
GreatVoyage-v4.8.2 (Pyrrho) was released as a mandatory upgrade with a deadline of 23:59 Singapore time on 16 August 2026. It adds a count-leading-zeros opcode, a secp256r1 (P-256) signature-check precompile, bounds and new pricing for the MODEXP precompile and historical block hashes served from state, alongside a resource-window change (TIP-833), a switch from Fastjson to Jackson, removal of InfluxDB metrics reporting in favour of Prometheus, and a required Event Plugin v3.0.0. A non-mandatory 4.8.2.1 followed on 31 July.
- Proposal:TIP-7939, TIP-7823, TIP-7883, TIP-7951, TIP-2935 and TIP-833 referenced in the release notes
- Implementation:shipped in java-tron v4.8.2
- Release:mandatory release; upgrade deadline 2026-08-16 23:59 SGT
- Activation:Osaka and Prague gates shown enabled on mainnet in a 2026-09-27 parameter query; activation dates not verified
Sources: tronprotocol (GitHub) — GreatVoyage-v4.8.2 (Pyrrho) release notes (external site) · TRON Developer Hub — Release Announcements (external site) · TronGrid — Chain parameters (public API response) (external site) · TRON Core Devs (TRON on Medium) — Mainnet Pyrrho Announcement (external site)
-
java-tron GreatVoyage-v4.8.1 (Democritus) released as a mandatory upgrade
The TRON developer community released GreatVoyage-v4.8.1 (Democritus) as a mandatory upgrade and asked nodes to upgrade by 23:59 Singapore time on 9 March 2026. It adds ARM64 support with JDK 17, changes SELFDESTRUCT to match Ethereum's EIP-6780 behaviour (TIP-6780), moves the proposal voting window into chain governance (TIP-767), adds peer-to-peer message rate limits and new APIs for live SR vote counts.
- Proposal:TIP-6780 and TIP-767 referenced in the release notes
- Implementation:shipped in java-tron v4.8.1
- Release:mandatory release; upgrade deadline 2026-03-09 23:59 SGT
- Activation:SELFDESTRUCT restriction shown enabled on mainnet in a 2026-09-27 parameter query; activation date not verified
Sources: tronprotocol (GitHub) — GreatVoyage-v4.8.1 (Democritus) release notes (external site) · TRON Developer Hub — Release Announcements (external site) · TRON Developer Hub — TVM vs EVM (external site) · TronGrid — Chain parameters (public API response) (external site)
Topics your AI can explain
Your AI can explain these topics for TRON through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Producer operator identities, vote concentration among the 27 producers and the stake behind them were not verified.
- No observed throughput measurement with a published method was found; the only figure recorded is TRON's own stated capacity.
- The client README (200 GB for a Lite Fullnode, 3.5 to 4 TB for a full node) and the deployment guide (3 TB minimum) give different storage figures; the guide's figures are used here.
- Whether USDD's legacy design counts as algorithmic, and how much legacy USDD still circulates, was not settled, so the algorithmic stablecoin row is unknown.
- Most of BitTorrent Chain's reviewed docs were last updated in 2022; its validator count, checkpoint cadence and bridge audits were not reviewed. Its public endpoint returned a current block on 2026-09-27, so the chain is running.
- Bridges other than the BTTC bridge and the USDT0 Legacy Mesh, and their trust models, were not reviewed.
- Payment or state channels and third-party light verifiers for TRON were not reviewed.
- Omniston's TRON contract address, audits, liquidity and swap volume were not verified; its docs say live quote availability is decided by each quote request. Other hash-locked swap services on TRON were not fully reviewed: Garden's docs describe a TRON contract for TRC-20 tokens, but its live mainnet chain list omitted TRON on 2026-09-29, so it is not counted.
- Hardware wallet support was read from vendor pages on 2026-09-27 and can change with app releases; Trezor's own guides disagree on whether staking for Energy is available yet, and Ledger's per-device feature support was not checked.
- Circle's current USDC list omits TRON, but the date and terms of any USDC withdrawal from TRON were not verified from a Circle page.
- TRONSCAN blocked automated fetching, so explorer facts rely on TRON's own documentation.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- What is TRON (external site)
- Consensus and DPoS (external site)
- Network parameters (external site)
- Tokenomics (external site)
- Account Permission Management (external site)
- TRON vs Ethereum (external site)
- TVM vs EVM (external site)
- Nodes overview (external site)
- Deploy a node (external site)
- TRONSCAN — blockchain explorer and data platform (external site)
- Wallets and accounts (external site)
- Advanced Decentralized Blockchain Platform Whitepaper, version 2.0 (external site)
- java-tron repository (external site)
- SUN.io documentation (external site)
- SunSwap overview (external site)
- What is the new version of USDD? (external site)
- What is USDDOLD? (external site)
- System Architecture (external site)
- Deployment Addresses (external site)
- Supported Protocols (external site)
- USDC contract addresses (external site)
- What is BTTC (external site)
- BTTC PoS architecture (external site)
- Bridge overview (external site)
- Networks (external site)
- The Legacy Mesh (external site)
- TRON explorer (external site)
- TRON wallet (external site)
- Tron staking (external site)
- TRC20 wallet (external site)
- TRON wallet (external site)
- Staking Tron (TRX) in Trezor Suite (external site)
- Send and receive Tron and TRC-20 tokens in Trezor Suite (external site)
- Supported coins (external site)
- Tether wallet (external site)
- TronLink wallet (external site)
- Overview (Omniston) (external site)
- How Omniston Works (external site)
- TRON chain (Omniston SDK) (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding