What Is a TON Full Node and When Should You Run One?

Quick Decision Guide: Run Your Own TON Node or Use Managed Infrastructure?

Before diving into the technical details, it helps to know whether running a TON full node is even the right move for your project. The answer depends on your workload, team resources, and reliability requirements.

Consider running your own TON full node if:

• You need low-latency access to TON data for high-frequency trading or real-time analytics.
• You want full control over the node's configuration and data retention.
• You have the DevOps expertise to handle upgrades, monitoring, and incident response.
• Your application generates heavy read traffic that would exceed shared RPC rate limits.

Consider using a managed RPC service like OnFinality instead if:

• You want to focus on your product rather than node operations.
• You need high availability without the overhead of running a redundant node cluster.
• Your traffic is spiky or unpredictable, and you want to scale without provisioning hardware.
• You prefer to pay for what you use rather than committing to fixed infrastructure costs.

If you're still unsure, start with a managed RPC endpoint to validate your application, then revisit the decision once you understand your actual load. OnFinality offers TON RPC endpoints and dedicated nodes that can serve as a reliable baseline.

What Is a TON Full Node?

A TON full node is a server that maintains a complete copy of The Open Network's blockchain. It validates all transactions and blocks, stores the full state, and participates in the network's gossip protocol. Unlike a light client, which only downloads block headers and asks full nodes for specific data, a full node independently verifies the entire history.

TON's architecture is sharded, meaning the network is split into multiple shardchains to process transactions in parallel. A full node in TON typically tracks the masterchain and one or more shardchains. The masterchain coordinates validators and stores the network's configuration, while shardchains handle user transactions. This design allows TON to scale horizontally, but it also means running a full node requires careful configuration to keep up with all the chains you want to monitor.

Why Run a TON Full Node?

There are several reasons why a developer or infrastructure team might choose to run a TON full node:

• Data sovereignty: You have direct access to raw blockchain data without relying on a third-party API.
• Custom queries: You can run complex queries against the full state, which might be restricted or expensive on public RPC services.
• Performance: For latency-sensitive applications, a local node eliminates network round-trips to a remote RPC provider.
• Learning: Running a node is an excellent way to understand TON's internals, which can inform smart contract development and debugging.

However, these benefits come with real costs. A TON full node requires substantial hardware, ongoing maintenance, and careful monitoring. For many teams, the operational burden outweighs the advantages, especially when managed services can offer comparable performance with less overhead.

Hardware and Storage Requirements

Running a TON full node is not a trivial task. Based on community guidance and the network's growth, you should plan for the following minimum specifications:

These are rough estimates. The actual requirements depend on how many shardchains you track and your query patterns. You should monitor disk usage and upgrade storage before it fills up.

Setting Up a TON Full Node

TON provides official node software, but the setup process is involved. Here's a high-level overview of the steps:

1. Install dependencies: You'll need a recent Linux distribution, build tools, and the TON source code.
2. Build the node: Compile the ton binaries from source or use pre-built packages if available.
3. Configure the node: Create a configuration file that specifies which networks (mainnet, testnet) and shardchains to follow.
4. Sync the blockchain: The initial sync can take days, depending on your hardware and network speed.
5. Run the node: Use a process manager like systemd to keep the node running.
6. Monitor: Set up logging and alerts for common issues like sync lag or disk space.

Here's an example of a basic systemd service file for a TON node:

[Unit]
Description=TON Full Node
After=network.target

[Service]
User=ton
ExecStart=/usr/local/bin/ton-node --config /etc/ton/ton-global.config.json
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

This is a simplified example. The actual command and configuration will depend on the specific node software you're using. Always refer to the official TON documentation for the most current instructions.

Common Pitfalls and How to Avoid Them

Running a TON full node comes with several challenges that can trip up even experienced developers:

• Sync issues: If your node falls behind the network, it can take a long time to catch up. Monitor sync status regularly and ensure your hardware can keep up.
• Storage exhaustion: The blockchain grows continuously. Set up alerts for disk usage and plan to add storage or prune old data if possible.
• Network connectivity: TON nodes need to maintain connections to peers. Firewalls or NAT configurations can cause connectivity problems.
• Software updates: TON's protocol evolves, and you'll need to update your node software to stay compatible. Subscribe to release announcements and test upgrades on a testnet first.

Managed RPC vs. Running Your Own Node

For many production applications, using a managed RPC service is a more practical choice than running your own full node. Here's a comparison to help you decide:

Managed services like OnFinality provide TON RPC endpoints that are ready to use, with support for HTTP and WebSocket. They also offer dedicated nodes if you need a private, isolated instance without the operational overhead.

How to Connect to a TON Full Node or RPC Endpoint

Once you have a TON node running (or you're using a managed endpoint), you can interact with it using TON's HTTP API. Here's a simple example using curl to get the latest masterchain block:

curl -X POST https://ton.access.onfinality.io/api/v1/ton/mainnet -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"ton.getMasterchainInfo","params":[]}'

Replace the URL with your own node's endpoint if you're running one. The response will include the latest block number, hash, and other chain information.

For JavaScript developers, you can use libraries like ton or ton-core to interact with the node. Here's a minimal example using the ton npm package:

import { TonClient } from "ton";

const client = new TonClient({
  endpoint: "https://ton.access.onfinality.io/api/v1/ton/mainnet",
});

async function getLatestBlock() {
  const masterchainInfo = await client.getMasterchainInfo();
  console.log(masterchainInfo);
}

getLatestBlock();

This code connects to a TON endpoint and fetches the latest masterchain information. You can then use the client to query accounts, send transactions, and more.

Monitoring and Maintaining Your Node

If you do decide to run your own node, you'll need to set up monitoring to ensure it stays healthy. Key metrics to track include:

• Sync status: How far behind the network is your node?
• CPU and memory usage: Are resources being exhausted?
• Disk space: Is storage running low?
• Network traffic: Are you receiving and sending blocks efficiently?

You can use tools like Prometheus and Grafana to collect and visualize these metrics. Set up alerts to notify you when something goes wrong, such as when sync lag exceeds a threshold or disk usage crosses a warning level.

Key Takeaways

• A TON full node gives you complete control and direct access to blockchain data, but it requires significant hardware and maintenance.
• For many applications, a managed RPC service is more cost-effective and reliable, especially if you lack DevOps resources.
• If you run your own node, plan for storage growth, monitor sync status, and stay up to date with software releases.
• OnFinality offers both TON RPC endpoints and dedicated nodes to support your infrastructure needs.

Frequently Asked Questions

What is the difference between a TON full node and a validator?

A full node stores and validates the blockchain but does not produce new blocks. A validator is a full node that also participates in consensus and earns rewards for proposing and validating blocks. Running a validator requires staking TON and additional responsibilities.

How long does it take to sync a TON full node?

Initial sync can take anywhere from a few hours to several days, depending on your hardware, network speed, and how many shardchains you're tracking. Using a fast SSD and a good internet connection will speed up the process.

Can I run a TON full node on a cloud server?

Yes, you can run a TON node on a cloud VPS, but you'll need to ensure the instance has sufficient CPU, RAM, and storage. Cloud providers often charge extra for high-performance SSDs, so factor that into your cost analysis.

What is the cost of running a TON full node?

Costs vary based on hardware and hosting. A dedicated server with the recommended specs might cost $100–$300 per month, plus electricity if self-hosted. Managed RPC services offer predictable pricing based on usage, which can be more economical for smaller projects.

How do I choose between a shared RPC endpoint and a dedicated node?

Shared endpoints are suitable for development and low-traffic applications. If you need consistent performance, higher rate limits, or custom configuration, a dedicated node is a better choice. OnFinality provides both options, so you can start with a shared endpoint and upgrade as your needs grow.

For more details on pricing and network support, see our RPC pricing and supported networks pages.