Quick Notes

This article is about the Blockchain “Jackal” - A decentralised file storage chain. It is somewhat technical in nature and intended for developers and infrastructure providers.

Many articles that Orbital Alchemists write are for non technical audiences : A Journey into the Roots of Decentralisation

This article is an update to my recent post: Can Jackal Be Resurrected Sustainably? The Filetree Question

When people hear that Jackal is a “blockchain for file storage,” it’s natural to assume the chain itself is holding files — photos, documents, videos — the way a hard drive would. It isn’t. The actual bytes of your file never touch the blockchain. Instead, file contents live off-chain, distributed across Jackal’s storage providers, while the blockchain holds something much smaller but arguably more important: a verifiable record of what exists, who owns it, and who’s allowed to see it.

This record is the job of the Filetree module. Every account that wants to organize files starts by “provisioning” a root folder — a single entry that becomes the top of their personal file tree. From there, every file or folder they add is stored as its own distinct entry in the chain’s consensus state, linked back to that root by a cryptographic path. Critically, what gets written on-chain for each file isn’t the file itself but a small bundle of metadata: a hashed path identifying its position in the tree, a pointer to where the actual content lives (the file ID from Jackal’s Storage module), an owner reference, a tracking number, and — often the bulkiest part — two maps listing exactly who has viewing or editing permission, with each permitted party’s entry containing an encrypted copy of the key needed to decrypt that file.

That last detail matters more than it first appears. Based on a real test entry we measured directly on a local testnet, a single file record with just one viewer and one editor weighs in at around 836 bytes — not because the file is large, but because of the encrypted key material stored per person with access. Share a file with ten people instead of one, and that entry grows accordingly, since each grantee needs their own encrypted key sitting in state. A bare, empty root folder, by contrast, is leaner — roughly 330 bytes — since it holds no content pointer or real access-control maps yet.

Multiply this by a global user base and the arithmetic becomes the crux of the sustainability question we’ve been circling. A million users with a thousand files each, even using this conservative one-viewer baseline, works out to somewhere in the region of 800 gigabytes of raw filetree state alone — before accounting for the actual database overhead the chain uses to index and verify that data, and before accounting for any meaningful file-sharing, which only pushes the number higher. Every validator on the network has to hold this growing dataset in order to independently verify the chain, forever, since Cosmos SDK chains don’t have a built-in mechanism for module state to expire or be pruned away once it’s written. It’s this permanence — not the per-entry size itself — that turns an individually modest piece of metadata into a long-term structural question for a chain aiming at mass adoption.