Architecture

DataPrism combines client-side encryption, platform-managed object storage, and an on-chain index. Users write the encrypted index of their files into prisms (on-chain namespaced vaults) funded with DPC credits, while encrypted file shards are stored through short-lived, project-scoped URLs. The system spans three layers, smart contracts on the blockchain, off-chain services (API, storage, relayers), and the client (SDK + frontend).

System map

 ┌────────────────┐   create account / buy credits / create prism
 │  Enterprise    │──────────────────────────────┐
 │  (user)        │                               ▼
 └───────┬────────┘                     ┌──────────────────────┐
         │                              │  dataprism-frontend  │
         │ uses the SDK                 └──────────┬───────────┘
         ▼                                         │ card payment
 ┌──────────────────┐                              ▼
 │   dataprism-sdk  │                ┌─────────────────────────────┐
 │  ┌─────────────┐ │                │   Stripe                    │
 │  │ encryption  │ │                └──────────────┬──────────────┘
 │  │ chunk + RS  │ │                               │ webhook
 │  │ storage     │ │                               ▼
 │  └─────────────┘ │                ┌─────────────────────────────┐
 │  execution layer │                │ dataprism-payment-relayer   │
 │   wallet │ api   │                └──────────────┬──────────────┘
 └────┬─────────┬───┘                               │ buy/transfer DPC
      │         │                                   │
  shards│   on-chain                                ▼
      ▼         │                    ┌─────────────────────────────────┐
 ┌─────────┐    │ (api)              │  dataprism-api → dataprism-relayer
 │ Managed │◄───┤ signed URLs        │ ──────────────────► on-chain      │
 │ storage │    └──► dataprism-api ──►                  │                  │
 └─────────┘                              ┌───────────▼────────────────┐ │
 (encrypted)                              │     dataprism-protocol     │ │
                                          │  Token (DPC)               │ │
                                          │  DataPrism / DataPrismCloud │ │
                                          │  Forwarder (meta-tx)       │ │
                                          │  FeeController / Exchange  │ │
                                          └────────────────────────────┘ │
                                          (prisms + encrypted index)

In the dataprism-sdk block, "encryption / chunk + RS / storage" is the full file pipeline: FastCDC chunking → convergent encryption → Reed-Solomon → content-addressing (dedup) → managed storage → encrypted Merkle index on-chain. On the write side, the execution layer routes either to the wallet (gas paid in ETH) or to the API (gas fronted by the relayer, reimbursed in DPC).

The two write paths

Every on-chain write, creating a prism, writing a slot, storing a file index, goes through one of two interchangeable paths. The application code is identical; only the execution layer differs.

            ┌──────── does the user hold ETH for gas? ────────┐
            │ YES                                        NO   │
            ▼                                                 ▼
   direct contract call                       call to dataprism-api
   (DataPrismCloud.*)                          with a signed request
   user pays the gas                           (EIP-712, gasless)
            │                                                 │
            │                                  dataprism-relayer executes
            │                                  the transaction on-chain
            │                                  (pays gas, takes a DPC fee)
            ▼                                                 ▼
      write committed on-chain ◄───────────────────────────┘

Layers

Smart contracts (Protocol)

The on-chain core. DataPrism stores raw data per prism, DataPrismCloud adds the application layer (cloud IDs, writers, two-step transfers, enumeration, read-through getters), and DataPrismCloudForwarder enables gasless meta-transactions. Token (DPC) pays fees, FeeController prices actions, and Exchange lets users swap ERC-20 tokens (USDC) for DPC.

A strict rule holds across the stack: every off-chain component talks only to DataPrismCloud / Forwarder, never to the core DataPrism contract directly.

Client SDK (SDK)

The client-side core, in TypeScript, runnable anywhere (browser, Node, scripts). It owns encryption (keys derived from a wallet signature, never stored), the file pipeline (chunking + Reed-Solomon + managed storage), and the unified execution layer for on-chain writes. The frontend uses it; integrators embed it directly.

REST API (API)

