RESEARCH
The research behind the design.
Provable data integrity means you never have to take our word for it: every guarantee is stated as a property and then derived, so your reviewer can follow it, argue with it, and sign off on something other than a vendor deck. This page is where those documents are published, and where the ones covering what we build next will be published too. The technical documentation is already live, and covers the same design in another form.
DataPrism paper
The design of the system end to end, and the formal guarantees behind the three properties.
WHAT IT DEMONSTRATES
That the properties are consequences of the design, not settings. You can follow each derivation down to the assumption it rests on, and if one of them does not hold in your environment, you will see exactly where the argument stops holding.
WHO IT IS FOR
For the architect or security reviewer who has to sign off on a storage design and answer for that signature later. For the story rather than the derivation, read how the design becomes a product.
Publishing soon
Reliability paper
The reliability models behind dispersal: how redundancy across independent providers translates into survivable failures and refusals, up to the redundancy threshold you choose. The durability math, laid out to be checked, not taken on trust.
WHAT IT DEMONSTRATES
That survival under failure is computed, not hoped for: put your own provider count and your own threshold into the models and you get the combinations of outages and refusals the dispersal absorbs, and the one where it stops.
WHO IT IS FOR
For the engineer who has to answer what happens when a provider fails, with a model instead of an adjective.
Publishing soon
Security Architecture Overview
The threat model in full: what each actor can see, what each guarantee rests on, and the cryptographic choices behind them.
WHAT IT DEMONSTRATES
Who can read what, under which conditions: provider, operator, authority, attacker, each walked through against the architecture. Most of what a security questionnaire asks is answerable straight from this document.
WHO IT IS FOR
For the CISO or security engineer running due diligence before a pilot, who would rather read than book a call.
Publishing soon
WHAT THE PAPERS COVER
What provable data integrity means, formally.
FORMAL GUARANTEES
The properties stated and derived, so you can test each one against your own threat model.
RELIABILITY MODELS
What survives when providers fail or refuse, and where the limit sits, so you set your redundancy threshold on evidence.
ARCHITECTURE
The complete architecture, from client to registry, with the trust assumption of each step written down.
STATED GUARANTEES
Four sentences we expect to be quoted back.
We make these claims across this site. The first three are stated properties with a derivation behind them in the papers. The fourth is what follows from them in practice. Quote them in your security review, and hold us to them.
-
CONFIDENTIALITY
Encryption happens before upload. Nobody can read your data, including us.
-
AVAILABILITY
Files are dispersed with redundancy across independent providers. No single provider outage can take your data down.
-
INTEGRITY
Every fragment is content-addressed. Tampering is detectable end to end.
-
COMPULSION
An operator served with a request can produce only incomplete fragments of ciphertext. The key is derived on your side and stored nowhere, including here.
WHY WE PUBLISH
We would rather be checked than believed.
Infrastructure that asks for your most sensitive data should not be evaluated on adjectives, and you should not have to sign off on faith. Publishing the design, with its guarantees stated and derived, turns our security story into something your reviewer can attack: read the claims, follow the derivations, look for the gap. Your due diligence gets a document instead of a meeting, and if you find a gap, we want to hear about it before anyone else does.
The papers are one layer of a checkable stack: the threat model in plain terms has its own overview above, and the client-side encryption SDK is documented in the open. Each document above links to its PDF as soon as that document is published.
This page is a venue, not a snapshot of one release. The documents above cover the system as it stands today. As the design gains capabilities, the papers that state and derive the guarantees those capabilities carry are published here the same way, under the same rule: a claim first, then the derivation behind it.
Built on research we publish.
The docs show how the design becomes an SDK your engineers can read line by line.