Encrypt on your machine
Your client encrypts the object before a single byte is transmitted. Providers receive ciphertext and nothing else.
Client-side · symmetric encryption
Distributed object storage
Storage that outlives
its provider.
Tessera encrypts your data on your machine, splits it into 15 shards, and distributes them across 15 independent storage providers. Any 10 rebuild the file. Your bytes never pass through our servers.
Upload · Download · Store · One HTTP API
- shards per slab
- 15
- shards rebuild the file
- 10
- storage overhead
- 1.5×
- providers can vanish
- 5
- survivability window
- 60d
The premise
Every storage provider is a single point of failure. So we stopped using one.
Conventional object storage replicates your data inside one company's infrastructure. If that company suffers a catastrophic failure, deletes your account, or simply ceases to exist, every replica shares the same fate — because every replica shares the same owner. Tessera removes the shared owner.
What Tessera never receives
- Your plaintext data — encryption happens on your machine, before anything is transmitted.
- Your files as files — shards travel directly from your client to storage providers. The API never proxies object bytes.
- Filenames, directory structure, or content types — the object model has no such fields. Names live in a metadata blob we cannot interpret.
- Any single reconstructable copy — no provider, and no Tessera server, ever holds one.
What Tessera does hold
- Placement metadata: which providers hold which shards, and the Merkle root of each.
- Erasure-coding parameters and slab key material required to serve reads and drive repair.
- Account identity — the public half of your credential — plus request and usage counters.
- Storage contracts with providers, which we fund, renew, and settle on your behalf.
This is the whole design. We operate the parts that need coordinating — provider selection, contracts, placement records, repair — and stay out of the parts that need trusting. Read the full trust model →
How it works
Four steps, and one of them is not ours.
You call one API. Underneath, an object becomes fifteen encrypted fragments held by fifteen unrelated businesses, and stays that way for as long as you keep paying — with the arithmetic to survive a third of them disappearing.
Split into 15 shards
Reed–Solomon erasure coding produces 10 data shards and 5 parity shards. Any 10 of them reconstruct the original.
10+5 · 1.5× storage overhead
Distribute to 15 providers
Each shard goes to a different provider, selected from a continuously vetted pool. No provider ever holds more than one shard of a slab, so none of them holds anything reconstructable.
One shard per provider, enforced
Repair before it matters
We scan shard health continuously. When a provider disappears, its shards are rebuilt from parity onto fresh providers — without you asking, and without a read.
Continuous · automatic
Your machine
encrypt(data)
reed_solomon.split(10 + 5)
write shard → provider
Encryption and erasure coding happen here. Nothing leaves in a readable form.
Direct transfer
Shards move straight from your client to each provider over an authenticated session. Tessera is not in the data path.
15 independent providers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
One shard each. No provider ever receives a second shard of the same slab.
Tessera control plane — alongside, not in between
provider curationcontract funding & renewalplacement manifestauthorisationshard health scanningrepair orchestrationmetering
The network underneath
Tessera is built on the Sia network — an open market of independent storage providers who post collateral against contractual storage commitments. We handle provider vetting, contracting, funding, and settlement. You never interact with the network, price it, or hold anything belonging to it. It is an implementation detail we are simply not in the habit of hiding.
Durability
Any 10 of 15.
Erasure coding replaces the copy-everything model with arithmetic. Drag the slider: take providers offline and watch what it costs you. Up to 5, the answer is nothing.
Reed–Solomon 10+5
Fully recoverable
D1
D2
D3
D4
D5
D6
D7
D8
D9
D10
P1
P2
P3
P4
P5
12 shards remain — 10 is the minimum. Your file reconstructs with no loss and no user action.
Tolerance — any 5 of 15 providers may fail simultaneously with zero data loss. Solid tiles are data shards, outlined tiles are parity.
5 simultaneous failures cost you nothing
Losing an object requires 6 of 15 unaffiliated providers — different companies, different hardware, different jurisdictions — to fail inside a single repair window.
Failures are independent, not correlated
A single operator outage, a regional power event, or one company going bankrupt takes down a fraction of your shards, not a replica set that shares an owner.
Integrity is verified, not assumed
Every shard is addressed by its Merkle root. A provider that returns altered bytes is detected on read, rejected, and repaired — silent corruption cannot propagate.
What we will not claim
No storage system is unloseable, and we would rather say so than pretend otherwise. A 10-of-15 slab is destroyed if 6 providers are lost before repair completes. Our claim is narrower and testable: that outcome requires a simultaneous, uncorrelated failure of 6 independent businesses, which is the reason we distribute across owners rather than across racks.
Survivability
If Tessera disappeared tomorrow, your data would not.
Most providers ask you to assume they will still be here. We would rather remove the assumption. Our contracts are funded far ahead of need, and the information required to retrieve your data without us is yours to hold.
60days
Prepaid recovery window
Storage contracts are funded roughly 12 weeks ahead of need — we deliberately overpay. If Tessera went dark permanently and no one renewed anything, your shards would remain retrievable from providers for at least 60 days. That is not a support commitment; it is a consequence of money already spent.
0middlemen
Retrieval does not route through us
Reads already go client-to-provider. Given the placement record for an object — which providers, which shard roots, which parameters — a client fetches and rebuilds it directly. Our API is the convenient way to look that up, not the only way to use it.
1export
Keep your own placement copy
Every object's placement is readable through the API at any time. Export it, store it with your own backups, and your recovery path no longer depends on our continued existence. We recommend doing this on a schedule.
The honest framing: we are a convenience layer over a market, not the vault. Losing us should cost you an integration, not an archive.
Security & compliance
Certified where it counts, candid where it doesn't.
Our control plane inherits the certifications of the infrastructure it runs on. Everything else is self-assessed, and every item below says which is which — because a compliance page that blurs the difference is not worth reading.
SOC 2 Type II
Certified — inheritedScope · Underlying cloud infrastructure (AWS)
The Tessera control plane runs on AWS, whose infrastructure and host operating environment are covered by an annual SOC 2 Type II examination. Tessera has not yet completed a SOC 2 examination of its own service layer.
Evidence: AWS Artifact — report available to customers under NDA
ISO/IEC 27001:2022
Certified — inheritedScope · Underlying cloud infrastructure (AWS)
AWS maintains an ISO/IEC 27001-certified information security management system covering the regions and services Tessera consumes, alongside ISO/IEC 27017 (cloud security) and ISO/IEC 27018 (cloud PII). Certification of the Tessera entity itself is on the roadmap.
Evidence: AWS certificate + statement of applicability
GDPR (EU 2016/679)
Self-assessedScope · Tessera as data processor
Tessera acts as a processor for customer content and as a controller for account and billing records. Data protection agreement, records of processing, subprocessor disclosure, and data-subject request handling are in place and self-assessed. No third-party GDPR audit has been performed.
Evidence: DPA available on request · subprocessor list published
CSA CAIQ v4 / STAR Level 1
Self-assessedScope · Tessera service
Cloud Security Alliance Consensus Assessments Initiative Questionnaire completed as a self-assessment against the Cloud Controls Matrix v4. This is a Level 1 self-attestation, not a third-party (Level 2) certification.
Evidence: Completed CAIQ workbook — available on request
OWASP ASVS 4.0
Aligned — internalScope · API and web surface — Level 2 target
The Application Security Verification Standard is used as the internal engineering checklist for the API surface. We target Level 2. Verification is internal; there is no external ASVS attestation and no independent penetration test has been completed yet.
Evidence: Internal control mapping
NIST CSF 2.0
Self-assessedScope · Organisation-wide
Security programme structured against the six NIST Cybersecurity Framework 2.0 functions — Govern, Identify, Protect, Detect, Respond, Recover. Current-profile self-assessment maintained internally with a documented target profile.
Evidence: Current and target profile worksheets
For developers
One signed HTTP API. No SDK lock-in.
Provision a credential, ask for placement, write your shards, record the object. Requests are authenticated with an ed25519 signature you can produce in any language — there is no session, no cookie, and no proprietary client you are obliged to use.
quickstart.sh
# 1 — provision a credential
curl -X POST https://api.PLACEHOLDER_DOMAIN.example/auth/provision
# 2 — ask for placement: 15 providers, 10-of-15 geometry
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/prepare-write?$AUTH" \
-d '{"totalShards": 15, "minShards": 10}'
# 3 — encrypt, erasure-code, and write shards to the returned providers
# 4 — record placement
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/slabs?$AUTH" -d @slab.json
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/objects?$AUTH" -d @object.jsonSigned requests, no sessions
Every call carries an ed25519 signature over the method, host, path, expiry, and body. Nothing to store, nothing to refresh, nothing to steal from a cookie jar.
Erasure geometry is yours to set
Ten-of-fifteen is the default. You can widen it per slab, within a validated range, when a workload deserves more parity.
Revocation is immediate
Credentials can be revoked in one call. Access stops at the next request — there is no token lifetime to wait out.
Opaque metadata by design
Filenames and structure live in a blob only your keys can interpret. If you want a directory tree, you build it — we cannot read it either way.
Store something that has to survive you.
A credential takes one request. The first object takes about fifteen minutes.