Blockchain nodes overview

Pick the right TON node setup and understand the operational work it requires.

A full node is a software that stores the whole blockchain state locally, opposite to lite-clients, which request small pieces of data from liteservers when needed. It does not solve any problem itself, but provides a base for other services requiring a full blockchain state (validator, liteserver, etc). Usually, full nodes keep only the latest part of the blockchain state, which is vital for ensuring client applications’ network stability and operation. Full nodes prune the state of the TON blockchain they keep. This means the full node automatically removes earlier blocks that become unnecessary for the network to manage its data volume effectively. To allow client applications to look for blocks and transactions and send new transactions into the TON blockchain, full nodes are equipped with the liteserver functionality.

Full node modes

Role	What it does	When to use it
Liteserver	Stores the latest shards, tracks the masterchain, and serves data to lite-clients.	Required for custom infrastructure, analytics, or to back your own APIs.
Archive liteserver	Stores all blockchain data, including old blocks and states.	Required for explorers and other services working with historical data.
Validator	Signs blocks, participates in elections, and earns rewards.	Needed to run validation with your stake or to operate a nominator pool service.
Collator	Produces blocks for validators.	Needed to reduce load on your validators by setting up block creation on a separate machine.
Nominator pool	Accepts funds from stakers and runs a validator with their stake.	Needed when you want to securely accept stakes from multiple parties and share rewards between them.
Single nominator	Secure way to run a validator without depositing all funds to a hot wallet.	Generally, you should use it each time you want to run a new validator.
Liquid staking	Same as nominator pool, but exchanges stakers’ funds for a synthetic token to be used in DeFi.	Needed to run a liquid staking protocol.

Do you need your own node?

• Run your own full node when you need guaranteed uptime or to serve high-volume workloads without third-party rate limits. Validators and staking services need to install a node and activate validator mode.
• Rely on public endpoints when building prototypes or light integrations. Community liteservers and APIs such as TON Center or other RPC providers already expose the blockchain for read access and transaction submission.

Pick your target environment

If you need	Run
Validator or nominator capacity	Setting up a node using MyTonCtrl with the validator, nominator pool, or single nominator workflows; the wrapper automates validator wallets, overlays, elections, and upgrades.
Liteserver APIs	Setting up a node using MyTonCtrl with liteserver option (and archive mode if needed) to expose API for applications.
An isolated development network	Setting up a local blockchain using MyLocalTon to spin up a local shard, explorer, and APIs for rapid iterations with no mainnet impact.
Kubernetes-native production operations	Use Rust node chart workflows and references.

Rust node overview

TON Rust node is an alternative implementation of a TON full node written in Rust. It is protocol-compatible with TON and follows an operational model designed for containerized environments rather than single-instance deployments.

Rust node operational focus:

• container-based architecture;
• Kubernetes-native deployment model;
• deterministic, version-pinned builds with automated release validation;
• node lifecycle management within a cluster environment;
• integration with external key management systems such as HashiCorp Vault.

Rust node is designed for:

• node providers operating multiple full nodes, liteservers, or validators;
• staking operators managing one or many validators as cluster resources;
• operators running node infrastructure that requires external key management integration and structured operational processes.

This model targets predictable scaling: infrastructure growth is handled through standardized deployment patterns, centralized control, and safer upgrade workflows.

Advantages

• Multi-node deployment and centralized management: a new node can be launched in minutes, excluding sync time, using standardized Helm workflows.
• Fully tested container delivery: release images are version-pinned and validated by more than 10 automated test suites before publication.
• Built-in observability: Rust node exposes Prometheus metrics across 8 subsystems and serves /healthz and /readyz from the same metrics HTTP server.
• Grafana-ready workflow: a bundled dashboard and documented Prometheus/Grafana integration are provided for Kubernetes deployments.
• Key isolation: validator wallet and ADNL keys are designed for Vault-backed workflows instead of direct in-node private key storage.

Rust node resource recommendations

Recommended Kubernetes requests and limits are:

Role	CPU request	CPU limit	Memory request	Memory limit
Full node / liteserver	8	16	32GiB	64GiB
Validator	16	32	64GiB	128GiB

The node can run on fewer resources, but these values provide headroom for load spikes such as elections, heavy traffic, and catch-up after restarts.

Source: TON Rust Node resource recommendations.

Full node

The full node is a basic node type within the TON blockchain. It serves as the backbone of the TON blockchain by keeping its block history — in other words, its current state.

Compared to archive nodes, full nodes keep only the latest part of the blockchain state, which is vital for ensuring client applications’ network stability and operation. Full nodes prune the state of the TON blockchain they keep. This means the full node automatically removes earlier blocks that become unnecessary for the network to manage its data volume effectively.

To allow client applications to look for blocks and transactions and send new transactions into the TON blockchain, full nodes are equipped with the liteserver functionality.

Archive node

The archive node is a full node that keeps the entire block history of the TON blockchain. These nodes act as the decentralized point of truth to ensure consistency of the whole blockchain history. They are a backend for blockchain explorers and other applications relying on deep transaction history.

Archive nodes do not prune the blockchain state, elevating system requirements, especially in storage. According to the latest estimations, while full and validator nodes require about 1 TB of disk space, archive nodes need about 12 TB to store the complete block history.

Validator node

Validator nodes or validators are the TON network participants who propose new blocks and verify transactions according to the TON’s proof-of-stake mechanism. In this way, validators contribute to the overall blockchain security.

Validators get rewards in TON for successful participation in the validation process.

To be entitled to propose and validate blocks, other participants elect validators based on the amount of TON they hold — in other words, their stake. The more TON a validator stakes, the higher its chances of being elected, validating blocks for the network, and earning rewards. As a rule, validator operators motivate other TON holders to stake with them to get passive income from the resulting rewards. In this way, validators ensure network stability and security and contribute to its growth.

Interacting with TON nodes

TON nodes can run in liteserver mode, which allows external applications to interact with the TON blockchain. In this mode, the nodes process client requests, enabling clients to access blockchain data, send transactions, and retrieve information about blocks and transactions.

Full and archive nodes typically enable liteserver mode because they store blockchain history and handle external requests. In contrast, validator nodes do not need it, as they focus on efficiently validating new blocks without additional workload from external queries. Use MyTonCtrl to enable liteserver mode in a full or archive C++ node.

Liteserver mode, or liteserver for short, uses the Abstract Datagram Network Layer (ADNL) protocol. Direct connections require either a client called lite-client downloaded from the latest TON release, or a library that understands ADNL. In the SDK table, such libraries have a mark in the ADNL column.

To connect from a webpage or otherwise interact with TON nodes over HTTP, an HTTP-to-ADNL frontend is required. TON Center is an official HTTP API provider, and its API endpoints can be used directly or self-hosted. In the SDK table, libraries that use these endpoints or other HTTP providers have a mark in the HTTP column.