TRON node requirements in 2026: FullNode, Lite FullNode and SR node

A TRON FullNode needs 16 CPU cores, 32 GB of RAM and a fast SSD, according to TRON’s developer documentation, and a Super Representative node needs 32 cores and 64 GB. Disk is the figure to watch: the official Mainnet snapshot weighed about 3.3 TB compressed in September 2026. A Lite FullNode starts from about 52 GB.

Official java-tron FullNode hardware requirements

TRON has one client, java-tron, for every role. A FullNode keeps the whole chain, a Lite FullNode boots from a state snapshot, and a Super Representative (SR) node is a FullNode started with --witness to produce blocks. The table reproduces the TRON Developer Hub’s deployment guide, verified on October 15, 2026 (the page was last updated on October 13).

Two other official pages broadly agree on CPU and memory but not on disk. The java-tron README asks for 3.5 TB for a “stable” FullNode and 4 TB for its recommended FullNode and SR tiers, and for at least 50 Mbit/s downstream instead of 100 Mbps; its 200 GB minimum tier only covers a Lite FullNode. The java-tron documentation site says 3.5 TB+. Where they differ, size for the larger disk: the snapshot sizes below show that 3 TB no longer holds a FullNode.

How much disk a TRON FullNode needs

Syncing Mainnet from genesis takes “weeks to months”, so most new FullNodes start from a database snapshot produced by the TRON community. TRON’s snapshot page lists these Mainnet archives:

These are compressed archives. TRON says the extracted database needs additional space but does not publish its size; its node overview put a FullNode snapshot at about 3 TB in May 2026. Three practical rules follow:

• Treat 4 TB of usable NVMe as a floor, not a target, and plan more for the internal-transaction or balance-history variants that exchanges and explorers often want.
• Stream the download when space is tight. Piping wget into tar extracts the archive as it arrives and never stores it, but you cannot check its .md5sum file first. Downloading, verifying and then extracting needs room for both; TRON suggests at least 5 TB for the archive alone, on a separate destination.
• Match the storage engine. LevelDB and RocksDB data are incompatible: the snapshot must match storage.db.engine in config.conf, and ARM64 nodes support only RocksDB.

The mirrors limit concurrent connections, so TRON asks for a single-threaded download tool. At a sustained 1 Gbps, a 3.3 TB archive takes a little over seven hours; at 100 Mbps, about three days.

Lite FullNode: when 52 GB is enough

A Lite FullNode runs the same FullNode.jar but starts from a snapshot holding the current state plus the latest 65,536 blocks, about 54 hours of history at TRON’s 3-second slots. TRON measured that snapshot at about 52 GB in May 2026, roughly 2% of a FullNode snapshot. It syncs new blocks, broadcasts transactions and answers current-state queries, which covers many wallet back ends and DApps.

The trade-offs are explicit. APIs that fetch blocks or transactions by ID or height are disabled by default, even for blocks produced after the node started; node.openHistoryQueryWhenLiteFN = true re-enables them, but only for data still on disk. And once running, a Lite FullNode grows at the same rate as a FullNode, so TRON suggests stopping it and re-pruning it with the Toolkit’s db lite command, monthly being a common cadence.

CPU, RAM and JVM settings

TRON’s troubleshooting guide is blunt about undersized machines: below 16 cores and 32 GB, a node “may stop syncing” when the chain hits a complex contract call, and both the physical core count and the thread count reported by /proc/cpuinfo should be at least 16 in production. On borderline hardware, raising vm.maxTimeRatio gives heavy contract calls more time during verification.

• Match the JDK to the CPU. x86_64 nodes run only on JDK 8, with Oracle JDK 8 recommended for production; ARM64 nodes run only on JDK 17, from java-tron 4.8.1. The node exits at startup on a mismatch.
• Size the heap. The reference commands use -Xms9G -Xmx9G on a 16 GB host. With 32 GB or more, set -Xmx to about 40% of physical RAM; the SR example for a 64 GB host uses -Xmx24G.
• Pick the documented collector. CMS (-XX:+UseConcMarkSweepGC) on JDK 8, ZGC (-XX:+UseZGC) on JDK 17, with every JVM option placed before -jar.
• Cap off-heap memory. Without -XX:MaxDirectMemorySize, TRON warns, direct memory can grow until the operating system kills the process. Preloading tcmalloc is also recommended to reduce fragmentation.

Ports and bandwidth

Defaults from the Mainnet config.conf shipped with java-tron:

