TON Storage

TON Storage is the file-storage component of TON’s infrastructure stack. Conceptually it is close to BitTorrent: arbitrary files are split into chunks, addressed by content hash, and exchanged peer-to-peer between nodes. The difference is the transport layer (ADNL instead of plain TCP/UDP trackers) and the optional payment layer (Toncoin-denominated storage contracts).

Why it exists

Storing large objects directly on a blockchain is expensive and inefficient, so most on-chain apps keep only a hash of the file in the contract and put the bytes somewhere else. Historically that “somewhere else” meant IPFS or centralised cloud storage. TON Storage gives the ecosystem a native alternative:

• NFT collections can keep metadata and images in TON Storage, with only a Bag ID referenced from the contract.
• A ton-sites bundle (HTML/CSS/JS) can be published as a Bag and resolved via TON DNS.
• Any creator who wants to distribute files without depending on a single hoster can publish a Bag and let the network seed it.

How it works

A file or folder is packaged into a Bag of Files — a Merkle structure with a header and a chunk list. The Bag has a unique identifier derived from the content; you publish that identifier (in a smart contract, in TON DNS, or as a plain link).

Storage nodes subscribe to a Bag and keep its chunks locally. A downloading client looks up holders through a DHT running over ADNL and pulls chunks in parallel from whichever peers respond. As long as a complete set of chunks is online somewhere across the swarm, the file remains retrievable.

Storage providers and payments

Beyond purely voluntary seeding, TON Storage defines a Storage Provider smart contract: it accepts Toncoin from a client, commits to hosting a specific Bag for a specific duration, and periodically posts proof-of-storage to draw down its payment. The on-chain logic guarantees that providers only get paid for time during which they actually held the data.

In practice, as of 2025–2026 the storage-provider market is still relatively small. Production use is concentrated in projects that prioritise decentralisation of metadata (NFT teams, research-style dApps) over peak throughput.

Typical usage

• Publishing an NFT collection with metadata stored in TON Storage instead of IPFS.
• Deploying a static site to ton-sites and serving the bundle from a Bag.
• Distributing tooling, documentation archives, or research datasets where a content-addressed handle is preferable to a URL.

Limitations

TON Storage is not a CDN replacement. Latency and availability depend on how many peers seed the Bag, not on geographic proximity. For rarely accessed files with few seeders, performance can be noticeably worse than a hosted bucket; for popular content, peer-to-peer fan-out can help.

Together with TON Sites and TON Proxy, TON Storage forms TON’s “decentralised web” layer — a stack designed to make publishing and consuming content possible without traditional hosting providers.