security · what we can and cannot see

Encrypt first, and there is nothing here to read.

Encryption (AES-256-GCM) happens client-side in the SDK. On the S3-gateway path you bring your own encryption: the gateway is a passthrough that stores your bytes exactly as sent and never holds your keys, so when you encrypt first there is nothing there to read. The coordinator is never on the byte path either way. The provider node is fully open source; the SDK ships with its test suite on npm.

Every stored object is challenged with chunk-level merkle proofs on a continuous cycle, targeting roughly every 4 hours. Proofs do fail, and the pass rate varies by node, which is why replication is 3x and providers are paid per passed proof. Retrievability is re-checked continuously, and providers only earn on proofs they pass. Proof records are issued by our coordinator today; provider-signed, customer-verifiable proofs are in development.

If you encrypt before upload and Obsideo is compelled to surrender your data, there is nothing to surrender. The keys were never on the platform. Upload plaintext and there is.

If you encrypt before upload and a provider's hardware is seized, they hold ciphertext that cannot be decrypted with keys they never had.

If the coordinator goes down, your recovery bundle (pre-fetched download authorizations plus a cached provider directory) lets the SDK evacuate your ciphertext straight from providers, for as long as those authorizations remain valid. Durable coordinator-independent recovery is in active development.

Who holds what

Trust is split on purpose. This table is the whole model.

What	Who holds it	If it is lost
Your encryption keys	You. The SDK generates them on your machine; on the S3 path you bring your own.	Your data is unreadable. There is no recovery path, because Obsideo never had them.
Your ciphertext	Three storage providers, placed across separate failure domains where the fleet allows.	One replica gone: re-replicated from the others. All three gone: the data is gone, and nobody was paid for it.
Object metadata: names, sizes, merkle roots, which providers hold what	The coordinator.	Restored from coordinator backups. Your ciphertext on the providers is untouched either way.
Proof records	The coordinator issues them today; provider-signed, customer-verifiable proofs are in development.	Re-established on the next challenge cycle, roughly every 4 hours.
Your recovery bundle	You, fetched through the SDK.	Fetch it again while the coordinator is up. Without it and without the coordinator, you cannot evacuate.

What the network protects against

A provider claiming to hold data it does not: chunk-level merkle challenges, continuously.
A provider quietly dropping data: missed proofs stop its pay and trigger re-replication.
Anyone at Obsideo reading your data: the coordinator is never on the byte path and holds no keys; the gateway stores bytes exactly as sent.
A single machine or facility failing: three replicas, placement prefers separate failure domains.

What it does not do

Stopping a provider from deleting: providers run their own hardware. The protocol makes deletion unpaid and heals around it; it cannot prevent it.
Operator and facility independence between every replica. Placement prefers it; the fleet does not always allow it. The live fleet is on /network/.
Proofs you can verify yourself without trusting the coordinator. In development.
Durable recovery with the coordinator gone for good. In development.
Key or password recovery. None.
Confidentiality if you upload plaintext. The network stores what you send.

This page is the security section that lived on the homepage until 2026-09-26, moved here unchanged. Reviewed 2026-09-26. The live fleet and its verification numbers are on /network/; the terms that govern these statements are on /terms/. Questions: regan@obsideo.io.