TON node requirements in 2026: full node, liteserver, validator

A TON full node or liteserver needs 16 CPU cores, 64–128 GB of RAM, at least 1 TB of NVMe SSD, a symmetric 1 Gbit/s link and a static public IP, per TON’s documentation as of October 2026. Archive nodes need 16–20 TB of NVMe; validators need 128 GB of RAM and about 1,000,000 GRAM of stake in practice.

The figures come from TON’s node guides on docs.ton.org and the MyTonCtrl repository, checked on October 15, 2026; where official pages disagree, we give both. Stakes are in GRAM, Toncoin’s new name since June 15, 2026. This guide covers hardware and setup, not staking advice.

The short version

Every node also needs a static public IPv4 address, one inbound UDP port and open outbound traffic, on Ubuntu 22.04 or 24.04 LTS (the liteserver guides also accept Debian 11 and 12). Validator stake starts at a technical minimum of 300,000 GRAM, and the validator guide budgets 1.4 to 4 million.

Full node, liteserver, archive or validator: which do you need?

TON’s docs call the full node “a basic node type”; the other roles build on it.

• Full node keeps the current state and prunes the rest. MyTonCtrl, the tool the docs use for every official node, has no separate full-node mode: its installer offers validator, liteserver and collator, and a liteserver is the closest match to a plain full node.
• Liteserver is a full node that also answers lite-client queries over ADNL, TON’s own network protocol. Web applications need an HTTP-to-ADNL frontend; the docs point to TON Center, an official HTTP API that can be used directly or self-hosted.
• Archive liteserver never prunes, so it serves every historical block and state, for explorers and other services that need history.
• Validator signs blocks and takes part in elections, which requires stake. A collator, which produces blocks for validators on a separate machine, is also documented, but the pages we checked give no hardware figures for it.

The docs’ rule of thumb: run your own node “when you need guaranteed uptime or to serve high-volume workloads without third-party rate limits”, and rely on public endpoints for prototypes and light integrations.

TON full node and liteserver hardware requirements

TON’s liteserver guide asks for:

• CPU: 16 cores.
• Memory: 64 GB. The requirements table in the MyTonCtrl setup guide says 128 GB for the same role.
• Storage: at least 1 TB of NVMe Gen4 or newer, enterprise grade preferred, sustaining at least 64,000 provisioned IOPS. On non-enterprise SSDs, Autonomous Power State Transition (APST) must be disabled.
• Network: 1 Gbit/s symmetric, about 16 TB a month at peak load, and a fixed public IP address.
• Software: Ubuntu 22.04/24.04 LTS or Debian 11/12, with Python 3.10 or later. The MyTonCtrl README marks Debian 13 as not supported and Debian 10 as deprecated, and recommends Ubuntu 22.04 or 24.04.

The installer enforces part of this. On mainnet, install.sh stops with “Insufficient resources” below 16 CPUs or about 64 GB of RAM (8 CPUs and 16 GB on testnet) unless you pass -i. It counts CPUs with lscpu, which reports threads, so an 8-core, 16-thread processor passes a check that the guide’s “16 cores” would not. For production, we would size by the stricter figures: 16 physical cores and 128 GB.

The guide’s disk benchmark sets a lower bar than its requirements: a minimum acceptable fio result of 10,000 IOPS for both reads and writes, against the 64,000 above. Its latency targets are about 50 ms to the nearest network beacon and up to 300 ms to the farthest. A note in the MyTonCtrl table adds that Hetzner and OVH are acceptable for liteservers but not for validators, without giving a reason.

How much disk does a TON node use in 2026?

Most nodes start from a database dump rather than syncing from peers. TON’s dump server publishes each file’s compressed and extracted size. The latest dumps, dated October 15, 2026:

With -d, MyTonCtrl downloads the archive into a cache folder inside the TON work directory, verifies its SHA-256 checksum, extracts it and deletes it. It checks first that both copies fit: about 619 GB on mainnet at the October 15 size, or 1.35 TB on testnet, the larger of the two. The liteserver guide asks for more than 740 GB free in /var.

Growth then depends on retention. The liteserver guide installs with ARCHIVE_TTL=2592000 and STATE_TTL=86400, which keep 30 days of archive data and one day of states; MyTonCtrl’s default archive retention is 30 days for liteservers and one day for other modes. TON’s overview puts full and validator nodes at about 1 TB, “according to the latest estimations”. Treat that as a floor, since the restore step alone takes about 619 GB.

For archive nodes, the docs give four figures:

