Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Storage Custody

Status: Proposed. This decision becomes accepted when the implementation PR is merged.

Decision

DataPrism does not own or operate the production buckets used for customer file shards. Each customer connects storage they control, and encrypted Reed-Solomon shards are dispersed across those independent providers.

Cloud credentials stay in the customer's infrastructure. The SDK and dashboard store only non-secret location metadata and a customer-controlled signing endpoint. For each object operation, that endpoint authenticates the caller and returns a short-lived URL scoped to one HTTP method and one content-addressed object key.

DataPrism-managed storage is not the default or canonical enterprise architecture. A managed offering may be introduced later as an explicit opt-in product with separate custody, billing, retention, and availability terms. It must not replace customer-owned storage silently.

Trust boundary

  • The customer owns the buckets, cloud accounts, IAM policies, signing service, and storage bill.
  • DataPrism supplies client-side encryption, erasure coding, routing metadata, and the provider interface.
  • DataPrism never receives permanent cloud credentials or stores them in the browser or on-chain.
  • Storage providers receive encrypted shards and content-addressed object keys, not plaintext files or reconstruction metadata.
  • A signing endpoint must reject arbitrary paths, bind the requested HTTP method and content length, constrain access to the configured bucket or prefix, and use a short expiry.

Provider slot

The sealed dataprism.providers slot contains records such as:

{
  "aws_s3": {
    "service": "signed_url",
    "signerUrl": "https://storage.example.com/aws/sign",
    "region": "eu-west-1",
    "bucket": "company-primary"
  }
}

Authentication for the signing endpoint is supplied to the SDK at runtime. Tokens, cookies, cloud access keys, and signing secrets are never written into the provider slot.

Existing projects

Legacy provider slots containing permanent cloud credentials are rejected by the SDK and must be replaced with signing-endpoint configurations. Because blockchain history is immutable, removing a credential-bearing slot cannot erase its earlier ciphertext. Customers must rotate any cloud credentials that were previously written and then update the project with a safe provider configuration.

Operational requirement

Production readiness requires an end-to-end test using at least two customer-owned providers: upload, HEAD/deduplication, download, delete, expired authorization, cross-project rejection, one-provider failure, and successful reconstruction from the remaining quorum.

Copyright © 2026 DataPrism.