What is a TON RPC node and how do you use one?

What is a TON RPC Node?

A TON RPC node is a server that exposes the TON blockchain's API via the Remote Procedure Call (RPC) protocol. It allows external applications—such as wallets, explorers, and dApps—to query the blockchain state, retrieve transaction history, and submit new transactions. TON nodes typically run in liteserver mode, which means they serve lightweight client requests without requiring the client to store the full blockchain.

The TON blockchain uses a unique architecture with sharding and masterchains. A full node stores the latest shards and tracks the masterchain, enabling it to respond to queries about account balances, block information, and transaction statuses. For applications that need historical data, an archive liteserver stores the entire blockchain history.

TON Node Modes and Their Use Cases

TON documentation defines several node modes, each optimized for different tasks:

Choosing the right mode depends on your application's requirements. Most dApps only need a liteserver for real-time data, while explorers and analytics platforms require archive nodes.

Self-Hosted vs. Managed TON RPC Nodes

You have two primary options for accessing a TON RPC node: run your own node or use a managed RPC provider. Each approach has trade-offs in terms of cost, control, and operational complexity.

Running your own TON full node gives you full control over the infrastructure, data privacy, and no rate limits. However, it requires significant DevOps effort: you must provision hardware, sync the blockchain (which can take days), monitor uptime, and handle scaling. The TON documentation recommends at least 8 CPU cores, 32 GB RAM, and a fast SSD for a full node.

Managed RPC providers like OnFinality handle node deployment, maintenance, and scaling. They offer geo-balanced endpoints that reduce latency by routing requests to the nearest server. This is ideal for production applications that need high availability and low response times without the operational burden.

• Self-hosted: Full control, no rate limits, but high operational overhead and upfront sync time.
• Managed: Low latency, automatic scaling, built-in monitoring, and support for both mainnet and testnet.
• Hybrid: Some teams run their own validator nodes while using a managed provider for public RPC traffic.

How to Choose a TON RPC Provider

When evaluating TON RPC providers, consider the following criteria to ensure your application performs reliably:

Many providers offer free tiers or trial periods, so you can test performance before committing. OnFinality provides TON RPC endpoints with competitive performance and dedicated node options for high-demand projects.

Making Your First TON RPC Call

Once you have a TON RPC endpoint, you can interact with the blockchain using standard JSON-RPC calls. TON uses the ADNL protocol for node communication, but most managed providers expose a standard HTTP RPC interface.

Here's an example using curl to get the latest masterchain block number:

Replace YOUR_ENDPOINT_URL with your actual RPC endpoint. The method 'getMasterchainInfo' returns the current masterchain block number, which you can use to verify connectivity.

• curl -X POST YOUR_ENDPOINT_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getMasterchainInfo","params":[]}'
• Common methods: getAccountState, getTransactions, sendBoc (send external message), runGetMethod.
• Always handle errors gracefully and implement retry logic for transient failures.

Best Practices for Production TON RPC Usage

To ensure your TON dApp runs smoothly in production, follow these best practices:

By following these practices, you can build a resilient application that handles traffic spikes and network issues gracefully.

• Use multiple RPC endpoints for redundancy—fallback to a secondary provider if the primary is unavailable.
• Implement connection pooling and keep-alive to reduce overhead from repeated handshakes.
• Monitor RPC response times and error rates to detect issues early.
• Cache frequently accessed data (e.g., account balances) to reduce RPC calls.
• Use testnet for development and staging to avoid mainnet costs and risks.
• Consider dedicated nodes if your application has high throughput or requires custom configuration.

Conclusion

A TON RPC node is the essential gateway for building on The Open Network. Whether you choose to run your own node or use a managed provider like OnFinality, understanding the different node modes and selection criteria will help you make an informed decision. For most production applications, a managed RPC service offers the best balance of performance, reliability, and ease of use.

Start by testing with a free tier or trial, evaluate latency from your target regions, and scale up as your user base grows. With the right infrastructure, you can focus on building great dApps on TON.

Frequently Asked Questions