• about 12 TB “to store the complete block history”, in the overview;
• at least 12 TB of fast storage, in the MyTonCtrl guide’s archive quickstart;
• at least 16 TB with ZFS lz4 compression, or 20 TB without, in the archive liteserver guide;
• at least 20 TB of NVMe or a compressed ZFS pool, in the MyTonCtrl table, with the note “Plan for continuous growth”.

We found no official page that dates an archive size. Size for the archive guide’s 16 TB compressed or 20 TB raw, and watch free space.

TON archive node requirements

The archive liteserver guide keeps 16 cores and 128 GB of RAM, asks for an open-files limit above 4,000,000, and requires NVMe Gen4 or newer sustaining at least 64,000 provisioned IOPS. It builds the storage on ZFS, for compression and snapshots:

sudo apt install -y zfsutils-linux
sudo zpool create -o ashift=12 data <DISK>
sudo zfs set compression=lz4 data
sudo zfs create data/ton-work
sudo zfs set mountpoint=/var/ton-work data/ton-work

“If sufficient disks are available”, the guide suggests a mirror or raidz for redundancy, and it warns that a stripe adds capacity but also the risk of data loss. The node is installed with -m liteserver --archive, which sets permanent retention, and the historical blocks arrive through TON Storage. The download takes one to several days depending on your connection, then import and final sync take one to several days each: up to a week in all.

TON validator requirements: hardware and stake

The validator guide’s minimum is stricter than the MyTonCtrl table on disks and network, and looser on CPU:

Both require a static public IP; the guide adds Ubuntu 22.04 or 24.04 LTS, Python 3.10 or later and Clang 21 or later. Its disk test runs fio with 4k random I/O at 75% reads on the drive that will hold /var/ton-work, and the pass mark is 250,000 read IOPS (981 MB/s) and 83,000 write IOPS (327 MB/s). The guide warns that slow storage “can severely impact validator stability”, and the table says to keep spare capacity for elections and snapshots.

Stake. TON’s staking overview puts the technical minimum at 300,000 GRAM and says the actual minimum is “typically higher, approximately 1,000,000 GRAM”. The validator guide budgets a deposit of 1.4 to 4 million GRAM “to cover both validation rounds”: MyTonCtrl splits the pool balance 50/50 between odd and even cycles, and the guide suggests a stake that places the validator between positions 200 and 250. Operating fees come on top, about 200 GRAM a month from the validator’s hot wallet, where the guide says to keep at least 600 GRAM.

Pools and penalties. The guide installs MyTonCtrl in single-nominator mode, which separates the owner’s cold wallet from the validator’s hot wallet; the multi-party nominator pool is deprecated. A validator that processes less than 90% of its expected blocks in a round is fined 101 GRAM, and validators that break the maintenance rules “are fined and excluded from the network”. The guide names @tonstatus as the mainnet announcement channel to follow.

Ports, static IP and bandwidth

The MyTonCtrl guide asks for a static public IPv4 address for each node, a single inbound UDP port, and all outbound ports open:

The UDP port is random unless you set VALIDATOR_PORT before installing; the status command shows it under “Node ports”. Both liteserver guides enable ufw with only SSH allowed, then read the two ports from config.json and open them:

sudo ufw allow <NODE_UDP_PORT>
sudo ufw allow <LITESERVER_PORT>
sudo ufw status

On bandwidth, 1 Gbit/s is the baseline for every role, and the validator guide’s minimum list says 5 Gbit/s. Monthly volume is what separates the roles: about 16 TB at peak for liteservers, 64 to 100 TB for validators. For scale, 64 TB in a 30-day month averages about 200 Mbit/s, or 100 Mbit/s each way if traffic is symmetric, consistent with the validator guide’s average of about 100 Mbit/s. On a metered plan, that volume shows up on the bill; on an unmetered 10 Gbps port, it does not.

Which PowerDedi server for a TON node

