The most expensive thing a chain can do is remember. Every byte in the state trie is replicated by every node forever, and priced accordingly. EmpoorioChain's answer for large data — media, AI model shards, rollup batches, encrypted backups — is to commit to it on chain and store it elsewhere, provably. This post covers the mechanism.
Two pallets
pallet-blob-storage accepts a blob and records a commitment (a hash and size) in state. The bytes themselves do not enter the trie; they are handed to the storage market.
pallet-storage-oracle verifies availability: that the committed bytes can actually be retrieved from the storage providers who are paid to hold them. A commitment without availability is worthless, so the two are designed together — this is the native equivalent of EIP-4844 blob data availability, without depending on an external DA network.
What it costs
Measured on the testnet: blobStorage.submit_blob for 1 MB is 0.000095 DMS — a fraction of a cent. The commitment is small and fixed; the storage itself is billed through the storage market.
That market moved, in runtime 213, from billing in whole gigabytes to billing in bytes. Prices are still quoted per GB, but a 3 KB file is charged for 3 KB — rounded up, so that nothing is ever free and a spammer cannot store a million tiny files for nothing. Before 213 a small file was rounded to the nearest gigabyte, which was either free or absurd depending on the direction.
Who stores it
Storage providers register through the cloud pallets (compute market, node uptime, blob and storage coordination). Ouranoos, the ecosystem's encrypted-cloud app, is the first consumer: a user's encrypted files are committed through blob storage and held by providers who are paid in DMS and verified by the oracle. The independent-provider network behind it is still being built; the app is in closed alpha on Google Play and says so.
Data availability for rollups
The same primitive is what lets EmpoorioChain act as a settlement and DA layer for application-specific rollups. A rollup posts its batch as a blob; the L1 holds the commitment and verifies availability; light clients can sample fragments and attest without downloading everything. The design intent in the architecture docs is erasure coding with KZG commitments; what is live today is the commitment-plus-oracle flow.
The pattern, generalised
Every large object in the ecosystem follows the same shape:
| Object | On chain | Off chain |
|---|---|---|
| NFT media | Ownership, royalty rule, CID | The file, via blob storage |
| AI model shard | Registry entry, hash | The weights, via blob storage |
| Ouranoos file | Commitment | Encrypted bytes at providers |
| Rollup batch | Commitment, availability proof | The batch data |
State stays bounded — a rule the whole runtime adopted in 215 — and the trie holds what consensus needs, not what users upload.
Compared with compression
Some chains reduce NFT cost by compressing many tokens into one on-chain Merkle root and keeping the leaves off chain in an indexer. EmpoorioChain gets a similar cost profile from the opposite direction: tokens stay native and individually addressable (batch and lazy minting keep them cheap), and it is the media that lives off chain with an availability guarantee. The ownership record is never in an indexer's database; it is in the state.
Based on ARCHITECTURE.md, 02_CORE_SYSTEMS/EVM_AND_L2.md, FEE_MODEL_AND_LOW_COST_STRATEGY.md and the runtime 213 storage-market change.