TON Nodes: What They Are and When to Run One vs. Use a Provider

TON Nodes Decision Checklist

Before deciding to run your own TON node, consider these factors:

• Do you need full historical data? Archive nodes store all blockchain history, while full nodes prune old data. Hosted providers often offer archive endpoints without the storage cost.
• Are you building a block explorer or analytics tool? You likely need an archive node or a hosted API that indexes historical data.
• Do you need to validate and earn rewards? Only run a validator node if you have enough TON stake and operational expertise.
• Can you handle maintenance? Self-hosted nodes require regular updates, monitoring, and backup. Hosted services handle this for you.
• What is your traffic pattern? If your dApp has variable traffic, a hosted RPC with auto-scaling may be more cost-effective than provisioning for peak load.

What Is a TON Node?

A TON node is a software client that maintains a copy of the TON blockchain state and participates in the network. Nodes validate transactions, propagate blocks, and serve data to lite clients (wallets, dApps). TON nodes use the ADNL (Abstract Datagram Network Layer) protocol for peer-to-peer communication and can expose a JSON-RPC interface for external applications.

There are several types of TON nodes, each with a different role:

• Full node (liteserver): Stores the latest shards and masterchain state, prunes old data, and serves lite clients. Suitable for custom infrastructure or backing your own API.
• Archive node (archive liteserver): Retains all historical blocks and state. Required for block explorers, analytics, and services that need full history.
• Validator node: Participates in consensus by signing blocks and earning rewards. Requires a stake of TON and a reliable setup.
• Collator node: Produces blocks for validators to reduce load on the validator machine.
• Nominator pool: Accepts stakes from multiple parties and runs a validator on their behalf.

When Should You Run Your Own TON Node?

Running your own node gives you full control over data access, latency, and reliability. It is the right choice if:

• You need unfiltered, direct access to the blockchain without relying on a third party.
• You operate a validator or collator to secure the network and earn rewards.
• You run a block explorer or data service that requires an archive node.
• You have the DevOps resources to maintain and monitor the node 24/7.

However, self-hosting comes with costs: dedicated hardware (or cloud instances), storage (archive nodes can be hundreds of GB), bandwidth, and ongoing maintenance. For many teams, the operational burden outweighs the benefits.

When to Use a Hosted TON RPC Provider

Most dApp developers and infrastructure buyers choose a hosted RPC provider because it simplifies operations and improves reliability. Hosted services offer:

• Managed infrastructure: No need to sync, update, or monitor nodes.
• Geo-distributed endpoints: Lower latency for users worldwide.
• Auto-scaling: Handle traffic spikes without provisioning for peak load.
• Archive access: Query historical data without storing it yourself.
• Multiple network support: Access mainnet and testnet from a single API key.

OnFinality provides TON RPC endpoints for both mainnet and testnet, with dedicated node options for high-throughput workloads. You can get started quickly without managing any infrastructure.

TON Node Setup: A Quick Overview

If you decide to run your own node, here is a high-level summary of the steps. Detailed instructions are in the TON documentation.

Prerequisites

• A Linux server (Ubuntu 20.04+ recommended) with at least 8 CPU cores, 32 GB RAM, and 500 GB SSD for a full node (archive nodes need more).
• Open ports for ADNL (TCP 30303, UDP 30303) and liteserver (TCP 8080).
• Basic knowledge of command line and system administration.

Installation (C++ Node)

1. Clone the TON repository:

   git clone https://github.com/ton-blockchain/ton.git
   cd ton

1. Build the node:

   mkdir build && cd build
   cmake .. -DCMAKE_BUILD_TYPE=Release
   make -j$(nproc)

1. Configure the node by editing config.json with your settings.
2. Start the node:

   ./validator-engine -C config.json

Interacting with Your Node

Once your node is running, you can use the lite-client tool to query the blockchain:

./lite-client -C lite-client-config.json -a 127.0.0.1:8080

Or send JSON-RPC requests to the liteserver endpoint:

curl -X POST http://127.0.0.1:8080/jsonRPC -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getMasterchainInfo",
  "params": []
}'

TON Node Types Comparison

Criterion	What to check	Why it matters
Data retention	Full node prunes old blocks; archive node keeps everything	Archive needed for historical queries; full node is cheaper
Hardware requirements	Full node: 8 CPU, 32 GB RAM, 500 GB SSD; archive: more storage	Underprovisioning causes sync failures or poor performance
Network participation	Validator signs blocks; liteserver only serves data	Validators need stake and high uptime; liteservers are simpler
Maintenance effort	Updates, monitoring, backups	Self-hosted requires ongoing DevOps; hosted eliminates this
Cost	Self-hosted: server + bandwidth + time; hosted: subscription	Hosted can be cheaper for low-to-medium traffic

Common Pitfalls When Running TON Nodes

• Insufficient storage: Archive nodes can exceed 1 TB. Monitor disk usage and plan for growth.
• Network configuration: Firewalls must allow ADNL and liteserver ports. Misconfiguration leads to sync failures.
• Sync time: Initial sync can take days. Use snapshots or a trusted provider to speed up.
• Version updates: The TON protocol evolves. Keep your node software up to date to avoid being forked out.

How to Choose Between Self-Hosted and Hosted TON Nodes

Evaluate your team's capacity and application requirements:

• Team size: Small teams benefit from hosted services that reduce operational load.
• Traffic patterns: If your app has unpredictable spikes, hosted auto-scaling is more reliable.
• Data needs: Archive access is easier with a provider that offers it out of the box.
• Budget: Self-hosting may seem cheaper initially, but factor in engineering time and incident response.

For most production dApps, a hosted RPC provider like OnFinality offers the best balance of performance, reliability, and cost. Check our RPC pricing and supported networks to see if TON fits your stack.

Key Takeaways

• TON nodes come in several flavors: full, archive, validator, collator, and nominator pool.
• Self-hosting gives full control but requires significant operational investment.
• Hosted RPC providers simplify infrastructure management and offer geo-distributed, scalable endpoints.
• OnFinality provides managed TON RPC endpoints and dedicated nodes for production workloads.
• Always evaluate your data retention, traffic, and team capacity before choosing a path.

Frequently Asked Questions

Q: Do I need a TON node to build a dApp?
A: No. You can use a hosted RPC provider to interact with the blockchain without running your own node.

Q: What is the difference between a full node and an archive node?
A: A full node prunes old blockchain data to save storage, while an archive node retains all historical data. Archive nodes are needed for block explorers and analytics.

Q: How much does it cost to run a TON node?
A: Self-hosted costs vary by cloud provider and storage. Expect $50–$200/month for a full node, more for archive. Hosted plans start at $0 for free tier.

Q: Can I use OnFinality for TON testnet?
A: Yes, OnFinality supports both TON mainnet and TON testnet.

Q: What is ADNL?
A: ADNL (Abstract Datagram Network Layer) is TON's low-level networking protocol for node-to-node communication. Most developers interact via JSON-RPC instead.

Related resources

• TON RPC Endpoints
• TON Testnet RPC
• RPC Pricing

Originally published at OnFinality.