TON Storage in 2026: How It Works, BagID, and TON Node Server Basics

TON Storage is the decentralised file storage layer of The Open Network. In the official TON documentation, it is described as a distributed file storage system that uses torrent-like distribution and optional on-chain payment contracts for paid storage guarantees.

Instead of storing full files inside smart contracts, TON Storage packages content into bags and distributes those bags across peers. The blockchain is then used only where it adds value, such as provider agreements, payments, and proof-of-storage logic.

This is not just a side tool for dApps. TON itself uses TON Storage to distribute archive copies of blocks and state snapshots, which makes it part of the network's real infrastructure rather than a purely experimental add-on.

For builders, the practical use cases are clear: NFT media, static site assets, downloadable bundles, public documents, decentralised distribution, and any content that is better served off-chain than inside blockchain state.

You also do not need to run a validator to use TON Storage. A storage node is a different service from a validator, liteserver, or archive node. If you only want to create, seed, or retrieve files, the relevant tool is storage-daemon.

Most storage systems today depend on centralized infrastructure. Files are stored on physical drives in specific locations, and if something goes wrong — like hardware failure, power outages, or even a fire — data can be lost. That’s why important files are usually copied to multiple servers or data centers in different regions.

Big companies build replication systems and maintain global data centers to avoid data loss and slow delivery. But this comes with high costs and technical complexity. For smaller projects, this level of redundancy isn’t always possible.

Another issue is access speed. If you’re in Europe and your data is hosted in the US, you’ll likely get slower download speeds. To fix this, many services use CDNs (Content Delivery Networks). These networks keep cached copies of data in multiple locations to make access faster for users around the world. But CDNs are still centralized solutions controlled by large providers.

The core problem here is that we’re using centralized tools to try to make storage feel decentralized. The more users and services rely on these setups, the more single points of failure we get — and that goes against the idea of Web3.

What Problems TON Storage Solves

TON Storage removes the need for centralized servers or cloud providers. Instead, it distributes files across a network of independent nodes. Anyone with enough resources can run a storage node and start contributing to the system.

There’s no need for physical replication across corporate-owned data centers. The TON network handles redundancy by design. Files are shared across multiple storage nodes, so if one node goes offline, others still hold the data.

TON Storage also avoids the need for costly on-chain file storage. Storing files directly in smart contracts or blocks is expensive. With TON Storage, you store files off-chain but connect them securely to the blockchain using a unique file identifier (BagID) and cryptographic proof.

What makes it different from torrents is that it includes blockchain-level storage commitments. When you want your data stored reliably, you can create a smart contract with a storage provider. The contract includes payment in Toncoin and proof-of-storage rules. If the provider loses the file or fails to respond to a proof request, they lose the reward or even their deposit.

In short, TON Storage gives you a decentralized file network with real guarantees. No centralized control. No CDN dependencies. Just a smart way to store and serve files globally on Web3.

Bags and BagID

TON Storage organises content into bags. A bag can contain a single file or a whole directory, and each bag is identified by a unique 256-bit BagID, which is the hash of the torrent info cell.

Files inside a bag are split into 128 KiB chunks. TON uses a Merkle tree built from SHA-256 hashes so individual chunks can be verified without downloading the full bag.

This makes TON Storage suitable for large files, immutable collections of site assets, and other content that benefits from chunked distribution and cryptographic verification.

Peer discovery through TON DHT

Nodes that store a bag register themselves in the TON DHT under a key derived from the BagID. When a client wants to retrieve a bag, it queries the DHT to discover seeders and then starts downloading from available peers.

In practice, this means TON Storage behaves like a torrent-style distribution layer, but one that is integrated into TON's networking stack and can be paired with on-chain storage contracts when stronger guarantees are needed.

Running the official storage-daemon

The official implementation is storage-daemon, which TON now documents as part of the TON software suite. The canonical start command remains:

storage-daemon -v 3 -C global.config.json -I <IP>:3333 -p 5555 -D storage-db

Use storage-daemon-cli to manage the daemon, create bags, export metafiles, inspect peers, pause or resume downloads, and control selective downloads.

For downloads and uploads, the current documented command set includes create, add-by-hash, add-by-meta, list, get, get-peers, get-meta, download-pause, download-resume, and priority-name. For partial downloads, TON now documents the --partial flag.

add-by-hash <BagID> --partial file1.txt file2.txt

TON-native file addressing

For direct references to files inside a bag, the current TON documentation uses the tonstorage:// URI scheme:

tonstorage://<BagID>/path/to/file

This is the most future-proof way to explain TON Storage addressing on a reference page because it matches the current TON docs and native TON ecosystem integrations.

Browser access through TON Proxy

For ordinary browser access, the current TON documentation focuses on TON Proxy. The official rldp-http-proxy can intercept .ton, .adnl, and .bag hostnames and forward those requests into the TON network.

rldp-http-proxy -p 8080 -c 3333 -C global.config.json

That makes TON Proxy a better section to document than an old hard-coded HTTP gateway example. If you want a readable public name, combine TON Proxy with TON DNS. If you want a direct content address, use tonstorage://.

TON Storage node vs TON node server

