Skip to main content

Storage

Choose where your encrypted data is stored off-chain.

Overview​

Encrypted data is stored off-chain and referenced via content-addressed IDs (CIDs). On-chain contracts store only CID pointers, not the encrypted payloads.

Configuration​

Storage is configured when initializing the SDK:

import { SlotVaultClient } from '@zksdk/js-private-token-slots-fhe';

const client = new SlotVaultClient({
  workerUrl: 'https://alpha.coprocessor.zksdk.com',
  storageType: 'postgres',  // Storage backend
});

Or when storing data directly:

import { storeData } from '@zksdk/js-private-token-slots-fhe';

const cid = await storeData(workerUrl, encryptedData, {
  storageType: 'postgres',
});

Available Options​

TypeStatusDescription
postgresAvailablePostgreSQL database (current default)
celestiaComing SoonCelestia DA layer
availComing SoonAvail DA layer
eigendaComing SoonEigenDA
ipfsComing SoonIPFS storage
Future-Proof

The API stays the same. When DA layers launch, switch with a single config change:

const client = new SlotVaultClient({
  workerUrl: 'https://alpha.coprocessor.zksdk.com',
  storageType: 'celestia',  // Switch when available
});

How It Works​

Content-Addressed IDs (CIDs)​

Data is stored and retrieved by CID:

  • CIDs are SHA-256 hashes of the encrypted content
  • Same data always produces the same CID
  • CIDs are stored on-chain as references to off-chain data

Data Flow​

1. Client encrypts data locally
2. Encrypted data uploaded → returns CID
3. CID stored on-chain (vault/contract)
4. Coprocessor fetches by CID when processing
5. Result stored → new CID returned
6. Client fetches result by CID and decrypts

Why Different Storage Options?​

Use CaseStorage
Default setuppostgres
Maximum decentralizationDA layers (coming soon)
Censorship resistanceDA layers / IPFS (coming soon)
Rollup compatibilityDA layers (coming soon)