ring0 is currently in active development. Follow our progress. Read the docs

Ring0Ring0

Section VIII

CHITA

Retrievable Archival Storage

S3-compatible

A chain that forgets cannot prove what it settled. Most storage layers spot-check a few random bytes and call it proof, so a provider can keep only the fraction those checks happen to visit, pass every one, and let the rest of the file quietly die. CHITA proves the whole file is still there, not a lucky sample of it.

Formally

CHITA is an incentivized archival layer whose possession audits are proofs of retrievability: custody is erasure-coded and committed in the chain’s own state, so any provider that can answer random challenges at all is provably holding enough to return the entire file.

what you get

What You Get

A chain that forgets cannot prove what it settled. History is not a nice-to-have here. It is the thing being sold.

What you get is durability you can check, rather than durability you are promised. The data your application writes today is still provably there in ten years, and nobody's word enters into it — not ours, not an operator's, not a foundation's. When a machine dies, the network rebuilds its share without anyone filing a ticket.

  • History that stays whole, not merely spot-checked
  • A lost node repairs itself from the others, with no manual recovery
  • Providers are paid for custody they can prove, and slashed when they cannot
  • Anyone can check custody from the chain, with no privileged access

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 then picks sixteen bonded providers at random and gives them one chunk each. The writer does not choose who stores their data, which is what stops a writer from quietly handing all sixteen chunks to itself.

Then the chain keeps asking. Random spot checks, continuously, for as long as the file is meant to exist.

The redundancy is what makes those checks mean anything. Because every chunk carries its own, a provider that can answer the checks at all is holding enough to hand the whole thing back.

  • 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
FILECODED CHUNKS
16chunks per file

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.

01

Models & Datasets

Weights and training data with provenance anyone can check, not a hash in a README.

02

Agent Memory

The logs an agent acted on, still standing when someone disputes the call months later.

03

Rollup & App Data

Blobs that have to outlive the block that carried them, retrievable long after the fees were paid.

04

Media & Assets

Images, video, and app files served from the same bucket your code already writes to.

05

Compliance Records

Where “we still have it” has to be provable on demand, not asserted in an email.

why it is different

Why This Is Different

Almost every storage proof in production checks a random sample of bytes. A provider that keeps only the fraction those checks happen to visit will pass every single one of them, indefinitely, while the rest of the file rots. The audit is honest and the conclusion is wrong.

CHITA is built so that passing the check proves the file is recoverable, not that a sample of it once existed. And it is built so that a coalition deciding to withhold forfeits more in bonds than the withholding could ever earn.

The whole layer rests on one assumption: that the hash function is collision resistant. No pairings, no discrete logarithms, no setup ceremony. Post-quantum is answered by choosing a wider hash, not by redesigning the protocol.

  • Passing the audit proves the file is recoverable, not merely sampled
  • Withholding is bonded and slashed, so capture costs more than it earns
  • One assumption only, a collision-resistant hash
  • No pairings, no discrete logarithms, no trusted setup, no ceremony
  • Post-quantum by construction: answered by choosing the width, not by redesigning