Introduction

DataPrism is a privacy-first storage layer with client-side encryption, managed object storage, and an on-chain index. It gives applications three core properties:

1. Private by design: encryption happens before upload. DataPrism stores encrypted shards, while the project key stays with the user.
2. Storage that works out of the box: the platform manages the bucket and authorizes each upload, download, check, or delete with a short-lived project-scoped URL. Users never paste cloud credentials into the app.
3. An on-chain trust registry: the index that says where to find each fragment is stored on a blockchain, encrypted, inside a namespaced vault called a prism. Nobody can alter or delete that index without your key.

Privacy is not given, it is built. Code is the only law that cannot be lobbied.

                        ┌─────────────────────────────────────────┐
                        │                DataPrism                 │
                        │   (encryption + managed storage +        │
                        │      on-chain index + payments)          │
                        └─────────────────────────────────────────┘
                                          │
                                          ▼
                              ┌────────────────────────┐
                              │ Managed object storage │
                              │   encrypted shards     │
                              └────────────────────────┘

Who it is for

The target user is the enterprise. A company creates an account, tops up a balance of credits (by card or crypto), and then drives its storage programmatically through the SDK. DataPrism handles encryption, managed storage access, payments, and the on-chain index; the company keeps control of its project keys and data.

The pieces

DataPrism is a monorepo of independent packages, each with a single responsibility.

How a file is stored

The heavy data lives in managed object storage; the prism only holds a tiny, encrypted index.

file (any size)
  │  ① chunk  (content-defined, FastCDC)
  │  ② convergent-encrypt each chunk     → storage only ever sees ciphertext
  │  ③ erasure-code (Reed-Solomon)       → k data + m parity shards
  │  ④ content-address + dedup           → identical shards stored once
  │  ⑤ store                             → managed storage via signed URLs
  │  ⑥ build a Merkle manifest           → roll the route list up to a tiny root
  ▼
on-chain: a ~few-hundred-byte encrypted index (constant size, any file size)

To read the file back, the SDK reads the on-chain root, decrypts it with your key, fetches at least a quorum of shards from managed storage, reconstructs each chunk with Reed-Solomon, and reassembles the original file.

See File Storage & Resilience for the full pipeline.

Core concepts

• Prism: a namespaced, on-chain vault that stores the encrypted index of your files (the reconstruction routes), not the files themselves. Identified by a bytes32 ID (keccak256(owner, salt)); a shortened bytes16 cloud ID is used on-chain to save calldata. It holds a DPC balance and a set of data slots.
• DPC: the protocol's ERC-20 credit token. It pays protocol fees (every on-chain write) and relayer fees (when a relayer fronts the gas).
• The Cloud Standard: a convention (like Ethereum's EIPs, but for cloud) that reserves named slots in every prism: dataprism.key, dataprism.encryption, dataprism.metadata, and dataprism.providers. See Prisms & the Cloud Standard.
• Meta-transaction: users sign an EIP-712 message off-chain; a relayer submits it for them, so the user never needs to hold gas.
• Writer: an address granted delegated write access to a prism, optionally with an expiration.

Where to start

• New to the project? Read the Architecture overview, then the Concepts.
• Building an integration? Start with the SDK Overview.
• Working on the chain? See the Protocol contracts and Deployments.
• Running infrastructure? See the Relayer and Payment Relayer.