Inside Levity: Polkadot's Decentralized Storage Layer

Discover how Levity combines the Bulletin Chain and HOP to provide decentralized, verifiable storage and peer-to-peer content delivery for applications built on Polkadot.

Most applications depend on someone else's server to store their files. A profile photo lives on S3. An app bundle is served from a CDN. A published article is hosted on a platform that controls access and can pull it down. The content is available because a company decided to keep it available.

Levity, combining the Bulletin Chain and the Handoff Protocol (HOP), takes a different approach. Files are stored across a distributed network of independent nodes, with many different operators with no shared incentive to take content down. Anyone with the content identifier can fetch the bytes and verify they got exactly what was published, without trusting any single host that served them.

That is the core idea. The rest of this article explains how it works and why the design decisions behind it matter.

What is Levity

Levity is Polkadot's decentralized storage and delivery layer, combining two components: the Bulletin Chain, which holds the on-chain storage records, and HOP, the Handoff Protocol, which handles delivery of data payloads across the network.

Together, they are built to hold the content that products publish. Anything that needs to outlive a session and be retrievable later by hash: profile photos, app bundles, published articles, encrypted message content, frontend assets. Levity is live on testnet today and on track for Polkadot mainnet in the coming months. This article covers the current experimental implementation and the direction it is heading.

If you have used IPFS, the mental model carries over directly. Content is addressed by its hash. Readers can fetch from the peer-to-peer network without a centralized host in between.

Two differences from standalone IPFS are worth pointing out. First, the storage records live natively on Levity. The chain pins the commitment that content existed and was valid at write time, rather than relying on external pinning services or hoping someone is still seeding. 

Second, Levity requires explicit authorization to write. This is a deliberate design choice: not everyone can upload. Authorization is granted by a privileged origin, which keeps the network from becoming an open dump and ensures the content stored there has been sanctioned by someone accountable for it.

Use Cases

The Bulletin Chain is suited for any scenario where you need decentralized, content-addressable storage on Polkadot. Common use cases include:

• Static sites: Host a static website entirely on-chain, served via IPFS-compatible gateways.
• Images and media assets: Store images, icons, or other media files with permanent, verifiable CIDs.
• Application data: Persist configuration files, metadata, or other structured data that needs to be publicly accessible and tamper-proof.
• Document storage: Store documents, certificates, or records that benefit from on-chain verifiability.

Key Concepts

• No balances: The chain does not use token balances for transaction fees. Authorization is required to store data.
• Authorization-based access: Accounts must be authorized before they can submit storage transactions.
• Content Identifiers (CIDs): Stored data is addressable via IPFS-compatible CIDs, enabling interoperability with IPFS tooling.
• Retention periods: Stored data is retained for a limited period (~2 weeks on Polkadot TestNet) and must be renewed to persist beyond that.
• Chunked uploads: Large files (up to ~64 MiB) can be split into chunks, each stored as a separate transaction (max ~8 MiB per transaction).

Four properties that define how it works

Content-addressed. When a Product writes data to Levity, the chain returns a Content Identifier - a Blake2b-256 hash of the bytes. That CID is intrinsic to the content itself. Anyone fetching by that CID can verify they received exactly what was published without trusting the delivery layer. Change a single byte and the hash changes. The client checks the CID against what it received. If they do not match, it knows the content has been tampered with. The address is bound to the content, not to where it lives.

Permissionless reads. Anyone with a CID can fetch the corresponding data from the network. No URL signing. No read authentication. No CDN to configure or pay for. Privacy for sensitive content is the Product's responsibility - encrypt before storing if the payload should not be public. But the retrieval mechanism itself is open by design.

Explicit authorization for writes. Levity has no token balance for storage. Every account that wants to write must first be granted an authorization. That's a quota defining how many transactions and how many bytes the account can store, with an expiration window.

Three origins can grant that quota. Root, which is sudo on the chain. Other parts of the Polkadot system, which can authorize accounts programmatically over XCM, allowing the broader ecosystem to decide how storage access is granted. Registered authorizers are entities that Polkadot's on-chain governance has approved to issue authorizations.

This is deliberate. It keeps the chain from becoming an unmanaged repository and gives the network control over what constitutes legitimate storage.

Time-bound retention with renewal. Data does not live on Levity indefinitely by default. The retention window is approximately fourteen days. Before that window closes, data can be renewed to extend its lifetime. Without renewal, it falls off the network automatically.