A TON Storage node and a general TON node server are not the same thing. A full node or liteserver stores blockchain state and serves blockchain data. An archive node stores full history. A validator signs blocks. By contrast, storage-daemon is the service that stores and distributes TON Storage bags.

If your goal is file hosting, bag distribution, or decentralised asset delivery, start with TON Storage. If your goal is RPC, historical blockchain queries, or validation, you need a full node, liteserver, archive node, or validator instead.

TON DNS

TON DNS can map a human-readable .ton domain to a TON Storage bag through the dns_storage_address record type:

dns_storage_address#7473 bag_id:bits256 = DNSRecord;

This makes stored files easier to share, because users no longer need to work with a raw BagID every time. In TON DNS terminology, the category name for this mapping is storage.

TON Sites

A bag containing HTML and other static assets can be published as a TON Site when TON Storage is combined with TON DNS and TON Proxy. In that setup, TON Storage carries the content, TON DNS provides the readable name, and TON Proxy bridges browser requests into the TON network.

This is the cleanest way to explain decentralised site hosting on TON in 2026.

NFTs and off-chain media

TON Storage also fits naturally into NFT workflows. The current TON docs explicitly note that NFT collections can reference off-chain media and metadata stored as bags, with individual files addressed through the tonstorage://<BagID>/path format.

That keeps heavy media off-chain while preserving content integrity and TON-native addressing.

Archive distribution and infrastructure

TON Storage is not only for front-end assets. TON itself uses it to distribute archive copies of blocks and state snapshots. Current MyTonCtrl documentation also documents optional downloading of blockchain dumps via TON Storage when operators build archive infrastructure.

This is an important real-world use case because it shows TON Storage already serving network infrastructure, not just application media.

• Canonical documentation refresh: TON Storage, TON DNS, TON Proxy and TON Sites documentation was refreshed in June 2026, which is why older examples and links should be updated.
• Current addressing model: TON now documents tonstorage:// URIs, dns_storage_address records and TON Proxy handling of .bag hostnames as the clearest way to explain access and integration.
• Sub-second finality is live on mainnet: since April 2026, TON mainnet has moved to roughly 400 ms block intervals and about 1 second target finalisation lag. This affects the on-chain side of storage-provider contracts and other TON applications.
• Archive workflows use TON Storage: current node documentation explicitly supports downloading archive data via TON Storage in MyTonCtrl-based setups.

TON Storage should be treated as a distributed content layer, not as a private-by-default vault. If a bag contains sensitive information, the safest approach is to encrypt the files before creating the bag and keep key distribution separate from storage itself.

That way, TON Storage handles decentralised distribution and availability, while confidentiality remains under your own key management.

TON Storage is strongest when content can be packaged into immutable bags and shared across peers: NFT media, static site assets, downloadable archives, public files, and decentralised bundles for apps. It is less of a direct drop-in replacement for highly mutable application data or private back-office storage.

In practice, a lot of teams will use TON Storage for distribution, integrity, and permanence, while still relying on traditional infrastructure for frequently edited files, private databases, or enterprise-style access control.

• NFT metadata and media: keep heavy media off-chain while preserving TON-native addressing.
• TON Sites: host static websites and front-end assets through TON Storage, TON DNS and TON Proxy.
• Public download bundles: distribute documents, media packs, or software assets through bags.
• Archive distribution: support infrastructure workflows that need blockchain dumps or historical state data.
• dApp asset delivery: ship immutable content that should stay addressable by BagID.

If you need stronger retention guarantees than voluntary seeding, TON Storage supports paid storage providers backed by on-chain contracts. In the official model, the smart contract stores the bag's Merkle commitment, issues proof challenges, and manages client payments, while the provider's storage-daemon stores the bag and submits proofs.

Official pricing is expressed in nanoTON per megabyte per day. This makes TON Storage suitable for direct project-to-provider agreements, even though the current TON docs document bilateral provider contracts rather than a protocol-native public marketplace UI.

For most projects in 2026, the cleanest TON Storage workflow is straightforward: create a bag with storage-daemon, store or reference files through tonstorage://, add a .ton domain when readability matters, and introduce provider contracts only where long-term paid persistence is required.

That approach keeps the blockchain light, preserves decentralised distribution, and uses the TON stack the way the current official documentation describes it.

Operating a storage node on TON Storage isn't just about contributing to the network; it's also a potential revenue stream. Storage providers can earn Toncoin through smart contracts, with payments triggered only after proof of storage is verified.

As of late 2025, while a unified "one-click" marketplace is still evolving, the foundational smart contracts are fully operational. Providers are actively earning by engaging in direct storage agreements with dApp developers and NFT projects looking for decentralized hosting solutions.

The horizon for TON Storage is filled with exciting possibilities:

• Marketplace Development: Building a robust platform for storage node operators to offer their services.
• Integration with TON Payments: Streamlining automatic rewards and transactions within the network.
• Developer Engagement: Encouraging developers to build innovative solutions on top of TON Storage.
• Community Tools: Projects like TON Torrent, built with Go, showcase the potential of community-driven tools, though broader adoption is needed.
• Long-Term Storage Solutions: Positioning TON Storage as a reliable option for TON, Web3, and potentially Telegram-related use cases.

By embracing these developments, TON Storage is set to play a pivotal role in the decentralized web's future.