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
| Type | Status | Description |
|---|---|---|
postgres | Available | PostgreSQL database (current default) |
celestia | Coming Soon | Celestia DA layer |
avail | Coming Soon | Avail DA layer |
eigenda | Coming Soon | EigenDA |
ipfs | Coming Soon | IPFS 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 Case | Storage |
|---|---|
| Default setup | postgres |
| Maximum decentralization | DA layers (coming soon) |
| Censorship resistance | DA layers / IPFS (coming soon) |
| Rollup compatibility | DA layers (coming soon) |