A serverless API (AWS Lambda + API Gateway + DynamoDB) with two responsibilities. It authorizes managed-storage operations and returns short-lived signed URLs, and it queues EIP-712 requests between users and relayers. Relayers poll for pending requests, claim them atomically, and report the outcome. The API never submits blockchain transactions directly.

Relayers

Two distinct services:

Relayer submits user data meta-transactions to DataPrismCloudForwarder in exchange for a relayerFee in DPC.
Payment Relayer handles the fiat on-ramp: after a Stripe card payment, it buys DPC on the Exchange and transfers it to the user.

Frontend (Frontend)

A Next.js dashboard where users manage projects, storage, API keys, team members, and buy DPC tokens with a card or USDC. Identity is wallet-based; private keys never leave the browser.

End-to-end flow: writing data (`WRITE_DATA_FOR`)

This is the gasless (API) path. The wallet path collapses steps 2-7 into a single direct DataPrismCloud.writeData(...) call paid by the user.

1. OFF-CHAIN SIGNING
   User computes the EIP-712 hash:
   WriteData(cloudId, dataId, keccak256(payload), relayerFee, timestamp, nonce)
   Signs with their private key → (v, r, s)
 
2. REQUEST SUBMISSION
   POST /requests
   {
     "chainName": "demo",
     "action": "WRITE_DATA_FOR",
     "params": {
       "cloudId": "0x...", "dataId": "0x...", "payload": "0x...",
       "relayerFee": "1000000000000000000",
       "timestamp": "1749600000",
       "signer": "0xUserAddress",
       "v": 27, "r": "0x...", "s": "0x..."
     }
   }
   → API validates, stores in DynamoDB with status=pending, returns requestId
 
3. RELAYER POLL
   GET /requests?status=pending → receives the request
 
4. CLAIM
   PATCH /requests/{id} { status: "processing" }
   → Atomic DynamoDB update (condition: status=pending)
 
5. PROFITABILITY CHECK
   estimateGas(writeDataFor) × gasPrice × ethPrice ≤ relayerFee ?
 
6. ON-CHAIN CALL
   Forwarder.writeDataFor(cloudId, dataId, payload, relayerFee, timestamp, signer, v, r, s)
 
7. INSIDE THE FORWARDER
   a. Checks the priority window
   b. Recomputes the EIP-712 hash using the signer's current nonce
   c. Verifies the signature (ECDSA or ERC-1271)
   d. Calls DataPrismCloud.writeDataAs(cloudId, signer, dataId, payload, relayerFee)
 
8. INSIDE DATAPRISMCLOUD
   a. Deducts protocol fees from the prism's DPC balance
   b. Transfers relayerFee DPC to the Forwarder
   c. Calls DataPrism.writeData(prismId, dataId, payload)
   d. Increments the signer's nonce
 
9. REPORT
   PATCH /requests/{id} { status: "success", txHash: "0x..." }

The same flow applies to other actions by swapping the signed typehash, the request action, and the *For function called. In particular, a combined CREATE_PRISM_WITH_DATA_FOR flow follows exactly these steps: it signs a CreatePrismWithData request, the relayer calls Forwarder.createPrismWithDataFor(...), and DataPrismCloud.createPrismWithDataAs(...) creates the prism and writes the initial batch of entries in a single atomic transaction (one nonce increment).

Fee model

Two distinct fee levels apply to every operation. See the SDK fee model for how the SDK surfaces them.

Protocol fees

Paid in DPC, deducted from the prism's token balance.
Defined per action (ADD_DATA, MODIFY_DATA, DELETE_DATA, …) by the FeeController.
DataPrismCloud benefits from negotiated custom (zero) fees.
Sent to the FeeController's treasury.

Relayer fees (`relayerFee`)

Set by the user at signing time (only relevant on the API path).
Deducted from the prism's balance and forwarded to the Forwarder.
Distributed based on relayer status: official relayers receive 100%; non-official relayers receive relayerShareBps% (default 70%), the remainder goes to the protocolTreasury.
Accumulated as vouchers and claimed via claimVouchers().

Request lifecycle (API path)

pending → processing → success
                    ↘ failed

The pending → processing transition is atomic via a DynamoDB conditional expression, preventing two relayers from processing the same request simultaneously.