• RAID. On two-drive servers, keep the default RAID 1 for a validator or liteserver: 1.92 TB mirrored holds today’s 349 GB database with room to spare, and a single drive failure does not stop the node. RAID 0 doubles the space, but a dead drive then means a fresh restore, and a validator that falls below 90% of its expected blocks is fined. Our software RAID guide describes each layout.
• Archive layout. On the EPYC 9965, the default RAID 10 leaves 15.36 TB, under the guide’s 16 TB floor. Choose RAID 5 when ordering (23.04 TB, one drive of redundancy, no compression), or install from an ISO through the IPMI/KVM console and build the ZFS pool the guide describes; raidz across the four drives keeps three drives’ worth of space. The 9965 is far more CPU than TON asks for. The EPYC 9555P, at 15.36 TB even striped, is too small, and our HDD storage servers have the capacity but not the NVMe IOPS.
• Test the drives before you stake. The validator bar of 250,000 read and 83,000 write IOPS applies to each drive, so run the guide’s fio test in the first hour. Billing is month to month, with no setup fee.
• Under 16 cores. The Ryzen 9 9900X (12 cores), Ryzen 7 7700 and Xeon E-2488 (8 cores each) pass the installer’s CPU check, which counts threads, but not the documented 16 cores, and their 64 GB is half the validator figure.
• Location. The docs set latency targets, not a region: about 50 ms to the nearest beacon and up to 300 ms to the farthest, tested against beacon-eu-01 and beacon-apac-01. The 9950X is offered in eight cities, Singapore and Tokyo included; the 4585PX in Amsterdam, Frankfurt, London and New York. Ping both beacons on day one.

Every server has its own static IPv4 address, a routed /64 of IPv6 and a 10 Gbps port. Running nodes and validators is allowed under our acceptable use policy; mining is not. We do not accept GRAM: payment is in BTC, ETH, XMR, USDT on TRON or SOL. Current stock is on our blockchain node hosting page.

How to install a TON node with MyTonCtrl

The guides benchmark the server first, then run MyTonCtrl’s installer as a non-root user with sudo rights. The commands below are TON’s; choose one install line.

# 1. Benchmark the disk that will hold /var/ton-work, then latency
fio --randrepeat=1 --ioengine=libaio --max-jobs=16 --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=10G --filename=/tmp/bench
ping beacon-eu-01.toncenter.com -c 6
ping beacon-apac-01.toncenter.com -c 6

# 2. Prerequisites and installer
sudo apt update
sudo apt install -y curl wget git ca-certificates python3-pip
wget https://raw.githubusercontent.com/ton-blockchain/mytonctrl/master/scripts/install.sh

# 3a. Liteserver, 30 days of blocks, restored from the dump
export ARCHIVE_TTL=2592000 STATE_TTL=86400 && sudo -v && nohup sudo bash install.sh -m liteserver -n mainnet -d > mytonctrl_installation.log 2>&1 &

# 3b. Archive liteserver, blocks from TON Storage
sudo -v && nohup sudo bash install.sh -m liteserver -n mainnet --archive > mytonctrl_installation.log 2>&1 &

# 3c. Validator through a single nominator pool
sudo bash install.sh -m single-nominator -n mainnet

# 4. Follow the install, then open the console and run status
tail -f mytonctrl_installation.log
mytonctrl

Change /tmp/bench if /tmp sits on a different filesystem, as the guide notes. The installer builds the node from TON’s repository, and -v pins a branch, tag or commit; the latest node release on GitHub is TON v2026.08, published on August 17, 2026. Before serving queries or staking, wait until status reports the node in sync, then apply the firewall rules above.

Common questions

Can I run a TON node on a VPS? For a liteserver, possibly: the MyTonCtrl guide mentions cloud security groups and “provisioned” IOPS, so it expects some nodes in the cloud. The test is whether you get the resources in full: 16 dedicated cores, 64–128 GB of RAM, 64,000 IOPS and a static IPv4. A validator’s per-drive 250,000 read IOPS and 5 Gbit/s minimum point to dedicated hardware.

How long does a TON node take to sync? A liteserver install takes up to three hours, plus one to several hours of final sync. The validator guide expects about three hours to synchronize and says a dump cuts that “from hours to minutes”. An archive liteserver can take up to a week.

Is Toncoin the same as Gram? Yes. ton.org calls Gram “the native coin of the TON blockchain” and notes it was “also known as Toncoin”. The ticker changed from TON to GRAM on June 15, 2026; the network is still The Open Network, and balances and addresses were unaffected.

Running nodes on more than one chain? See also our Solana RPC node hardware guide.

Sources

• Run a validator — TON Docs
• Run a liteserver — TON Docs
• Run an archive liteserver — TON Docs
• Run a node with MyTonCtrl — TON Docs
• MyTonCtrl overview — TON Docs
• Blockchain nodes overview — TON Docs
• Staking overview — TON Docs
• MyTonCtrl README, scripts/install.sh and mytoninstaller/dump.py — ton-blockchain on GitHub
• Index of /dumps/ — TON database dumps (mainnet and testnet dumps of October 15, 2026)
• Releases — ton-blockchain/ton on GitHub (TON v2026.08, August 17, 2026)
• TON — The Leading L1 Blockchain — ton.org
• TON Native Token to Be Renamed Gram on June 15, 2026 — KuCoin News (June 9, 2026)