TRON’s advice is to expose only the P2P port and to put any public API behind a gateway with TLS, authentication and rate limiting. One inconsistency: the README’s example configuration shows gRPC on port 9090, while the shipped config.conf and the Developer Hub both use 50051.

For bandwidth, the Developer Hub asks for 100 Mbps and the README’s recommended tier for 50 Mbit/s downstream; neither gives a monthly traffic figure. The snapshot is the largest single transfer, and API clients add their own load afterwards; on an unmetered 10 Gbps port, neither appears on the bill.

Do I need my own TRON node to send or receive USDT (TRC-20)?

No. A TRON wallet, or an application calling a hosted API such as TronGrid, builds, signs and broadcasts the transaction through nodes that already exist. TRON’s node overview says that casual users, wallets and occasional transfers “usually do not need to run a node”. Your own node does not lower fees either: TRC-20 transfers consume Energy, obtained by staking TRX or by burning TRX per transaction, and the protocol charges it whichever node broadcasts.

A node of your own makes sense when the chain is part of your product:

• Exchanges, custodial wallets and payment processors that detect deposits and send withdrawals at volume. TRON notes that most integrators start on TronGrid, which needs an API key for production traffic and is rate-limited by plan, and move to a self-hosted node when volume or feature needs justify it.
• Indexers, explorers and analytics that parse every block. A self-hosted node has no rate limits, but no account-history endpoints either: you build those from block data.
• Super Representatives, who must run the block-producing node themselves.

For deposit detection, TRON recommends vm.supportConstant = true (required to read TRC-20 balances with balanceOf), vm.saveInternalTx = true (to see TRX and TRC-10 moved by contracts) and a vm.maxTimeRatio of 20 or more on lower-spec hardware, and reading from solidified blocks, which trail the head by about a minute but cannot be rolled back. If you are paying for the server itself, PowerDedi accepts USDT on TRON.

Which PowerDedi server for a TRON node

The disk caveat matters more than the CPU one. Mirroring two drives leaves 3.84 TB, which no longer fits a FullNode, so the two-drive servers above work as FullNodes only with the drives striped (RAID 0), and a failed drive then means another snapshot restore. Only the EPYC 9555P combines a FullNode with redundancy. The EPYC 4585PX ($179/mo) has the 9950X’s disks with ECC memory, so it suits a Lite FullNode too. SR operators should budget for two servers: TRON’s upgrade procedure moves block production to a standby node before the primary is touched. And if you only need to move USDT, you need none of these.

How to run a TRON node: setup outline

These steps use only commands from TRON’s documentation; paths and the snapshot URL are placeholders.

# 1. Download FullNode.jar and the matching Toolkit.jar from the java-tron
#    releases page, or build from source:
git clone https://github.com/tronprotocol/java-tron.git
cd java-tron
git checkout -t origin/master
./gradlew clean build -x test

# 2. Restore a snapshot into output-directory, streamed (archive never stored)
wget -q -O - SNAPSHOT_URL/FullNode_output-directory.tgz | tar -zxvf -

# 3. Start a FullNode (x86_64, JDK 8; heap shown for a 16 GB host)
java -Xms9G -Xmx9G -XX:+UseConcMarkSweepGC -jar FullNode.jar -c config.conf

# 4. Follow the sync; stop with SIGTERM, never kill -9
tail -f ./logs/tron.log
kill -15 <pid>

# Lite FullNode: prune a stopped FullNode database into a Lite snapshot
java -jar Toolkit.jar db lite -o split -t snapshot -fn /path/to/fullnode/output-directory -ds /path/to/snapshot

For an SR, add --witness and provide the signing key, preferably as an encrypted keystore created with java -jar Toolkit.jar keystore new rather than in plain text in config.conf. Then firewall everything except SSH and port 18888 using our first-hour hardening checklist. Current stock and locations are on our blockchain node hosting page.

Sources

• Deploy a node — TRON Developer Hub (updated October 13, 2026)
• Database snapshots — TRON Developer Hub (updated September 22, 2026)
• Nodes overview — TRON Developer Hub (updated October 12, 2026)
• Node operations issues — TRON Developer Hub
• Exchange and custodial wallet integration and Exchange wallet integration — TRON Developer Hub
• java-tron README — tronprotocol on GitHub (latest release GreatVoyage-v4.8.2.3, September 30, 2026)
• Mainnet config.conf — java-tron repository
• Deploying a java-tron Node — java-tron documentation