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 now has an update and some questions are beginning to be answered in my post: Understanding Jackal’s Filetree: What Validators Actually Store
Bringing a chain back from maintenance mode is not just a matter of getting the software to compile and the validators to sign blocks. Before investing the effort, we want to know whether there is a credible path to a chain that can sustain itself. At Orbital Alchemists, that question has narrowed to one module: filetree.
The issue as we see it. Jackal separates file data from file organisation. The file bytes live with storage providers, while the filetree module keeps the records that make those files usable: folders, hashed merkle paths, and the encrypted keys that let owners, viewers and editors open each file. From our reading of the module documentation, these records are written as ordinary transactions. That makes them consensus state, and every validator stores them. The file data is replicated across a handful of providers. The metadata describing it may be replicated across every validator on the network.
Our concern. Each file or folder appears to get its own on-chain entry, and sharing adds more encrypted key entries on top. Each entry is small, but entries accumulate, and on a chain, state is effectively permanent. A Cosmos chain keeps this state on disk rather than in memory, but the burden is still real. Every validator needs the storage, syncing and snapshots get heavier, and writes slow as the state tree grows. Take an illustrative case: a small fraction of the world’s population each storing a thousand files. The metadata alone could reach tens of terabytes, and every validator would carry all of it. We haven’t measured this, and the figures are only a thought experiment. But if the design scales linearly with files and users, it works against the decentralisation the chain is meant to provide. Validators would need ever larger machines, and fewer people could afford to run one.
What we are exploring. One possible direction is to keep only a small root pointer per user on-chain and move the full folder tree into an encrypted manifest stored in the storage layer. The chain would then hold roughly one entry per user instead of one per file. We don’t yet know whether Jackal’s architecture allows this, or whether the per-file design is too deeply embedded in the chain to change. So we are reading the code rather than guessing. We are examining the actual Files structure and how the keeper reads and writes it. We are also checking whether any size limits or fee mechanisms already discourage state growth, and whether a chain upgrade could migrate the existing design to a lighter one.
Why this decides the effort. If there is a path to a leaner filetree, whether by module changes, a migration, or a manifest-based layer, then resurrecting the chain is worth serious investment. If the per-file model is a hard blocker with no workable upgrade route, the right decision is to know that early, before committing months of work. We have already run a local testnet and successfully uploaded and retrieved files. The next step is to understand the architecture well enough to give an honest answer to the question: is there a pathway to a better, sustainable chain?
I wrote this as an open investigation, with no conclusions claimed, because we haven’t yet read sufficient code (in enough depth) and we haven’t done the experiments we want. Once we’ve gone through the Files definition and the keeper logic, we can replace the “we are exploring” section with what we found.