Section VIII
CHITA
Decentralized File Storage
Your files. Across a network. Not in one company’s hands.
Think S3-like storage, without one company holding everything. CHITA spreads your files across providers and checks whether the stored pieces can rebuild them—not just whether a few bytes are still there.
S3-like describes object storage: files identified and retrieved by applications. It does not specify compatibility with every S3 API.
what you get
What You Get
CHITA is ring0’s decentralized object-storage network for model weights, records, media, and agent logs. Applications store files; storage providers hold coded pieces; ring0 records the roots, assignments, and custody commitments.
Lose a storage machine, not the only copy of your file. Extra pieces allow recovery when enough valid pieces remain. Regular checks make providers accountable for their custody commitments; storage providers do not finalize blocks.
- Files spread across multiple providers
- Missing pieces can be rebuilt from the remaining pieces
- Providers earn storage fees and risk penalties for failed checks
- Storage records and checks anchored in ring0
how it works
How It Works
A file is cut into pieces, and each piece is coded into sixteen chunks, any ten of which rebuild it. The chain assigns those chunks to bonded providers. The writer does not choose the destinations. Eligibility and concentration rules matter too: random assignment alone does not prove the providers have independent owners.
Providers are checked regularly and paid for the storage they serve. Missing pieces can be rebuilt from enough surviving pieces.
Each piece also contains extra recovery data. With correctly prepared files, answering enough challenges shows that the entire piece can be reconstructed from the provider’s responses.
- 16 chunks per piece, any 10 rebuild it
- The chain picks who stores what, not the writer
- A lost chunk is rebuilt from the others, without re-uploading the file
- The redundancy costs twice the raw size
One file becomes sixteen
The file is cut and coded so the pieces carry more than the file itself. Ten of them bring it back.
use cases
What People Store Here
Anything whose value depends on still being there, and on being able to prove it.
Legal records, audit trails, model weights, medical archives, the artifacts an application must still produce years after the team that built it moved on. The shape is always the same: the file matters, but the ability to demonstrate the file was never quietly lost matters more.
Models & Datasets
Keep model weights and datasets recoverable, with storage roots your application can reference.
Agent Memory
Store the logs and artifacts needed to review an agent’s actions.
Rollup & App Data
Keep application artifacts beyond their original block, under an explicit custody term.
Media & Assets
Store images, video, and application files across storage providers.
Compliance Records
Retain legal and audit records with checkable storage evidence.
why it is different
Why This Is Different
Keeping a few bytes is not the same as keeping a usable file. CHITA combines storage checks with extra recovery data to make that distinction testable.
Retrievable-storage admission checks every inner codeword, the outer encoding, and the roots of the stored pieces before accepting a catalog entry. This binds the recovery claim to correctly encoded data, rather than letting a writer register a hash of unusable bytes. It does not promise permanent storage or immediate downloads.
CHITA handles storage, not secrecy. Files that need to stay confidential need a separate encryption layer.
- Recovery checks, not just spot checks
- Provider deposits put a cost on breaking storage commitments
- Recovery depends on enough pieces remaining available
- No built-in confidentiality or download-speed guarantee