Your architecture stays as it is
Your providers stay: no infrastructure project to fund.
Product
Storage your own cloud cannot read, lose, or silently alter.
DataPrism sits on top of the cloud you already run: one pipeline applies the property to that storage, so what you can prove about your data changes while your architecture stays exactly as it is.
Encrypted before upload. Dispersed with redundancy. Proven in public.
The property starts with client-side encryption: keys are derived on your side, and what leaves is already unreadable. Each stage below turns one assurance from a provider's promise into a behaviour of the data itself, which is what makes it demonstrable to a customer, an auditor or a regulator. Where encryption before upload is already in place, start with the three exposures it leaves standing.
-
File
-
Encrypted
-
Fragmented
-
Dispersed
-
Anchored
File
Encrypted
Fragmented
Dispersed
Anchored
What it is
A sovereign overlay, not another silo.
You keep your object storage providers. DataPrism composes them into something none of them can offer alone: storage where a provider still holds your bytes but can no longer read them, and no longer decides whether you keep them. Replacing your providers would also mean replacing your contracts, your regions, and your compliance posture. The overlay leaves all three where they are, which turns an infrastructure decision into a decision your security and compliance teams can take on their own.
Already encrypting?
Your provider cannot read it. That is one problem of three.
Encrypt before upload with a key you hold, and your provider is blind to your data. That is real, and it is where our own pipeline starts. Three things stay exactly as they were: it still holds all of it, it can still stop you reaching it, and you still have nothing an auditor can check without you.
What it still holds
One estate, one address
Your ciphertext sits complete inside one provider's estate. Whatever reaches that estate reaches all of it, in one operation, and a copy taken today can be kept until it is worth reading. Files are split, encrypted, and dispersed with redundancy across the independent providers you configure: the same operation now has to succeed as many times as you set. That number is something you choose, and something you can state when someone asks what a single compromise reaches.
What it cannot keep up
Confidentiality is not availability
A key you hold does nothing about an outage, a suspended account, or a change of terms. Your data goes wherever that one provider goes. Dispersed with redundancy, the loss of one is absorbed by the threshold you configured, not by your recovery plan.
What it cannot show
Nothing a third party can check
Key custody is a statement about your own configuration, and the evidence for it is your word plus your provider's. A constant-size fingerprint on a public registry is checkable by the person asking, at the time they ask, with nothing required from you.
None of this is an argument against encrypting first. It is the list of what encrypting first leaves open.
How it feels to integrate
One SDK to integrate. Your product behaves exactly as it does today.
You add a TypeScript SDK to the code that already handles uploads. Its upload and download calls take over from the ones you have today, the types come with them, and the rest of your product carries on: the same screens, the same support playbook, the same release you were going to ship anyway.
- 01
Install
Add the TypeScript SDK where your upload handler already lives. It runs in your own process, in the browser or on your server.
- 02
Point
Point it at the storage you already run: the same accounts, the same regions, the same contracts.
- 03
Ship
Ship it in an ordinary release. What changes is what your providers can hand over, and your product keeps the behavior it has.
The developer page shows the code: the client-side encryption SDK.
Why it holds
Enforced by consensus, not by an operator.
Any guarantee an operator enforces, an operator can quietly break. So integrity here does not depend on anyone's good behavior, including ours: the anchored root index never grows with your data, and every fragment is content-addressed, so any alteration is detectable end to end. When a customer or an auditor asks how you know nothing was altered, you show a proof anyone can check, not a report only your provider can produce, and answering them does not mean opening a ticket with anyone.
The guarantees are formal: see provable data integrity, specified in our research. What each actor can see is laid out in Trust and security.
What you get
What lands in your stack.
A single compromise is not enough
Encrypted fragments across the providers you configure: reaching one estate is no longer reaching your data.
You survive losing a provider
Provider outages and refusals stop being events you plan around.
One check, at any volume
One fingerprint, whatever the volume behind it: the same single check at any scale.
You would know if it changed
Every fragment content-addressed: alteration surfaces instead of passing unnoticed.
Encryption your team does not write
A TypeScript SDK: no cryptographic plumbing to build or defend in review.
FAQ
Asked before every demo.
- Do we have to migrate our data?
- Your providers, regions and contracts stay exactly as they are, and there is no platform to move to. What passes through the pipeline is the data itself, and there are two ways to start: apply it to everything written from now on, which leaves what already sits there untouched, or bring an existing perimeter through once, which rewrites those files as fragments into the same accounts. Either way it is a change one team ships, not an infrastructure program to budget for. The set of destinations is yours to pick and to change: several accounts at one provider, several providers side by side, your own on-premise storage, or any mix of them. Anything that speaks the S3 API is a destination today, and adding one later is a configuration change, not a second integration. The overlay is described in What it is, above.
- We already encrypt client side. Does DataPrism replace that?
- No, and it does not ask you to unwind it. The SDK encrypts on your side too, so an object you hand it already encrypted travels the pipeline as your ciphertext. What changes is everything after encryption: how many places the fragments land in, and what a third party can check. The section above sets out what encryption alone leaves open.
- What actually lands on the public ledger?
- A sealed index, and nothing else: the map that puts your fragments back together, encrypted with a key we never receive. No content and nothing readable ever lands there, so anyone can check your integrity claim without you publishing anything about your data. What each actor can see, and what none of them can, is laid out in the security architecture overview.
- What happens to our data if DataPrism stops?
- Your files stay in your own accounts, and the key stays derived on your side, so recovery holds without us. Reconstruction runs client side from the fragments your providers hold and from the index on the public registry, and the SDK reads that index through an interface any public node can serve. The recovery path is a property of the design rather than a commitment we make, which is what the security architecture overview sets out.
- Which storage can it compose?
- Whatever object storage you operate, wherever it runs: AWS, GCP, Azure, or on-prem. The pipeline is the same across all of them, and no part of your integration changes when the mix of providers does.