The time-bound model exists because storage capacity is finite. The network cannot hold everything indefinitely, and authorizations are designed to give each participant a fair share of that capacity. Renewal is how you signal that content is still worth keeping. Without it, space is reclaimed for someone else to use.

How Levity stores content

Levity's collators hold everything: the on-chain records such as CIDs, authorizations, and expiry times, and the actual content bytes. There is no separation between the chain and the content network. The same nodes that produce and finalize blocks also serve content to readers over IPFS Bitswap.

What makes this work at real content sizes is chunking. Large files are split into chunks, structured as DAG-PB manifests for IPFS compatibility, and stored chunk by chunk. The manifest CID is what gets recorded on-chain. Readers reassemble the original content from the chunks.

Why this matters

The current web is built on a model where storage is a service someone else provides and can withdraw. Centralized storage creates centralized control over what is available, who can access it, and at what cost.

Levity provides a working primitive: a storage layer that is open, verifiable, and not dependent on a single provider's continued goodwill or availability. Anyone with the CID can fetch content and verify what they received. The rules are enforced by the protocol, not by a company's terms of service. Storage is time-bound, capacity is limited, and authorization is explicit by design.

It is a beginning. And for the applications being built on Polkadot today, it is the foundation they need.

At Web3 Summit 2026, 190 people deployed applications whose frontends lived entirely on Levity. They did not configure hosting. They did not provision storage. They published, received a CID, and made the content available for anyone to fetch. Most of them never knew Levity existed. That invisibility was the point.

Where Levity is heading

Levity is an experimental reference implementation with deliberate constraints. It is designed for a limited number of users with verified personhood, and the storage it provides is intentionally small in scope. That is the point. A bounded, authorized, verifiable primitive for the applications that need exactly that.

The broader storage vision goes further. Capacity is the next layer: a scalable storage service for applications that need more, built on a subscription model. Storage at scale requires payment because unlimited free storage is not a sustainable foundation for anyone.

Levity and Capacity are not the same thing. They serve different needs, and both are part of the direction.

The vision is a human-centric storage and delivery layer that's free at the point of use for the applications and people who need it, rate-limited to keep the network sustainable rather than paywalled to keep it profitable. Not storage-as-a-service you subscribe to. Levity provides storage infrastructure beneath the products built on top of it, much like DNS exists beneath the web.

The fuller picture combines two complementary layers. Levity stores on-chain records: authorizations, CIDs, and expiry windows. For larger payloads like attachments, HOP - the Handoff Protocol - currently handles temporary delivery across the network. How larger content storage evolves from here, including the potential role of Capacity, is still being developed.

Levity and HOP together provide the storage and delivery primitives that Web3 applications need today. Levity is designed for decentralization by architecture. HOP is a practical delivery layer for attachments that is still maturing. The two are separate pieces solving different problems, at different stages of development.

Traditional cloud storage is reliable, but prone to censorship. A provider can withdraw access, comply with a takedown request, or simply decide that certain content violates their terms. For most applications, that is an acceptable trade-off. For applications that require censorship resistance by design, it is a disqualifier.

Levity uses IPFS Bitswap for content retrieval, building on that protocol rather than replacing it. What it adds is the on-chain layer: authorized writes, verifiable records, and retention enforced by the protocol rather than by a pinning service someone else operates.

Most applications that call themselves Web3 use a blockchain for a narrow slice of their stack and centralized services for everything else. The logic might be on-chain. The files are still on S3. The frontend is still on Vercel. Users do not experience that as a contradiction. They just experience a website. But the properties that make Web3 meaningful are censorship resistance, verifiability, and permissionlessness. Those properties only hold if the full stack upholds them. A censorship-resistant application hosted on infrastructure that can be taken down is not censorship-resistant. Levity exists for the applications where those properties are not optional.

Levity, Capacity and HOP are being built to close that gap. Content that is addressable by hash, retrievable peer-to-peer, with authorization and retention enforced by the protocol rather than by a company's terms of service. Not storage as a service. Storage as infrastructure.

The code is open source, and the work is ongoing. Start here:

• Dashboard: paritytech.github.io/polkadot-bulletin-chain 
• Documentation: docs.polkadot.com/chain-interactions/store-data/bulletin-chain 
• Repository: github.com/paritytech/polkadot-bulletin-chain