Data Storage¶

The Polkadot Bulletin Chain is for storing raw data and files on-chain — images, HTML, JSON, documents, and more. You get back a CID (Content Identifier) and the data is directly retrievable. Think of it as decentralized file hosting built on a Polkadot SDK-based blockchain with IPFS-compatible content addressing. The data is only kept for a specific retention period and needs to be renewed to be kept for longer. There are no ownership semantics — it's just storage.

The Bulletin Chain is designed as a utility chain — it has no native token balances. Instead, access is managed through an authorization system that grants accounts or preimages the ability to store data. For more details, see the Polkadot Bulletin Chain repository (will be moving to the fellowship runtimes repository in the future).

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).

Authorization¶

The Bulletin Chain has no token balances — there are no fees to pay. Instead, storage access is controlled through an authorization system that prevents spam and ensures fair usage. Currently, only OpenGov can provide authorizations but the PoP (Proof of Personhood) subsystem is also planned to have this privilege in the future.

Authorization is not a token transfer — it's a permission entry recorded in the chain's storage that specifies:

• The account allowed to store data
• The number of transactions and bytes the account can use
• An optional expiration block after which the authorization becomes invalid

Authorization is consumed as you store data — each storage transaction decrements your remaining transaction count and byte allowance. Once your allocation is used up or the expiration block is reached, you need a new authorization.

Who Grants Authorization¶

The authorize_account and authorize_preimage extrinsics require Root origin, meaning only privileged accounts can grant authorization. How this works depends on the network:

Account Authorization¶

Account authorization grants a specific account the ability to store any data on-chain, up to the allocated transaction and byte limits. This is the most common authorization type for active users.

• Granted via the authorize_account extrinsic (Root origin)
• Can be refreshed with refresh_account_authorization
• Expired authorizations can be cleaned up with remove_expired_account_authorization

Preimage Authorization¶

Preimage authorization grants storage access to anyone who can provide the preimage of a specific hash. This is useful for sponsored uploads where a third party authorizes the storage of specific, known content without needing to know which account will submit it.

• Granted via the authorize_preimage extrinsic (Root origin)
• Can be refreshed with refresh_preimage_authorization
• Expired authorizations can be cleaned up with remove_expired_preimage_authorization

Capacity Planning¶

When requesting authorization, estimate how many transactions and bytes you need. For simple uploads, a single file under 8 MiB requires one transaction. For chunked uploads (files over 8 MiB), each 1 MiB chunk requires a separate transaction, plus one additional transaction for the manifest. For example, a 100 MiB file would require approximately 101 transactions.

Transaction Storage Pallet¶

The transactionStorage pallet is the core module for interacting with the Bulletin Chain. It provides the following extrinsics:

The pallet also exposes the following storage items:

The pallet emits the following events:

IPFS Integration and Data Retrieval¶

The Bulletin Chain follows a "write-to-chain, read-from-network" architecture. Data is stored via on-chain transactions and retrieved directly from collator nodes using the CID. The chain is designed to work seamlessly with the InterPlanetary File System (IPFS) — Bulletin Chain nodes are themselves IPFS participants.

How It Works¶

When you store data on the Bulletin Chain, the following happens:

1. CID generation: The chain computes an IPFS-compatible Content Identifier (CID) from your data using a cryptographic hash. This CID uniquely identifies the content regardless of where it is stored.
2. Bitswap serving: Bulletin Chain collator nodes implement the IPFS Bitswap wire protocol, which is the standard way IPFS nodes exchange data blocks. IPFS clients can request data directly from collator nodes using the CID.

Retrieval Methods¶

Data Lifecycle¶

The typical lifecycle of data on the Bulletin Chain follows these steps:

1. Authorization: Obtain authorization to store data through the faucet (Polkadot TestNet) or from a privileged account (MainNet).
2. Storage: Submit a store or store_with_cid_config transaction with your data payload.
3. Retrieval: Fetch data from collator nodes using the CID via the Console UI, Direct P2P (Helia), the Bulletin Chain IPFS gateway, or (coming soon) the Smoldot light client.
4. Renewal: Before the retention period expires, submit a renew transaction to extend the data's lifetime.

Size Limits¶

For files larger than the max transaction size, data must be split into chunks using the DAG-PB (UnixFS) standard. Each chunk is stored as a separate transaction. A final manifest transaction is uploaded last, containing the CIDs of all chunks. The manifest's CID becomes the root CID for the complete file. IPFS clients can then retrieve and reassemble the file automatically using the manifest.

Network Endpoints¶

Where to Go Next¶