Nodes overview
What a TRON node is, the two node types (Fullnode and Lite Fullnode), why you might want to run your own, and how to decide between running a node yourself or using a hosted API service.
TRON is a distributed network of computers running software (known as nodes) that verify blocks and transaction data. To run a node, you install a client — an implementation of the TRON protocol — on your machine.
This page is the conceptual starting point. It covers what nodes are, the two node types TRON supports, why you might run one, and how to choose between running your own or using a hosted API. For step-by-step deployment, see Deploy a node.
What are nodes and clients?
A node is a running instance of the client software. A client is an implementation of the TRON protocol that verifies every transaction in every block, keeping the network secure and the ledger consistent. The TRON client is implemented in Java (java-tron) and the same binary runs in all configurations described below.
Why run a TRON node?
Running your own node gives you four practical benefits over relying on a third-party service:
- Trustless verification. Your node validates every block and transaction against consensus rules itself. You don't have to trust any other node in the network to tell you the truth.
- Privacy. Your queries stay on your hardware instead of being routed through a third-party provider.
- Custom RPC. You can program your own RPC endpoints for application-specific lookups or instrumentation that a hosted service doesn't expose.
- Network support. More independent nodes make the TRON network more resilient and decentralized.
These benefits matter most for indexers, analytics back-ends, exchanges, bridges, and anyone whose product depends on the chain. Casual users — wallets, occasional transfers — usually do not need to run a node.
Node types
TRON supports two node types. Both run the same java-tron client; they differ in what initial dataset they boot from and what historical queries they can serve.
| Aspect | Fullnode | Lite Fullnode |
|---|---|---|
| Initial dataset | Syncs from genesis, or boots from a Fullnode snapshot (significantly faster — usually preferred in production) | Boots from a state-data snapshot |
| Historical block / transaction queries | Full | Disabled by default for pre-snapshot history (post-startup data is queryable) |
| Snapshot size | ~3 TB at May 2026 | ~52 GB at May 2026 (≈2% of a Fullnode snapshot) |
| Initial disk footprint | Full chain (~3 TB at recent height) | A few percent of a Fullnode dataset, grows over time |
| Typical operator | Block explorers, indexers, archival services, SRs | Operators who need block sync and current state but not historical queries |
Fullnode
A Fullnode stores and synchronizes the complete blockchain since genesis. It verifies all blocks and states independently and exposes HTTP and gRPC APIs for external queries against any block or transaction in history. Super Representatives (SRs) run Fullnodes (with the --witness flag and a signing key) to produce blocks and earn the block reward.
If you serve block explorers, exchanges, wallets, indexers, archival APIs, or anything that needs historical lookups going back to genesis, you want a Fullnode. See Deploy a node for the operational setup.
Lite Fullnode
A Lite Fullnode runs the same client software as a Fullnode but boots from a state-data snapshot containing the complete current state plus the most recent 65,536 blocks (roughly 54 hours of history at 3-second slots). It trades the ability to serve pre-snapshot historical queries for a much smaller initial footprint and a much faster startup.
Choose a Lite Fullnode when you need block sync, transaction broadcast, and current-state queries — but not pre-startup historical data — and want a faster initial deployment. See Lite Fullnode deployment for the operational setup.
How to use a TRON node
There are three practical ways to interact with the TRON network through a node. The right choice depends on what your application needs and how much operational ownership you want to take.
| Run your own Fullnode | Run your own Lite Fullnode | Use a hosted service | |
|---|---|---|---|
| Initial setup time | Hours–days | Minutes–hours | Minutes (sign-up) |
| Initial disk | ~3 TB | A few percent of full | None |
| Ongoing operation cost | High | Medium | Low (subscription) |
| Historical queries | Full | Post-startup only | Provider-dependent |
| Privacy | Full | Full | Provider sees your queries |
| Custom RPC | Yes | Yes | Provider-fixed surface |
| Best for | Explorers, indexers, archival services, SRs | DApps that need their own sync and current state | Wallets, dashboards, low-volume integrations |
For the two self-hosted paths, follow Deploy a node.
Multiple third-party providers run hosted TRON node services. TronGrid is the most widely used in the TRON community. For a broader list of providers and how to choose one for your region and SLA needs, see Networks.
Related resources
- Deploy a node — End-to-end deployment for Fullnode, SR, and Lite Fullnode
- Database snapshots — Skip cold sync from genesis
- Node maintenance toolkit — Database utilities shipped with the release
- TronGrid — hosted node service for connecting to TRON without running your own node
- Becoming a Super Representative — Apply, register, and operate an SR
Updated 9 days ago